From nobody Thu Dec 1 00:31:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6771A12940C for ; Thu, 1 Dec 2016 00:31:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896] 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 WPdO5lBVvi_j for ; Thu, 1 Dec 2016 00:31:20 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id A0EB112949D for ; Thu, 1 Dec 2016 00:31:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id E6DDF18B0D; Thu, 1 Dec 2016 10:31:18 +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 aQnCzuGSqQ33; Thu, 1 Dec 2016 10:31:17 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 772DC21C; Thu, 1 Dec 2016 10:31:17 +0200 (EET) Date: Thu, 1 Dec 2016 10:31:11 +0200 From: Ilari Liusvaara To: Peter Gutmann Message-ID: <20161201083110.GA28486@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161201025025.GP26244@mournblade.imrryr.org> <1480566976732.22966@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1480566976732.22966@cs.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 certificate signature algorithm requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 08:31:33 -0000 On Thu, Dec 01, 2016 at 04:36:17AM +0000, Peter Gutmann wrote: > Viktor Dukhovni writes: > > >So I'd like to see the text in the first paragraph changed to a SHOULD or > >worst-case a qualified "MUST whenever possible". > > Why is that whole thing even there in the first place? From the previous > discussions where this came up, the pretty much universal consensus was that > people were ignoring the requirement because it served no obvious purpose > but broke interoperability. Unless you're a server operator that chooses to > buy a whole bunch of $995 certs, one per algorithm, from a CA that allows > you to choose which algorithm gets used for signing, the whole thing is > completely inapplicable. You send whatever cert chain the CA gave you to > the client, and it's up to them to decide whether they want to accept or > reject. What would be lost by simply removing that entire block of text, > since it's being ignored by implementers anyway? The solution is to remove > it, not to fiddle with it until it becomes a no-op that matches what > everyone is doing anyway. Using algorithms that are supported is kinda important for interop, since if you send a non-(super-)TA certificate using algorithm the client doesn't know, it is going to have trouble validating the chain. If you are referring to mixing RSA/ECDSA certs in one certificate chain, that already works fine in TLS-1.2-as-of-spec (unless client does something crazy[1]). TLS 1.3 removes the options for clients to be crazy here. [1] That's related to requirment of matching EE (not any CA) certificate type and ciphersuite, causing client to be able to trip all sorts of bugs and edge cases in ciphersuite selection. -Ilari From nobody Thu Dec 1 03:48:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA80212963B for ; Thu, 1 Dec 2016 03:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqJyZNVdYpdj for ; Thu, 1 Dec 2016 03:46:10 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 244A612963A for ; Thu, 1 Dec 2016 03:46:10 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B3562C04D2A4; Thu, 1 Dec 2016 11:46:09 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-97.brq.redhat.com [10.40.204.97]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB1Bk8cm029442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Dec 2016 06:46:09 -0500 From: Hubert Kario To: Martin Thomson Date: Thu, 01 Dec 2016 12:46:07 +0100 Message-ID: <2548632.5mfjX3JiUz@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.8-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: References: <20161124195002.GA32346@bolet.org> <2592774.mFcuq1jeh1@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9681735.o5vD7iRQfB"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Thu, 01 Dec 2016 11:46:09 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2016 11:48:45 -0000 --nextPart9681735.o5vD7iRQfB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 1 December 2016 09:43:54 CET Martin Thomson wrote: > Asking ALL TLS implementations to change to accommodate these things > is a pretty blunt instrument. I want to be sure that this is > necessary. (FWIW, I think that this is a reasonable request, I would > probably be OK with a smaller maximum by default even.) for receiving those messages you don't have to do anything above what the=20 specification already requires for sending the implementations already have to be able to fragment their=20 messages - the change is only to make the value that guards those sizes a=20 variable instead of being hardcoded that leaves the matter of negotiation of the value itself - which, while it= is=20 yet another extension that needs to be supported, it is not exactly complex= or=20 that requires convoluted logic > On 1 December 2016 at 00:22, Hubert Kario wrote: > > On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote: > >> On 30 November 2016 at 05:54, Thomas Pornin wrote: > >> > Any comments? > >>=20 > >> I'm ambivalent on this generally: though I think that the general > >> notion is OK, I'm not sure about the details. > >>=20 > >> In particular, you need to be clearer in your motivations: the point > >> is to ensure that little things (really little things) can talk to any > >> other TLS implementation. That seems inherently good, but it might > >> pay to dig into that some more: why is that good? > >=20 > > because if they can't use TLS, they will create a bespoke protocol, and > > those have a tendency of being completely broken, on conceptual level, > > let alone implementation > >=20 > > combine it with the fact that "trusted network" doesn't exist any more = and > > you end up with solutions that are insecure with nobody using them knows > > they are insecure, especially in IoT space > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart9681735.o5vD7iRQfB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYQA1/AAoJEJKo0bgB0vX1t08P/1sbapA4SZovF7WMZ0dfmFqN W49kCZIZwGRVT/6KaQbjbyzLD9QnmmQKu0RiaIxRpGcqCWOzHdCH3OCBXg8oXpoA Tp5MGDvHJVB6YbsBbh5DF5KCW9mj+Iie9RxdjGTGdBf/V/5svIirwZQHx8j9S5QN p5T+gGziPGCOsuRZuXAcP1EJpEAz9KUBzQ7eUDNDS2WJQtlXpFKD1kDCCflooDb3 3kABFzBFkDdeeoygHpP5yTwSni40uiBgnl+75833XiikE8fv16nvE1xvyvUGjsoc bNxsEzXL3CgFx2G0jkT2RO1r7gY6DE9dWOVE3SeAfbdLwkq0RSKj/1+bFPNq/RLn ZrYMwoD5l7nX5SzdTTbJG45LO/KfDubCyOVgdjGDz++W8Yff9Od5hVgohcajRJnl e7qrBXGAUSXerjxtt4sUBSoCrGXn8iTpfR+V3Ok8mDN5Hn8zhbTj7eVjeEWtTy5s M17y0PO/KtZDcFiM6XulP3C9EXrDfOFPprm8Dstf/EZ9peE5G1918c3V3uiVP3i/ M5OWkLcrn6BwqDu5gNClsp1ViMAGL1gXH/G4tmqPRQBfJl1aEei4IiqbOxNryfsi /cKDJ5RB5xFCbypP8ta4ohwgHzxrOqzfPadRnyaBOsWv7xRYl09JTjA2mPNkzAK3 opIisarr0prMGi5hqOxy =ZqIr -----END PGP SIGNATURE----- --nextPart9681735.o5vD7iRQfB-- From nobody Thu Dec 1 18:16:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D538129661 for ; Thu, 1 Dec 2016 18:16:45 -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 FC5ROY1QTqzn for ; Thu, 1 Dec 2016 18:16:43 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 44804129400 for ; Thu, 1 Dec 2016 18:16:43 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 51so268011131uai.1 for ; Thu, 01 Dec 2016 18:16:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nv87KOeUdvgIwhC0St/OL1R7cohVVC9qlWpBpKYwZEQ=; b=rFQOAgETzYN+ZBSAoAFvXsfW8/iIZg4CCOxjZIrhhod5MzK0UaPT2sHxJnQonfkSjk 4XdKsHHMh1uCWAiHv3hONREmCqZaOIUv0K0+7N7QyhPIZXpRMVLpL5M1LX7S/2Rm1ck6 yMeweK6qieW7OjZ1uOqV9XcwCKNGPcQFl+Eu7kiwRD/D5HPrx8nr81Er6CAYUUnt0WR4 GY9GJv84JVVEMEmtNKkmtEcZ/aSWNG5Tbu5K2iN3s7B2/AOMnBFoUhEFmC0oTGvXbQMH ciSPfA8Figx30Tboxsl7FWXa9zY5g9fEiZVBC/q2hzptKDY0N/Vz1sL2Tu8I1S8iIJap KNUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nv87KOeUdvgIwhC0St/OL1R7cohVVC9qlWpBpKYwZEQ=; b=KEfA68oaRqjoKJmHHWncHO3K8nMsJ5vQc8gkBIrv3PWTrvgIJ+k854Ao1AB40/NEb+ FvlldV/4ma2BTmGFzrNfENjIn9Z4C6bOHsqMCFvKyqcX6F5GN3VbV2ojUGswGgOGmkQP 0ms8ZTg1VTjjAGQiB8k30sltePQ0RT4bbzdJ8hAbYV+xOcF0oSBV5e2yjjbjNB8oDMXk 5paud+QRLLFn277CI8gigEbBxLKSsHgC7XY26UD3J0OT+pOrp8+tyeSqxtKmONi+TxdT MfhiQ1A3fBeQgfdPPRmFh05GLpz0Yr4Hixn00vQcf1rb3L5dyCGgjDujPD4j/g0H/aXi BeOg== X-Gm-Message-State: AKaTC01YJREUvo7oh3hNLT9WJi4tCHKraYHDI40IRS0cDUkjfTpO3lzXlvCLkKi8eZ5MTa9yLePiB0G/OWEAWg== X-Received: by 10.159.35.118 with SMTP id 109mr31734708uae.113.1480645002230; Thu, 01 Dec 2016 18:16:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.145.144 with HTTP; Thu, 1 Dec 2016 18:16:21 -0800 (PST) In-Reply-To: References: <1480566504487.58214@cs.auckland.ac.nz> From: Tony Arcieri Date: Thu, 1 Dec 2016 18:16:21 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a11357dd66580fa0542a38709 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 02:16:45 -0000 --001a11357dd66580fa0542a38709 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 30, 2016 at 8:43 PM, Viktor Dukhovni wrote: > > I actually completely agree with Timothy Jackson's recent posting: > > > > After 15 years, everyone but us still calls it SSL. We need to > > admit that we lost the marketing battle and plan for a world where > > everyone calls =E2=80=9CTLS X=E2=80=9D =E2=80=9CSSL X=E2=80=9D. Even = =E2=80=9Cnew=E2=80=9D implementations call > > themselves =E2=80=9CLibreSSL=E2=80=9D and =E2=80=9CBoringSSL=E2=80=9D= rather than =E2=80=9CLibreTLS=E2=80=9D or > > =E2=80=9CBoringTLS=E2=80=9D. > > I'll drink to that! I will also +1 this and add that if the goal is to reduce confusion, a last minute renaming of TLS 1.3 to something else probably won't accomplish that, but will rather create more confusion. There's already ample material out there (papers, presentations, mailing list discussions, etc) which talks about "TLS 1.3". Rebranding it now would add an additional bit of errata everyone needs to learn if they ever encountered the "TLS 1.3" version in any of these materials. And I think the whole SSL/TLS thing is errata enough. --=20 Tony Arcieri --001a11357dd66580fa0542a38709 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 30, 2016 at 8:43 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
&= gt; I actually completely agree with Timothy Jackson's recent posting:<= br> >
>=C2=A0 =C2=A0After 15 years, everyone but us still calls it SSL. We nee= d to
>=C2=A0 =C2=A0admit that we lost the marketing battle and plan for a wor= ld where
>=C2=A0 =C2=A0everyone calls =E2=80=9CTLS X=E2=80=9D =E2=80=9CSSL X=E2= =80=9D. Even =E2=80=9Cnew=E2=80=9D implementations call
>=C2=A0 =C2=A0themselves =E2=80=9CLibreSSL=E2=80=9D and =E2=80=9CBoringS= SL=E2=80=9D rather than =E2=80=9CLibreTLS=E2=80=9D or
>=C2=A0 =C2=A0=E2=80=9CBoringTLS=E2=80=9D.

I'll drink to that!

I will also = +1 this and add that if the goal is to reduce confusion, a last minute rena= ming of TLS 1.3 to something else probably won't accomplish that, but w= ill rather create more confusion. There's already ample material out th= ere (papers, presentations, mailing list discussions, etc) which talks abou= t "TLS 1.3". Rebranding it now would add an additional bit of err= ata everyone needs to learn if they ever encountered the "TLS 1.3"= ; version in any of these materials. And I think the whole SSL/TLS thing is= errata enough.

--
Tony Arcieri
--001a11357dd66580fa0542a38709-- From nobody Thu Dec 1 18:47:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56ED1299C1 for ; Thu, 1 Dec 2016 18:47:52 -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 zyV_biwH5Yaw for ; Thu, 1 Dec 2016 18:47:50 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::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 A18E412956C for ; Thu, 1 Dec 2016 18:47:50 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id 51so268565404uai.1 for ; Thu, 01 Dec 2016 18:47:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=d0jzhOCHb08m4ga7khgOMhS8mL7n1yj0vUufsR39ZgI=; b=wvs943Q7/fViIrT+15fE1TP+JIBSvT47UmDsj+cuuLtUXke1ZjPGRsUEPPHcL13vVk fPSOVwNu0qTKQSmrbveOCZ2EUvszlAQNRf0KNMdCo6H/eZ5HuFy378Vuwk9Fi+AVgqRh WlXQiyKjA4pDQwWVDrpthJhRhRmY73reyxehLEvMMkJZJ9JKuEnXNRL+pzUfzK+v+43Z qOMNdQ7+d05lTo2HRp7n6JSwlWmxFi21amMVNgefvdMgipsnSKvoU16wBKCOVcbqwtyL cwfHyxOyM/ouDowWvizZN8clT/rBohlvkFwZMvx774Scp8E/gOiclQUbYou/67JNW++p gcZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=d0jzhOCHb08m4ga7khgOMhS8mL7n1yj0vUufsR39ZgI=; b=Dd4nFOKL1rjSSDWTT5DTB7ZjkUI3ttpkRbRxS5cGv7lPVt/x8IvbVPVw9QPugeBY3r z1tnL2RGfbXncEpZP94dJoWB20U+lqU/bpK+oCL6gmkKa0zKrTHweCCUnJngYwhTO2iQ +MXUNQ0N/N6cTU+jZl/Sb4FWdUfjiP/ccLdbLfJqm/K6ajHi500pnCxkz3JH7M9lzHws f8R10EASCcZw7yBbC5hhwHr7yLLkLOnpgquWbx6/PSpkN9Hz9LCCh8U4u2+JcCggm3Dk 5qDn9SmhxKdgNePjLtTI83djydI3x1gvAncg9utz2UAULlAa2JTt7wSmT/ZElwZBNkLf qYqg== X-Gm-Message-State: AKaTC01s3ijHRCRwGBnnpAq54GRKDAAOIfjlhzI86VhoDkIyo6fM4yTcL/YQ7ZcpbjdykXtOO8BsDClqREl4WQ== X-Received: by 10.176.65.33 with SMTP id j30mr31889271uad.94.1480646869700; Thu, 01 Dec 2016 18:47:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.50.153 with HTTP; Thu, 1 Dec 2016 18:47:48 -0800 (PST) In-Reply-To: References: <1480566504487.58214@cs.auckland.ac.nz> From: Watson Ladd Date: Thu, 1 Dec 2016 18:47:48 -0800 Message-ID: To: Tony Arcieri Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 02:47:52 -0000 On Thu, Dec 1, 2016 at 6:16 PM, Tony Arcieri wrote: > On Wed, Nov 30, 2016 at 8:43 PM, Viktor Dukhovni > wrote: >> >> > I actually completely agree with Timothy Jackson's recent posting: >> > >> > After 15 years, everyone but us still calls it SSL. We need to >> > admit that we lost the marketing battle and plan for a world where >> > everyone calls =E2=80=9CTLS X=E2=80=9D =E2=80=9CSSL X=E2=80=9D. Even= =E2=80=9Cnew=E2=80=9D implementations call >> > themselves =E2=80=9CLibreSSL=E2=80=9D and =E2=80=9CBoringSSL=E2=80= =9D rather than =E2=80=9CLibreTLS=E2=80=9D or >> > =E2=80=9CBoringTLS=E2=80=9D. >> >> I'll drink to that! > > > I will also +1 this and add that if the goal is to reduce confusion, a la= st > minute renaming of TLS 1.3 to something else probably won't accomplish th= at, > but will rather create more confusion. There's already ample material out > there (papers, presentations, mailing list discussions, etc) which talks > about "TLS 1.3". Rebranding it now would add an additional bit of errata > everyone needs to learn if they ever encountered the "TLS 1.3" version in > any of these materials. And I think the whole SSL/TLS thing is errata > enough. So what should X be in above email? Clearly it should be \geq 4. > > -- > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Dec 1 19:12:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB35C129A6F for ; Thu, 1 Dec 2016 19:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 wQ5eI0myc_Qv for ; Thu, 1 Dec 2016 19:12:48 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DC8126FDC for ; Thu, 1 Dec 2016 19:12:47 -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=1480648367; x=1512184367; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SqVzSgtyvXWMabNN2/ksvSWTuf+qblFhodIEsmNMMhs=; b=gQUQXYy3TOI+4WV313TbqYsL9PeFqSZXAPDKRzJqB8wsOtrj+EQP3dNi T8NlAPVpdhrozZUEPIuwOH1yR4G09OlajIJTP/2+tMVxYZJxeTZ3usCG1 UBkiEPDRDSZ0cBcMPt3K9o51kzPA/PyVVxy8c9qPGseJC4yfw4IcbnKB4 W5Qd6+C+4zeXfrLVpqrNfq9mJ3gWX5TMzH548EZ1OqAH0PP0+apQShz4J tkmPLEplcmtlzc6rpe/fYJ+/RlVnVT4dEcJJLOmouUQYDxSWFVpPb1mq+ xH2OZzPT4EpUG75ANpMVwUS4EdLgE3f5j/+NsbN1JihdqLft+TD2LROAu Q==; X-IronPort-AV: E=Sophos;i="5.33,284,1477911600"; d="scan'208";a="118438870" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Dec 2016 16:12:42 +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.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 2 Dec 2016 16:12: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.1178.000; Fri, 2 Dec 2016 16:12:42 +1300 From: Peter Gutmann To: Tony Arcieri , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfD667DaatoU6RNleDGo1T66DwCVTAgAGDyICAAQa6CP//KrAAgAFpLoCAAOlzAw== Date: Fri, 2 Dec 2016 03:12:41 +0000 Message-ID: <1480648354917.41781@cs.auckland.ac.nz> References: <1480566504487.58214@cs.auckland.ac.nz> , 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] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 03:12:51 -0000 Tony Arcieri writes:=0A= =0A= >There's already ample material out there (papers, presentations, mailing l= ist=0A= >discussions, etc) which talks about "TLS 1.3".=0A= =0A= In other words, the TLS WG and a small number of people who interact with i= t=0A= call it TLS 1.3.=A0 That's hardly a strong argument when most of the rest o= f the=0A= world doesn't even call it TLS.=0A= =0A= In fact that's something that's come up repeatedly in the bikeshedding so f= ar,=0A= there are some really good, sound arguments for calling it TLS/SSL 4 or=0A= TLS/SSL 2017, while pretty much the only reasons I've seen for TLS 1.3 are= =0A= inertia, "we've always called it that"/"I don't want to change"/etc.=0A= =0A= Peter.=0A= =0A= = From nobody Thu Dec 1 19:35:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EA50129A7D for ; Thu, 1 Dec 2016 19:35:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, 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 Z0WamjqAfBld for ; Thu, 1 Dec 2016 19:35:12 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC565129A7C for ; Thu, 1 Dec 2016 19:35:11 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id n21so266989326qka.3 for ; Thu, 01 Dec 2016 19:35:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=zBkatizUXGrMOZ2HlzDuInWowmZBCU+qDEtgsj1/JUs=; b=SU6jf67B+WTbQUeI3N78yijllIVFOndOu9mNZd9uUVqQl4RX7Jjk1LjkNHaJPpqvxr adARGuYuHYvaznMZlqvo+RmDFaSHXI/it/CVOJObRQeyaCvuKhMlQqvI4i6CroZz/v3H XtmAkSFctS5iyG22LkuZPch6GWb9QMxWq4UEc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=zBkatizUXGrMOZ2HlzDuInWowmZBCU+qDEtgsj1/JUs=; b=bYiovQpNXf9B4Wra4BGjnQvND9kN4OuOORUnjmEdOn/Z2Kawg5E1gRQ60rJ0vqxBrO 66jYwN2X7ZPuHSsQE2P7L0KmGPtqhPnF21s9MIE6y/T/VTIAzXmjGbGS8lRILSCh8BxV 12PWXFA14ZueIa/wzVKa7H3NWQx41X6Yf5CPYC8X3x/nbTIsu0UyMk1v/d4iCadsWaPI nbHU6KoTMJ1Ft8efD26jfDb8nVvoF+WNM4h/y5U+PAVpZgAmHxihHg9d/V+qtEmXqIPs hPn15Upi6MoP74mtqzAnH7Ru2khjzoS2aHwHTYHntchzW0fDQnfUIHcaOohcA6abDB8d V+6Q== X-Gm-Message-State: AKaTC03F2ViTxU2v406OMmtVXmx0ZrMmYafMo/lUwUzhTVyZIChynvAI5bBbNhACztqCvl5pGfgU4hpoUZPbwEMb X-Received: by 10.55.10.7 with SMTP id 7mr34299889qkk.162.1480649710688; Thu, 01 Dec 2016 19:35:10 -0800 (PST) MIME-Version: 1.0 References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> In-Reply-To: <1480648354917.41781@cs.auckland.ac.nz> From: David Benjamin Date: Fri, 02 Dec 2016 03:35:00 +0000 Message-ID: To: Peter Gutmann , Tony Arcieri , "" Content-Type: multipart/alternative; boundary=001a114c563e0b3bed0542a4a057 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 03:35:14 -0000 --001a114c563e0b3bed0542a4a057 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 1, 2016 at 10:12 PM Peter Gutmann wrote: > Tony Arcieri writes: > > >There's already ample material out there (papers, presentations, mailing > list > >discussions, etc) which talks about "TLS 1.3". > > In other words, the TLS WG and a small number of people who interact with > it > call it TLS 1.3. That's hardly a strong argument when most of the rest of > the > world doesn't even call it TLS. > > In fact that's something that's come up repeatedly in the bikeshedding so > far, > there are some really good, sound arguments for calling it TLS/SSL 4 or > TLS/SSL 2017, while pretty much the only reasons I've seen for TLS 1.3 are > inertia, "we've always called it that"/"I don't want to change"/etc. I think TLS 4 makes everything worse, not better. In hindsight, renaming SSL 3.1 was a terrible mistake. But TLS 1.2 is going to exist for a long time. If we call the next one 4, we have to explain a gap in the versioning (1.0, 1.1, 1.2, 4?) and placing 2.0 and 3.0 after 1.2 becomes even more inviting. Short of a time machine so we can call this SSL 3.4, the best fix is to let SSL 3.0 fall away. This is already semi-plausible (it's out of all browsers) and is only going to become more realistic over time. Certainly it will be faster than TLS 1.2 going away and undoing TLS 4's version gap problem. (TLS 1.3 even places SSL 3.0 as a MUST NOT, for what little teeth that has.) Once SSL 3.0 falls away, we'll be left with 1.0, 1.1, 1.2, and 1.3, which is a plausible numbering progression. There'll still be the mess with SSL being the informal name for the protocol family, but that isn't a numbering problem. David --001a114c563e0b3bed0542a4a057 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Dec 1,= 2016 at 10:12 PM Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Tony Arcieri <bascule@gmail.com> writes:

>There's already ample material out there (papers, presentations, ma= iling list
>discussions, etc) which talks about "TLS 1.3".

In other words, the TLS WG and a small number of people who interact with i= t
call it TLS 1.3.=C2=A0 That's hardly a strong argument when most of the= rest of the
world doesn't even call it TLS.

In fact that's something that's come up repeatedly in the bikeshedd= ing so far,
there are some really good, sound arguments for calling it TLS/SSL 4 or
TLS/SSL 2017, while pretty much the only reasons I've seen for TLS 1.3 = are
inertia, "we've always called it that"/"I don't want= to change"/etc.

I think TLS 4 makes e= verything worse, not better.

In hindsight, renamin= g SSL 3.1 was a terrible mistake. But TLS 1.2 is going to exist for a long = time. If we call the next one 4, we have to explain a gap in the versioning= (1.0, 1.1, 1.2, 4?) and placing 2.0 and 3.0 after 1.2 becomes even more in= viting.

Short of a time machine so we can call thi= s SSL 3.4, the best fix is to let SSL 3.0 fall away. This is already semi-p= lausible (it's out of all browsers) and is only going to become more re= alistic over time. Certainly it will be faster than TLS 1.2 going away and = undoing TLS 4's version gap problem. (TLS 1.3 even places SSL 3.0 as a = MUST NOT, for what little teeth that has.)

Once SS= L 3.0 falls away, we'll be left with 1.0, 1.1, 1.2, and 1.3, which is a= plausible numbering progression. There'll still be the mess with SSL b= eing the informal name for the protocol family, but that isn't a number= ing problem.

David
--001a114c563e0b3bed0542a4a057-- From nobody Thu Dec 1 20:43:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E92612943B for ; Thu, 1 Dec 2016 20:43:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeLAYyzn9ZY5 for ; Thu, 1 Dec 2016 20:43:04 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id AF708129428 for ; Thu, 1 Dec 2016 20:43:04 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E03A6433462; Fri, 2 Dec 2016 04:43:03 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C5A8A433446; Fri, 2 Dec 2016 04:43:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480653783; bh=jAANFzLoxSlAStr5mWE/2WiFJ5Wvu7HyW7IcPPxWp40=; l=496; h=From:To:Date:References:In-Reply-To:From; b=Ch/0ZTYp+2i7b9/OuJigzq1QaOov9EPpQaaYYt2/yEPrCgL7eRIOeavo30ItOZCrD Zn8DbKuielJK23lDp/7ud35Rj1S8/FYGJChsXWRe2l7gTxDEwEI8ygNhwU/45m9ecZ bXfdlhcXuzSV0de8e5JKCjfOgfO++EwRdFGj5NNg= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id BCC671FC8C; Fri, 2 Dec 2016 04:43:03 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Dec 2016 23:43:03 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 1 Dec 2016 23:43:03 -0500 From: "Salz, Rich" To: Peter Gutmann , Tony Arcieri , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDwX4eAgAJbVYCAAC0nAIAABEIAgAFpLoCAAA++gP//xHQA Date: Fri, 2 Dec 2016 04:43:03 +0000 Message-ID: <577e248fa6454c178053e6559df9af54@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1480566504487.58214@cs.auckland.ac.nz> , <1480648354917.41781@cs.auckland.ac.nz> In-Reply-To: <1480648354917.41781@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.164] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 04:43:06 -0000 > In other words, the TLS WG and a small number of people who interact with > it call it TLS 1.3.=A0 That's hardly a strong argument when most of the r= est of the > world doesn't even call it TLS. Strongly agreed > pretty much the only reasons I've seen for TLS 1.3 are > inertia, "we've always called it that"/"I don't want to change"/etc. Yes. Think outside the community. The world calls it SSL. Many of the vendors = in this industry also call it SSL. SSL 4 or greater. From nobody Thu Dec 1 20:48:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192FD129A9E for ; Thu, 1 Dec 2016 20:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0RTgpK_4dEB1 for ; Thu, 1 Dec 2016 20:48:07 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 65F2A129A96 for ; Thu, 1 Dec 2016 20:48:07 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0D4E1433464; Fri, 2 Dec 2016 04:48:07 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id EACE04EA48; Fri, 2 Dec 2016 04:48:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480654086; bh=xLAumsVi9CJ2LEC2jkPa/RX4Ngaz27uDn0u4SMzfQ5E=; l=6496; h=From:To:Date:References:In-Reply-To:From; b=DGmkJY0/CpazICXANFugIlJj3qCzkqKHCznungZ1jK9sj6y5oef+f5waYzkqMrYj9 XzUpjv/WYec4b813opcBHMp1gjRCYBNRTP23RkMsCtpwLjmPqxOhiM4QwrwI/6i6/z Vxw1VwJdor7mQOu0tOT463pKBabrmb5s8EMvOpZI= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id E4FC81FC8C; Fri, 2 Dec 2016 04:48:06 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Dec 2016 23:48:06 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 1 Dec 2016 23:48:06 -0500 From: "Salz, Rich" To: David Benjamin , Peter Gutmann , Tony Arcieri , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDwX4eAgAJbVYCAAC0nAIAABEIAgAFpLoCAAA++gIAABjwA//+/4DA= Date: Fri, 2 Dec 2016 04:48:05 +0000 Message-ID: <80fcb2d5f9a84f0d959e25a4d36fddc8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.164] Content-Type: multipart/alternative; boundary="_000_80fcb2d5f9a84f0d959e25a4d36fddc8usma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 04:48:09 -0000 --_000_80fcb2d5f9a84f0d959e25a4d36fddc8usma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJZiB3ZSBjYWxsIHRoZSBuZXh0IG9uZSA0LCB3ZSBoYXZlIHRvIGV4cGxhaW4gYSBnYXAgaW4g dGhlIHZlcnNpb25pbmcgKDEuMCwgMS4xLCAxLjIsIDQ/KSBhbmQgcGxhY2luZyAyLjAgYW5kIDMu MCBhZnRlciAxLjIgYmVjb21lcyBldmVuIG1vcmUgaW52aXRpbmcuDQoNCk5vIHdlIGRvbid0IGhh dmUgdG8gZXhwbGFpbiBpdC4gIE1vc3Qgb2YgdGhlIHdvcmxkIGlzbid0IE9DRCB0eXBlcyBsaWtl IHRob3NlIG9mIHVzIGluIHRoaXMgZmllbGQuDQoNCj4gT25jZSBTU0wgMy4wIGZhbGxzIGF3YXks IHdlJ2xsIGJlIGxlZnQgd2l0aCAxLjAsIDEuMSwgMS4yLCBhbmQgMS4zLCB3aGljaCBpcyBhIHBs YXVzaWJsZSBudW1iZXJpbmcgcHJvZ3Jlc3Npb24uIFRoZXJlJ2xsIHN0aWxsIGJlIHRoZSBtZXNz IHdpdGggU1NMIGJlaW5nIHRoZSBpbmZvcm1hbCBuYW1lIGZvciB0aGUgcHJvdG9jb2wgZmFtaWx5 LCBidXQgdGhhdCBpc24ndCBhIG51bWJlcmluZyBwcm9ibGVtLg0KDQpPbmNlIFNTTCAzLjAgZmFs bHMgYXdheSwgdGhlIGluZHVzdHJ5IHdpbGwgc3RpbGwgYmUgY2FsbGluZyB0aGUgcHJvdG9jb2wg U1NMLiAgRXhjZXB0IG5vdyB0aGUgY29tbW9uIG5hbWUgYW5kIHRoZSByZWFsIG5hbWUgaGF2ZSBu byByZWxhdGlvbnNoaXAuDQoNCkFuZCBhbHNvLCB0aGUgd29ybGQgd2lsbCBub3QgY2FyZSBhYm91 dCBhIGdhcCBpbiBudW1iZXJpbmcuICBOb2JvZHkgY2FyZWQgdGhhdCB0aGVyZSB3YXMgbm8gV2lu ZG93cyA5Lg0KDQo= --_000_80fcb2d5f9a84f0d959e25a4d36fddc8usma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCglj b2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVk ZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0t PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0K PG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+ PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxp bms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZndDsgSWYg d2UgY2FsbCB0aGUgbmV4dCBvbmUgNCwgd2UgaGF2ZSB0byBleHBsYWluIGEgZ2FwIGluIHRoZSB2 ZXJzaW9uaW5nICgxLjAsIDEuMSwgMS4yLCA0PykgYW5kIHBsYWNpbmcgMi4wIGFuZCAzLjAgYWZ0 ZXIgMS4yIGJlY29tZXMgZXZlbiBtb3JlIGludml0aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Tm8gd2UgZG9uJ3Qg aGF2ZSB0byBleHBsYWluIGl0LiZuYnNwOyBNb3N0IG9mIHRoZSB3b3JsZCBpc24ndCBPQ0QgdHlw ZXMgbGlrZSB0aG9zZSBvZiB1cyBpbiB0aGlzIGZpZWxkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jmd0OyBPbmNlIFNT TCAzLjAgZmFsbHMgYXdheSwgd2UnbGwgYmUgbGVmdCB3aXRoIDEuMCwgMS4xLCAxLjIsIGFuZCAx LjMsIHdoaWNoIGlzIGEgcGxhdXNpYmxlIG51bWJlcmluZyBwcm9ncmVzc2lvbi4gVGhlcmUnbGwg c3RpbGwgYmUgdGhlIG1lc3Mgd2l0aCBTU0wgYmVpbmcNCiB0aGUgaW5mb3JtYWwgbmFtZSBmb3Ig dGhlIHByb3RvY29sIGZhbWlseSwgYnV0IHRoYXQgaXNuJ3QgYSBudW1iZXJpbmcgcHJvYmxlbS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPk9uY2UgU1NMIDMuMCBmYWxscyBhd2F5LCB0aGUgaW5kdXN0cnkgd2lsbCBzdGls bCBiZSBjYWxsaW5nIHRoZSBwcm90b2NvbCBTU0wuJm5ic3A7IEV4Y2VwdCBub3cgdGhlIGNvbW1v biBuYW1lIGFuZCB0aGUgcmVhbCBuYW1lIGhhdmUgbm8gcmVsYXRpb25zaGlwLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ QW5kIGFsc28sIHRoZSB3b3JsZCB3aWxsIG5vdCBjYXJlIGFib3V0IGEgZ2FwIGluIG51bWJlcmlu Zy4mbmJzcDsgTm9ib2R5IGNhcmVkIHRoYXQgdGhlcmUgd2FzIG5vIFdpbmRvd3MgOS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_80fcb2d5f9a84f0d959e25a4d36fddc8usma1exdag1mb1msgcorpak_-- From nobody Thu Dec 1 20:56:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA9C7129AAB for ; Thu, 1 Dec 2016 20:56:53 -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 NsCawPd8H7KF for ; Thu, 1 Dec 2016 20:56:52 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFFA129A9D for ; Thu, 1 Dec 2016 20:56:51 -0800 (PST) Received: from [47.143.125.162] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1cCftO-0007g4-0u; Thu, 01 Dec 2016 23:56:14 -0500 Date: Thu, 1 Dec 2016 20:56:13 -0800 From: Bill Frantz To: "Salz, Rich" X-Priority: 3 In-Reply-To: <80fcb2d5f9a84f0d959e25a4d36fddc8@usma1ex-dag1mb1.msg.corp.akamai.com> 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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79706e0c56100601363f81d7538956923c350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.162 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 04:56:54 -0000 On 12/2/16 at 8:48 PM, rsalz@akamai.com (Salz, Rich) wrote: >And also, the world will not care about a gap in numbering. Nobody cared = that there was no Windows 9. If we go with 2017, we can tell the world that by using the year=20 the standard was approved, instead of a confusing set of names=20 and numbers, we are eliminating any confusion about which=20 version is the most recent. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | gets() remains as a monument | Periwinkle (408)356-8506 | to C's continuing support of | 16345=20 Englewood Ave www.pwpconsult.com | buffer overruns. | Los Gatos,=20 CA 95032 From nobody Fri Dec 2 00:27:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0608126BF7 for ; Fri, 2 Dec 2016 00:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.197 X-Spam-Level: X-Spam-Status: No, score=-7.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yENAOfYxfqDV for ; Fri, 2 Dec 2016 00:27:07 -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 54873129431 for ; Fri, 2 Dec 2016 00:27:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 40608BE64; Fri, 2 Dec 2016 08:27:02 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 q7aP6zl3krN9; Fri, 2 Dec 2016 08:27:01 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 83E30BE51; Fri, 2 Dec 2016 08:27:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1480667220; bh=H+hZcwb/SSk7scGL6qy3fjQsVvlzgZFO3oB8Nevw/h8=; h=Subject:To:References:From:Date:In-Reply-To:From; b=prO9X5bESrIpNNFj57vGvhDeqRUHQNziZDxgfg0ms1iwvZ96wdIdoYFTWAs1sxYA9 QvCkNF+htj5i5S68LYcYU5HxtJcIOQnSWz/19NlUIxzVEwxe5TmzarPjPitz2RkXLj slayi96ER2t77ittz0+72/962OYp85FS0IEIxlPI= To: David Benjamin , Peter Gutmann , Tony Arcieri , "" References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> Date: Fri, 2 Dec 2016 08:27:00 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010607040905050605050609" Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 08:27:10 -0000 This is a cryptographically signed message in MIME format. --------------ms010607040905050605050609 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/12/16 03:35, David Benjamin wrote: > In hindsight, renaming SSL 3.1 was a terrible mistake. IIRC that was sort-of a condition for adoption of the work in the IETF 20 years ago, when there were two different protocols already being deployed and the proponents of one of them said "we'll use that other one (SSL) but you gotta change the name of the standard or we can't get our to agree to change to all use the same thing." So changing to TLS was maybe a mistake or maybe not as it allowed us to end up with one protocol with two names and not two (or more) protocols. Cheers, S. --------------ms010607040905050605050609 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMDIw ODI3MDBaMC8GCSqGSIb3DQEJBDEiBCDK5zpFQy/qpzU5eGKTyoEOKnPQloOkoDu3zDO2uysT lDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCs49aV19MarOWT9t1pwq15xWOurVceyF8xgZwibWLdYAAQVmouKxLS HG1fKmCBcch1Wfj8TRHP/5Ce7+n8ZtSt4RACuK67KF7GDQDhl1ic2PTDfct7lf7JE4nZusnE qJMbn8b0TvnMum4dRTvuHBlPZmoAlvCicdL425xOoloaLXl8MO4otsw73139ePdcYug87QxU sp5YIYvFdxxQ8JrjK5y6F+t9pAO1brrHzmbJFcgMhhuCdBqAn9ECptTWTS44ZQl7IViK8HBC r8dN59tNwwTo8Zn9iY/XVrKfeYWRIh/yjLSd6N2+H/TpXUTfM5BdXqbfr+aWKW/VCHDeBM0C AAAAAAAA --------------ms010607040905050605050609-- From nobody Fri Dec 2 00:33:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676E4129431 for ; Fri, 2 Dec 2016 00:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 jex3zza_sJT9 for ; Fri, 2 Dec 2016 00:33:25 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE8C126BF7 for ; Fri, 2 Dec 2016 00:33:24 -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=1480667604; x=1512203604; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=9TC494n/H+LCcqMOsxZ3nHD5KHHcDS9hVc94VoOxVPk=; b=1a4vOV3tR5kgNpiJljQMfxRtC34s9Hxqn6vTMgzVFjVDXMlviv98AENN cIZM1Ye7SOpib4zZmRjJ+ZW2yZfhpnN0CGDDba017vLqWqa5SP2G8BAjQ gC4pVOEPUKXgYez10fPQpkS4Bf4wXLX+seuMrGz9JIJBXdvZ0kN1atPHr 1UrBNtwNcaH69dUByuNm6Ps9ma9DLfwS/vljFUC1Pj9HLoQDykm6pFOPf zi1aXaraWqSoIbSTgZC9VsxmClRXvCYNQEf0vuvpxXVE4PFEaRL+3DSEI d5JGdcqZoI61d0M1ZqMWjrbZFWUqjV9W3P6v03Y07VDKYJVjugoXNaZc9 A==; X-IronPort-AV: E=Sophos;i="5.33,285,1477911600"; d="scan'208";a="118476200" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Dec 2016 21:33:22 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 2 Dec 2016 21:33:21 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::e4eb:6def:adaa:5544]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::e4eb:6def:adaa:5544%14]) with mapi id 15.00.1178.000; Fri, 2 Dec 2016 21:33:22 +1300 From: Peter Gutmann To: Stephen Farrell , David Benjamin , Tony Arcieri , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfD667DaatoU6RNleDGo1T66DwCVTAgAGDyICAAQa6CP//KrAAgAFpLoCAAOlzA///LIYAgABRlgCAANucOQ== Date: Fri, 2 Dec 2016 08:33:21 +0000 Message-ID: <1480667592856.97451@cs.auckland.ac.nz> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> , <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> In-Reply-To: <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> 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] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 08:33:27 -0000 Stephen Farrell writes:=0A= =0A= >IIRC that was sort-of a condition for adoption of the work in the IETF 20= =0A= >years ago, when there were two different protocols already being deployed = and=0A= >the proponents of one of them said "we'll use that other one (SSL) but you= =0A= >gotta change the name of the standard or we can't get our to agre= e=0A= >to change to all use the same thing."=0A= =0A= It was Netscape with SSL vs. Microsoft with PCT.=0A= =0A= If no-one from Microsoft has any objections, can we just rename it back to= =0A= what it's always been for everyone but us, SSL?=0A= =0A= Peter.=0A= From nobody Fri Dec 2 01:22:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70997129BAF for ; Fri, 2 Dec 2016 01:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92gnGPZwP6Pq for ; Fri, 2 Dec 2016 01:22:47 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329671295A0 for ; Fri, 2 Dec 2016 01:22:47 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id m203so1714814wma.3 for ; Fri, 02 Dec 2016 01:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9K1VILH0SnpVb1gI1Otu9J7FbSB8qNK642cUAwnxglg=; b=B/38L0lciefRuRPd6InJuPD8KHuKlJn1hcyn+bC920FUZstcq1ANAyVbabyDb8Egdx Sh876lJxOXpH96CQMH3u7xgX0Hssbyq5tJSDzKbjVzgJzzPZZdbF9edZVSCxpHAYaKra OowSgBNRa3mC6GkJJbJ3igwQ1hIi5x7w41xRstPfvJZJu6dfaOHYvxCVxVmmHmQBCoWA qhlHrQdjVEL+PMDAVEPbLO1uUuPa6wgfZxDX2OfiUVxESH7ZT78Uwj7CcXGju1CTQJMb 19bl0U4sk9I+SPJ/HiqR3flV+f14+3OjP60hvxZeT5dRCAipHMQU0/U8UL/NMMBPWxER y2Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9K1VILH0SnpVb1gI1Otu9J7FbSB8qNK642cUAwnxglg=; b=A/nNZyNmw4EFLrDtHr7fYjTkpcVjvzqcavXVLCe4symLKTJ6YiXS5h+rUVnFuQcUz5 Y83BbSxq2yWIi13IlHwZ5HWgQcemVcNsPp2/MJ23RY1RjPL6SQ52tqyPzgkhDbwqDJ+W Hwk/gWbI+IuNwdA3H0cvV0+MEeaqHeg5QTnwHg6FBZvgeEN4rZlTBkGn6bRdnNyDERsC tNlx5k7sw/sieChsBHXpGI6eZisy081rk6vWgaJEAFrsL5iaRZu+V/ew+9+W1GvDtjYs Vvn8v8JdWk0y77WVxOZ+HxXxwmXSa++qsYpvdt4jJQ3xrmXxiZExJSQBHNo5CM6lNkQU qj+g== X-Gm-Message-State: AKaTC00hWdthDwAclNzNoQorn+s2BJb1iCSl0DXKdCCq4sG+9QpD7g/sNtwZEJxhfRo0+g== X-Received: by 10.28.174.76 with SMTP id x73mr1966079wme.25.1480670565691; Fri, 02 Dec 2016 01:22:45 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id x5sm4519389wje.36.2016.12.02.01.22.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 01:22:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <1480667592856.97451@cs.auckland.ac.nz> Date: Fri, 2 Dec 2016 11:22:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <239D273F-838C-4D33-BA26-2550F8602554@gmail.com> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 09:22:49 -0000 > On 2 Dec 2016, at 10:33, Peter Gutmann = wrote: >=20 > Stephen Farrell writes: >=20 >> IIRC that was sort-of a condition for adoption of the work in the = IETF 20 >> years ago, when there were two different protocols already being = deployed and >> the proponents of one of them said "we'll use that other one (SSL) = but you >> gotta change the name of the standard or we can't get our to = agree >> to change to all use the same thing." >=20 > It was Netscape with SSL vs. Microsoft with PCT. >=20 > If no-one from Microsoft has any objections, can we just rename it = back to > what it's always been for everyone but us, SSL? Is that even possible? The way I=E2=80=99ve heard it =E2=80=9CSSL=E2=80=9D= is a registered trademark owned by Netscape (now AOL), so we can=E2=80=99= t use it unless AOL lawyers sign off on that. It might be wrong, but if = it=E2=80=99s true - good luck with that. Yoav From nobody Fri Dec 2 01:36:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01685129597 for ; Fri, 2 Dec 2016 01:36:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 NtxLwtplmVWk for ; Fri, 2 Dec 2016 01:36:16 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B80261295A0 for ; Fri, 2 Dec 2016 01:36:15 -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=1480671375; x=1512207375; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=lmvEiLNLFj67K3Fi4miKyI5LuZ5SJdpgr4/8CLfMLiY=; b=kdr54JHguvQ8Lwi43UvFPlhFwz6FzS8QpxLU0ciKqbj23FjoWHFxEUFc xojfL40oE36bdxKE45pZeUmkUEnV8pBs6y/bj+qdaEFf1lkGiO3ydGAFG PgXdHqB6CLm5C6xONHmZ+bRm9vifeTcUfCSI/GOMFqWBNvl0Lp1vkEcBP R3NkwdmoTBE4ZfbNXfvDE7Jhgz/pKo7EoXbmYJyK1fmfubh85eMtpv6vW Vevz6rJmyCzuY1t8jU9JNcaitvUJl49UiXZmE/PGXRVHtoGQssSPaPcmh BJj37NDClrVrPQrfaPSLjtlLNxUnXOtAytlPsbG73aVnEZuUEkqFQZJod A==; X-IronPort-AV: E=Sophos;i="5.33,285,1477911600"; d="scan'208";a="118481841" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-a.UoA.auckland.ac.nz) ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 02 Dec 2016 22:36:11 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 2 Dec 2016 22:36:05 +1300 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::e4eb:6def:adaa:5544]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::e4eb:6def:adaa:5544%14]) with mapi id 15.00.1178.000; Fri, 2 Dec 2016 22:36:05 +1300 From: Peter Gutmann To: Yoav Nir Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfD667DaatoU6RNleDGo1T66DwCVTAgAGDyICAAQa6CP//KrAAgAFpLoCAAOlzA///LIYAgABRlgCAANucOf//M/WAABtsCyk= Date: Fri, 2 Dec 2016 09:36:04 +0000 Message-ID: <1480671356453.36142@cs.auckland.ac.nz> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz>, <239D273F-838C-4D33-BA26-2550F8602554@gmail.com> In-Reply-To: <239D273F-838C-4D33-BA26-2550F8602554@gmail.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="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 09:36:18 -0000 Yoav Nir writes:=0A= =0A= >The way I=92ve heard it =93SSL=94 is a registered trademark owned by Netsc= ape (now=0A= >AOL), so we can=92t use it unless AOL lawyers sign off on that. It might b= e=0A= >wrong, but if it=92s true - good luck with that.=0A= =0A= http://tmsearch.uspto.gov/bin/showfield?f=3Dtoc&state=3D4810%3Ajoxwrl.1.1&p= _search=3Dsearchss&p_L=3D50&BackReference=3D&p_plural=3Dyes&p_s_PARA1=3D&p_= tagrepl%7E%3A=3DPARA1%24LD&expr=3DPARA1+AND+PARA2&p_s_PARA2=3Dssl&p_tagrepl= %7E%3A=3DPARA2%24COMB&p_op_ALL=3DAND&a_default=3Dsearch&a_search=3DSubmit+Q= uery&a_search=3DSubmit+Query =0A= =0A= http://tmsearch.uspto.gov/bin/showfield?f=3Dtoc&state=3D4805%3A16epd1.1.1&p= _search=3Dsearchstr&BackReference=3D&p_L=3D100&p_plural=3Dyes&p_s_PARA1=3DS= SL&p_tagrepl%7E%3A=3DPARA1%24ALL&expr=3DPARA1+and+PARA2&p_s_PARA2=3Dsecurit= y&p_tagrepl%7E%3A=3DPARA2%24ALL&a_default=3Dsearch&f=3Dtoc&state=3D4805%3A1= 6epd1.1.1&a_search=3DSubmit+Query=0A= =0A= http://tmsearch.uspto.gov/bin/showfield?f=3Dtoc&state=3D4805%3A16epd1.4.1&p= _search=3Dsearchstr&BackReference=3D&p_L=3D100&p_plural=3Dyes&p_s_PARA1=3D%= 22secure+sockets+layer%22&p_tagrepl%7E%3A=3DPARA1%24ALL&expr=3DPARA1+or+PAR= A2&p_s_PARA2=3D&p_tagrepl%7E%3A=3DPARA2%24ALL&a_default=3Dsearch&f=3Dtoc&st= ate=3D4805%3A16epd1.4.1&a_search=3DSubmit+Query=0A= =0A= Doesn't look like it. And even if it was, Netscape's failure to defend it= =0A= against infringement by half the planet would probably make its enforceabil= ity=0A= dubious.=0A= =0A= Peter.=0A= =0A= From nobody Fri Dec 2 01:38:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3669D129BBB for ; Fri, 2 Dec 2016 01:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KU_CqkohqQiD for ; Fri, 2 Dec 2016 01:38:48 -0800 (PST) Received: from mx496502.smtp-engine.com (mx496502.smtp-engine.com [IPv6:2001:8d8:968:7d00::19:7e53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFB0C129BB4 for ; Fri, 2 Dec 2016 01:38:48 -0800 (PST) Received: from mail-io0-f180.google.com (mail-io0-f180.google.com [209.85.223.180]) by mx496502.smtp-engine.com (Postfix) with ESMTPSA id 780FC7D3 for ; Fri, 2 Dec 2016 09:38:42 +0000 (GMT) Received: by mail-io0-f180.google.com with SMTP id m5so334271865ioe.3 for ; Fri, 02 Dec 2016 01:38:42 -0800 (PST) X-Gm-Message-State: AKaTC01yE1JS6rwMgO9CnTmK3UznIlZhRt4E8rdYcwnE8TDOkuqRGCVKgGXVqkBqRD10u0D5xytM3+DdTUWhoA== X-Received: by 10.107.57.193 with SMTP id g184mr38872584ioa.183.1480671520875; Fri, 02 Dec 2016 01:38:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.14.73 with HTTP; Fri, 2 Dec 2016 01:38:40 -0800 (PST) In-Reply-To: <239D273F-838C-4D33-BA26-2550F8602554@gmail.com> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> <239D273F-838C-4D33-BA26-2550F8602554@gmail.com> From: Matt Caswell Date: Fri, 2 Dec 2016 09:38:40 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 09:38:51 -0000 On 2 December 2016 at 09:22, Yoav Nir wrote: > >> On 2 Dec 2016, at 10:33, Peter Gutmann wrote= : >> >> Stephen Farrell writes: >> >>> IIRC that was sort-of a condition for adoption of the work in the IETF = 20 >>> years ago, when there were two different protocols already being deploy= ed and >>> the proponents of one of them said "we'll use that other one (SSL) but = you >>> gotta change the name of the standard or we can't get our to a= gree >>> to change to all use the same thing." >> >> It was Netscape with SSL vs. Microsoft with PCT. >> >> If no-one from Microsoft has any objections, can we just rename it back = to >> what it's always been for everyone but us, SSL? > > Is that even possible? The way I=E2=80=99ve heard it =E2=80=9CSSL=E2=80= =9D is a registered trademark owned by Netscape (now AOL), so we can=E2=80= =99t use it unless AOL lawyers sign off on that. It might be wrong, but if = it=E2=80=99s true - good luck with that. It does not appear on this list of AOL trademarks: http://legal.aol.com/trademarks/ Searching here does not turn up any relevant *registered* trademarks: http://tmsearch.uspto.gov/bin/showfield?f=3Dtoc&state=3D4803%3Aaagjih.1.1&p= _search=3Dsearchss&p_L=3D50&BackReference=3D&p_plural=3Dyes&p_s_PARA1=3D&p_= tagrepl~%3A=3DPARA1%24LD&expr=3DPARA1+AND+PARA2&p_s_PARA2=3DSSL&p_tagrepl~%= 3A=3DPARA2%24COMB&p_op_ALL=3DAND&a_default=3Dsearch&a_search=3DSubmit+Query= &a_search=3DSubmit+Query It does not appear to be a current trademark if it ever was one. IANAL but IIUC a trademark is only valid for as long as it is in use and defended. Matt From nobody Fri Dec 2 03:14:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D45129C84 for ; Fri, 2 Dec 2016 03:14:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gC_J_AnY0C5h for ; Fri, 2 Dec 2016 03:14:23 -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 86F99129D48 for ; Fri, 2 Dec 2016 03:11:32 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 35CE4C008B0C; Fri, 2 Dec 2016 11:11:32 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2BBUdf009289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Dec 2016 06:11:31 -0500 From: Hubert Kario To: tls@ietf.org Date: Fri, 02 Dec 2016 12:11:30 +0100 Message-ID: <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.10-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <1480648354917.41781@cs.auckland.ac.nz> References: <1480648354917.41781@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1612505.uFjZB5IWIz"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Fri, 02 Dec 2016 11:11:32 +0000 (UTC) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 11:14:30 -0000 --nextPart1612505.uFjZB5IWIz Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 2 December 2016 03:12:41 CET Peter Gutmann wrote: > Tony Arcieri writes: > >There's already ample material out there (papers, presentations, mailing > >list discussions, etc) which talks about "TLS 1.3". >=20 > In other words, the TLS WG and a small number of people who interact with= it > call it TLS 1.3. That's hardly a strong argument when most of the rest of > the world doesn't even call it TLS. >=20 > In fact that's something that's come up repeatedly in the bikeshedding so > far, there are some really good, sound arguments for calling it TLS/SSL 4 > or TLS/SSL 2017, while pretty much the only reasons I've seen for TLS 1.3 > are inertia, "we've always called it that"/"I don't want to change"/etc. People already know that SSL3 is worse than "SSL" 1.0 though 1.2 , it's=20 logical that SSL 1.3 continues that trend. creating "SSL" 4 will bring more= =20 confusion. In 10 years time, when the only way for you to get anything that can talk S= SL=20 3 is to run EOL software and hardware, then we can create "SSL" 4. But not= =20 when one fifth of the Internet still supports SSL 3. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1612505.uFjZB5IWIz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYQVbiAAoJEJKo0bgB0vX1JO8P/icYb8vSyCA/ow2yetdN3vzf CwuYhPk0k9h2FqUd/MoPMZYaUmus82YM42dvhFej/ihrgzouw2JDxVtIbE8VqSe7 toHipyqetJAbQ745Y0QJipxsZuoqL8dosxyU6YBYq7gEb4p35Y7Y4rNpsVCACw4C p6ZlRGdvyc0GKEHIz0+MWsC6EGXUBeEm/6TIicwChAm9EEEfe4SQrSjTtdJrgnRM 5KaTbB2BYxTyNCiJlG8d2p3u/TdUviIx2E/GQOS5NFXKKKF9IcDNon+xz46up7mG zKERX+m8sd4QVlJATjcyraAEyAQYZeD4ujy9OAsLRLHPpbFZmyFqO5Wop21XFzDQ BexbvhaQ7q+7K2U8lRAWiYO41bOcM1u3LKgoxGtUlm9lkOqaKZ18cvktlkjqjEOJ zcVPdGbjkfpoONTuToSrmRXbP97F1rFQeedQ6ZPKQeB1/1kg6vqLiWdPmwiHw57J r46k9C9LN13hZpXdp8IPVUolA3CXaEgEAzd8mYlBXd1/9G6FNX6RAjz3xs+5QZ9l 8KAyxGhdQk8CqLdd4agaP5pyv8Nbp4E3SKASpF5YJTzw0ZFhoXVDsDm8XYHdVWAE nGMFZAUKkVw5ggBCHAXZ9T2BREReIhJZmKqtsPHXCShQUnAgpRPnkQ4mDXNqRhBS 7W+n0p4rOny++rL3dMtG =rDTz -----END PGP SIGNATURE----- --nextPart1612505.uFjZB5IWIz-- From nobody Fri Dec 2 05:47:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB09129FA4 for ; Fri, 2 Dec 2016 05:47:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRLeqJeCDexc for ; Fri, 2 Dec 2016 05:47:43 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF9F129C66 for ; Fri, 2 Dec 2016 05:47:21 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C468F43346B; Fri, 2 Dec 2016 13:47:20 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AB280433462; Fri, 2 Dec 2016 13:47:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480686440; bh=QRZXEdeWHnTct7GeR8lFAuvzvZ9EK/mKiLylvRBDDVY=; l=432; h=From:To:Date:References:In-Reply-To:From; b=hOOZEFryz8ZpSGI0J4rhel3PGZdgU8dZOP/dXUTvucWnRLhXCLFjga/EHTmFyIt0q Zu/3EOO+ueTYd/17zWX8fDlXODPHLg2r9rHo+oDfrYeAI2Eot8Z7lTeKwUrIeIdauk W+5WwH+W8m98NYde+vQhzfGAulilWIZoHGFa+1NQ= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 9FD141FC8D; Fri, 2 Dec 2016 13:47:20 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 2 Dec 2016 08:47:19 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 2 Dec 2016 08:47:20 -0500 From: "Salz, Rich" To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDwX4eAgAJbVYCAAC0nAIAABEIAgAFpLoCAAA++gIAAhccA///XiQA= Date: Fri, 2 Dec 2016 13:47:20 +0000 Message-ID: <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1480648354917.41781@cs.auckland.ac.nz> <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> In-Reply-To: <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 13:47:46 -0000 PiBQZW9wbGUgYWxyZWFkeSBrbm93IHRoYXQgU1NMMyBpcyB3b3JzZSB0aGFuICJTU0wiIDEuMCB0 aG91Z2ggMS4yICwgaXQncyBsb2dpY2FsDQo+IHRoYXQgU1NMIDEuMyBjb250aW51ZXMgdGhhdCB0 cmVuZC4gY3JlYXRpbmcgIlNTTCIgNCB3aWxsIGJyaW5nIG1vcmUgY29uZnVzaW9uLg0KDQpQbGVh c2UgZXhwbGFpbiB0aGF0IGFzc2VydGlvbi4NCg0KLS0gIA0KU2VuaW9yIEFyY2hpdGVjdCwgQWth bWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpA amFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQo= From nobody Fri Dec 2 06:00:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45724129FA1 for ; Fri, 2 Dec 2016 06:00:14 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-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 4xDGcGNf4qap for ; Fri, 2 Dec 2016 06:00:07 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819121296D3 for ; Fri, 2 Dec 2016 06:00:07 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id t196so196213692lff.3 for ; Fri, 02 Dec 2016 06:00:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ox4oJPggP8v/QGsC78lO/RZv691LREztfX14BCYDbrs=; b=eQUvN+/IrVHUwbMscfWwRpEd/XycXEs8boQD3OrNrmkf7fmKAvUuD3JoJPfoyWg+rw W9qDjJ/84Ay6UZbZu81cUmPmkPzXWuKEgPQYG+BQ1jcFtTIhuR2yqMq5DBDm7TrXjpTO CbWiUyRVqYVTY8m6nUBAgs1Ti3xu/16XBFmKxegfeEsemuqUZ82vjqjbqRg0Chb3Deat u52j7uH0BQbUyY8OqIuWpvR9EdOTkStxjwLesR+BgemgHYVXbUD5LyFydPk/3Iq+F0nO O8P1GzilybJTXVh5EEkWb6LgcNwLJxDFr6OlgGaUB3lBRvECMCqCqSWUUQmm8sqiJcHD 5JKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ox4oJPggP8v/QGsC78lO/RZv691LREztfX14BCYDbrs=; b=BPF2Dt/b+mipNFqfqaV+nKua6qKDRnumhmsCZB/UvZpYlFDGgslhM4R+qFf+LEfFHA nvLIFeUnZjZiodtm3cduWhI4TXNWbEtEwervduh2M4EniE5OAjAsGzXC7xmqQxebnhvJ O/0qGiHmfvEMBLTv0OjP6EQxVij6OfVO6Dvp7/6fqBJWffLenLfAuBByo9KnDA1tmmW+ 8CbE0PBQXmqs/itI4tFIUSBn0mKJj10hWM4LK7cLwE/adMCbdo6FUwFhHPOhZEbcPbGN Z56ednybU3Hd6vo/nbUMxNOMMQHk0R4nWfArQCVqIhFetBsFGM6ym78YSl9+VacXybjr AFFA== X-Gm-Message-State: AKaTC0354peU1JaujH1PAqeymcT2QAW3uoyGiURjs+yJsU4LZSe8EuS+s/Zxve+XcvuUIYUo4UtAlogIh24sWA== X-Received: by 10.25.190.79 with SMTP id o76mr17015924lff.56.1480687205678; Fri, 02 Dec 2016 06:00:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.63.132 with HTTP; Fri, 2 Dec 2016 05:59:25 -0800 (PST) In-Reply-To: <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1480648354917.41781@cs.auckland.ac.nz> <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> From: Ted Lemon Date: Fri, 2 Dec 2016 08:59:25 -0500 Message-ID: To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:00:14 -0000 Rich, I don't think there is any explanation that can be given for the assertion without collecting a lot of data. That said, the objection makes sense to me. I certainly think of SSL as poison. Of course, the average Joe on the street doesn't even know what TLS stands for, but the people who are deciding what software to run do. In that audience, adding confusion with a new name change is probably bad. So what Hubert said seems self-evident to me, not requiring any explanation. On Fri, Dec 2, 2016 at 8:47 AM, Salz, Rich wrote: >> People already know that SSL3 is worse than "SSL" 1.0 though 1.2 , it's logical >> that SSL 1.3 continues that trend. creating "SSL" 4 will bring more confusion. > > Please explain that assertion. > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Dec 2 06:04:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCFC81296AF for ; Fri, 2 Dec 2016 06:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFjVkI-5o71s for ; Fri, 2 Dec 2016 06:04:42 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id CDCF51296D3 for ; Fri, 2 Dec 2016 06:04:38 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 37203433455; Fri, 2 Dec 2016 14:04:38 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 211D7433451; Fri, 2 Dec 2016 14:04:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480687478; bh=KzyxuV6zm9+UVdZTErJ+wCV7a+RRkAt27bHYzIuZ+hE=; l=822; h=From:To:CC:Date:References:In-Reply-To:From; b=wJaHoBJqbFyCH4mpI1NFyTpcf6kGJpVJmvfgkIAhu5+PA1Vnqi02H5VKqNGzm0UuT y8V1JD+H1sEBXH1QgnYwkqyfltPGOIHiIHyp5QL0kSrARZuqbJH3Tyo1r7wVbcZir1 HUsKUBdyO9DATTdlf4a1uneHdczfIfuCBC1LpY2M= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 10D5F1FC8E; Fri, 2 Dec 2016 14:04:38 +0000 (GMT) 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.1178.4; Fri, 2 Dec 2016 06:04:37 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 2 Dec 2016 09:04:37 -0500 From: "Salz, Rich" To: Ted Lemon Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDwX4eAgAJbVYCAAC0nAIAABEIAgAFpLoCAAA++gIAAhccA///XiQCAAFdigP//rM+w Date: Fri, 2 Dec 2016 14:04:36 +0000 Message-ID: <62b7b7b016d94bd68e17cc6c81306b05@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1480648354917.41781@cs.auckland.ac.nz> <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:04:44 -0000 Tm9ib2R5IGtub3dzIHRoZSBkaWZmZXJlbmNlIHR3ZWVuIDEuMCAxLjEgMS4yDQoNClNTTCA0IG9y IFNTTCA0LjAgaXMgYSBiaWdnZXIgbnVtYmVyIHRoYW4gMS54IGFuZCB1c2VzIHRoZSBzYW1lIHRl cm0gdGhhdCBldmVyeW9uZSwgaW5jbHVkaW5nIG91ciBpbmR1c3RyeSwgdXNlcy4gIElmIHNvbWVv bmUgc2VlcyAiVExTIDEuMiIgYW5kIHRoaW5rcyAid293LCB0aGF0J3Mgc28gbXVjaCB3b3JzZSB0 aGFuIFNTTCA0IGJlY2F1c2UgdGhlIG51bWJlciBpcyBzbyBtdWNoIHNtYWxsZXIsIiB0aGVuIGlz bid0IHRoYXQgYSBnb29kIHRoaW5nLCBpbmNyZWFzaW5nIHByZXNzdXJlIHRvIG1vdmUgZm9yd2Fy ZD8NCg0KSSB3b3VsZCBtdWNoIHJhdGhlciBzcGVuZCB0aW1lIGV4cGxhaW5pbmcgIm5vLCByZWFs bHkgVExTIDEuMiBpcyBub3QgdGhhdCBiYWQiIHRoYW4gaGF2ZSB0byBzcGVuZCBtb3JlIGRlY2Fk ZXMgZXhwbGFpbmluZyAibm8sIHJlYWxseSwgdGhhdCB0aGluZyB0aGUgd29ybGQgdGhpbmdzIG9m IGFzIFNTTCBpcyByZWFsbHkgVExTIGFuZCAxLjMgaXMgcmVhbGx5IGJldHRlciB0aGFuIHdoYXQg eW91IHRoaW5rIHlvdSBzaG91bGQgaGF2ZS4iDQo= From nobody Fri Dec 2 06:06:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04E77129689 for ; Fri, 2 Dec 2016 06:06:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dof4ul8xZCt4 for ; Fri, 2 Dec 2016 06:06:43 -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 E9776127071 for ; Fri, 2 Dec 2016 06:06:42 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A3AF2C0AD40B; Fri, 2 Dec 2016 14:06:42 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2E6fMI014615 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Dec 2016 09:06:42 -0500 From: Hubert Kario To: "Salz, Rich" Date: Fri, 02 Dec 2016 15:06:40 +0100 Message-ID: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.10-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3349477.gij29N6bkr"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 02 Dec 2016 14:06:42 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:06:46 -0000 --nextPart3349477.gij29N6bkr Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 2 December 2016 13:47:20 CET Salz, Rich wrote: > > People already know that SSL3 is worse than "SSL" 1.0 though 1.2 , it's > > logical that SSL 1.3 continues that trend. creating "SSL" 4 will bring > > more confusion. >=20 > Please explain that assertion. SSL 2 < SSL 3 < "SSL" 1.0 < "SSL" 1.1 < "SSL" 1.2 < "SSL" 4 is not logical ordering =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart3349477.gij29N6bkr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYQX/wAAoJEJKo0bgB0vX1904P/11UOusf8ZemqYuck0h8gz5I mCTBdYr0WIXkz1Z7gmOltzaOfjJ30hJW9MGNqwba48xgIqcIOx/mnfVou+bucrqO H6ZxnZIpamhxkjsllxHf0Vr7Z3QhdIXP/OiLmQN1Vm+eyZvJgSCqn4onvVtHf4kt ovr1sq5dH+X8VezXPdA27H2JsO12MNzfi/NvSNamepXG4APFGNv20cRiyGHfIdzy KMqAGETc+62bWTMycCdAZSvDIcFskYnlA9hQmQTNQxIy3wFKkSoZrD0kqa0DeqBI aUKnfwbHJJRjBxL7HYiIZuBN9gx05zuE2gS4r6yfAW7YQIdW6DyO7t9GFLKW9DhV Tunwuz7hErkzoHVTNgiLvwYbstX41MO7grnpvFZQ4p65cbX6aTlSE7VHhSsAY50U VLp08wQoyW8iyWd6jrLoBZQf83YbZmUWMskD9lGRRLpgmtn1cvCeWZqJB85bJMWf Tmcat7l18ppvR8gCtuHQvWgSz7msjqlwtGkMsIdDdAA4TVk13GgvREWMUCR4Nixs r51lO0wecUPRYctiPByfFDTOi3lihqp4LNXZk+kR265LAPf7wvfZFXHiGl5/seNz rMI0ObgQvwa8Cia+91AwoyjZldIOhgBHX5oqLURRi9XHcYFISdYTAuAGweZRBfZ6 Vx0uZAbxstDDFLb9u+Ir =KOrr -----END PGP SIGNATURE----- --nextPart3349477.gij29N6bkr-- From nobody Fri Dec 2 06:12:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44F01294C0 for ; Fri, 2 Dec 2016 06:12:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gYCZrPa3-R5 for ; Fri, 2 Dec 2016 06:12:40 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E08CF1294BF for ; Fri, 2 Dec 2016 06:12:39 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 90D5443346B; Fri, 2 Dec 2016 14:12:39 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 7AD93433407; Fri, 2 Dec 2016 14:12:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480687959; bh=Zty/PfarZ09pBM6tHgpwdEQKSdqsb83o2nZGPWqXpc4=; l=954; h=From:To:CC:Date:References:In-Reply-To:From; b=kQAy527hK7yLzwQ/knAdgsOMBSfkmI+ACAsdgtkjKso/UWHJZC5Sd2P2rEU2SVgkB YqumSb3cbU8qtARoHgHy1Psrl7crYdqeCrduXXqV7pfrYKZebWOXvNBsp35SCIxUWX iytA6JDwgEXiULxmUeHafft3IXvX8XS8eijkO1QE= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 77ADD1FC8C; Fri, 2 Dec 2016 14:12:39 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 2 Dec 2016 09:12:39 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 2 Dec 2016 09:12:39 -0500 From: "Salz, Rich" To: Hubert Kario Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDwX4eAgAJbVYCAAC0nAIAABEIAgAFpLoCAAA++gIAAhccA///XiQCAAFloAP//rJxQ Date: Fri, 2 Dec 2016 14:12:38 +0000 Message-ID: <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> In-Reply-To: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.174] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:12:41 -0000 PiBTU0wgMiA8IFNTTCAzIDwgIlNTTCIgMS4wIDwgIlNTTCIgMS4xIDwgIlNTTCIgMS4yIDwgIlNT TCIgNCBpcyBub3QgbG9naWNhbCBvcmRlcmluZw0KDQpTbz8gIFdobyBjYXJlcz8gIEEgY291cGxl LWh1bmRyZWQgcGVvcGxlIGluIHRoZSBJRVRGLiAgQW5kIHRoZSBpc3N1ZSBpcyB0aGF0IFNTTCAz IDwgIlNTTCIgMS4wIHdoaWNoIGlzIHRoZSBpc3N1ZSBubyBtYXR0ZXIgd2hhdCB3ZSBjYWxsIHdo YXQgd2UncmUgZG9pbmcgaGVyZS4gIEFuZCB0aGUgcXVvdGVzIGFyb3VuZCB0aGUgbGFzdCBTU0wg ZG8gbm90IGJlbG9uZyB0aGVyZS4NCg0KWW91IGNhbiBzYXkgdGhhdCBjYWxsaW5nIGl0ICJUTFMg MS4zIiBwcm9tdWxnYXRlcyB0aGUgaWxsb2dpY2FsIG9yZGVyaW5nLCBvciB5b3UgY291bGQgc2F5 IGl0IGNvbnRpbnVlcyBhIHJlbnVtYmVyaW5nLiAgQSByZW51bWJlcmluZyB0aGF0IHRoZSB3b3Js ZCBoYXMgbmV2ZXIgcmVjb2duaXplZCBvciB1bmRlcnN0b29kLiAgWW91IGNhbiBzYXkgdGhhdCAi U1NMIDQiIGNvbmZ1c2VzIHBlb3BsZSB0d2ljZSwgb3IgeW91IGNhbiBzYXkgdGhhdCBpdCByZXN0 b3JlcyBzYW5pdHkgdG8gYSAyMC15ZWFyIGdsaXRjaCBhbmQgc3RhcnRzIHVzIHVzaW5nIHRoZSBz YW1lIG5hbWUgdGhhdCB0aGUgcmVzdCBvZiB0aGUgd29ybGQsICphbmQgb3VyIGluZHVzdHJ5LCog dXNlcy4NCg0KDQo= From nobody Fri Dec 2 06:13:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D191296DD for ; Fri, 2 Dec 2016 06:13:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 55_kT-UufCfi for ; Fri, 2 Dec 2016 06:12:59 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADD411294BF for ; Fri, 2 Dec 2016 06:12:58 -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=1480687978; x=1512223978; h=from:to:date:message-id:in-reply-to:references:subject: mime-version:content-transfer-encoding; bh=RTs2cdQbm/dZk84S8v3CRyrkOKNXp8UJYnPDUbj+Ilo=; b=WdeoQGZwqf717onUc4sspo734QM5vu+WQTwtTm9vrOtAEW3SXCI0hn0M PKf8DUhRLR6R1cDofO+uxcjJ5MWvnbjvnk3Iadk+39lHX+0Ic+qCW4bAq 3OntRcXgFHkgQrVI/DwUHzKeG/VOUyuluANo0orgQ+ok9N7dQnKX3KAzz fng9kxUhQVOU2Icn9JccCFeob7T/+s15DEaRGZOi7Jhw3xrQKdK2fMkao VkRA6xEoHWKOAr3mc059FzgbrpOaB06MiP/mLFG6opBio/wGNNTb960RC bA4J35pNtgJaJUb7Kmx0idghPX5veT4MVooZN89WgdYJGlGt/1x8U6kZF g==; X-IronPort-AV: E=Sophos;i="5.33,729,1477911600"; d="scan'208";a="118512345" X-Ironport-HAT: None - $RELAY-AUTH X-Ironport-Source: 14.1.79.23 - Outgoing - Outgoing-SSL Received: from 14-1-79-23.worldnet.co.nz (HELO [192.168.1.35]) ([14.1.79.23]) by mx4-int.auckland.ac.nz with ESMTP; 03 Dec 2016 03:12:54 +1300 From: Peter Gutmann To: "Salz, Rich" , Hubert Kario , Date: Sat, 03 Dec 2016 03:12:52 +1300 Message-ID: <158bfe16ea0.2767.b9f769d0c6fd5b2dd1c91644b008d34c@cs.auckland.ac.nz> In-Reply-To: <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1480648354917.41781@cs.auckland.ac.nz> <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:13:01 -0000 "Salz, Rich" writes: >>People already know that SSL3 is worse than "SSL" 1.0 though 1.2 , it's logical >>that SSL 1.3 continues that trend. creating "SSL" 4 will bring more confusion. > >Please explain that assertion. I was going to ask that too, the quoted text seems..., well, gibberish to me. Peter. From nobody Fri Dec 2 06:14:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B45129537 for ; Fri, 2 Dec 2016 06:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GfYusClcpCA for ; Fri, 2 Dec 2016 06:14:54 -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 CEB001294D5 for ; Fri, 2 Dec 2016 06:14:54 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 951E83A27C; Fri, 2 Dec 2016 14:14:54 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2EErZE021196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Dec 2016 09:14:54 -0500 From: Hubert Kario To: "Salz, Rich" Date: Fri, 02 Dec 2016 15:14:52 +0100 Message-ID: <2372388.z3ZTS2GYoM@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.10-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <62b7b7b016d94bd68e17cc6c81306b05@usma1ex-dag1mb1.msg.corp.akamai.com> References: <62b7b7b016d94bd68e17cc6c81306b05@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart12570294.UGlBU2NpWh"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Fri, 02 Dec 2016 14:14:54 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:14:56 -0000 --nextPart12570294.UGlBU2NpWh Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 2 December 2016 14:04:36 CET Salz, Rich wrote: > Nobody knows the difference tween 1.0 1.1 1.2 >=20 > SSL 4 or SSL 4.0 is a bigger number than 1.x and uses the same term that > everyone, including our industry, uses. If someone sees "TLS 1.2" and > thinks "wow, that's so much worse than SSL 4 because the number is so much > smaller," then isn't that a good thing, increasing pressure to move > forward? Or he thinks "stupid 'experts' pushing stuff down our throats by inflating= =20 numbers". Certainly not all of them will think the same thing. =20 > I would much rather spend time explaining "no, really TLS 1.2 is not that > bad" than have to spend more decades explaining "no, really, that thing t= he > world things of as SSL is really TLS and 1.3 is really better than what y= ou > think you should have." Except in 10 years we may be explaining that "no, TLS 1.3/2.0/4/2017 alone = is=20 completely insecure, you need to deploy post-quantum crypto on TLS=20 1.2/2.0/4/2017" =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart12570294.UGlBU2NpWh Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYQYHcAAoJEJKo0bgB0vX1bA4P/2hUtP9wE9jqjabZB+WIJhpH XUx+ShWgcP5RK1bAMCRm0RAqL50N2bKWR2KN7ylIG9fXt9W1TU3rjd61zt9BJDVX ccglszqlRkQMWKjn0fZj/QSMJY+qX9jrBqbPiVw6C/hroy5/yjCTJv/rm1EJGi6r pSx96oDthH3n0vn7PRhf6Ifrth5T14Fuqg0AJrdlNbDh4SomVBb3jZivBD57gsun en1gzb0BhoKbJNJSlMJg4xCcIyMsT/8IP82+/yS4+ww0+bsuKx4QgXQ3o5ScbD30 Vln2vP1GgrQ9Vi8DgWs82hsF/wy3pFFJOw4va4Nd4nW5ovcI0FHNopoisOFq8ayJ C3KH1zJRqMDpaRJ7Wvy+gEFQPmmlHQzHG2xXE0ERPHmpZ5ZpLLlLjrrhYrt5B0Ao JHRIgJFCJ8oSYf/MRm5lLrxSJIrmj7QtSFKtjPM3lUbZ2Ax8R02DFaGtWUWP0O/m Xf8zsikyrXdRhW4+a+o4Y19fD+uCLuZwV+ket6NHGaU9shezfG0MGlyQy6Q+Af5h EWczted9Oo1SkdUMDMu9jICl/P2d7s2o1vMd/vDtrMWz9lO55Fk82WVZtWSdfYdj lPVMqM1km3G/2sVEoruVtGUs//amFWtInfSmZy7BjgPD7Dvoko9m6JQVSOZmyD6y 6u8X9Xw33oBqP6XzraLu =DqiU -----END PGP SIGNATURE----- --nextPart12570294.UGlBU2NpWh-- From nobody Fri Dec 2 06:19:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F551296F2 for ; Fri, 2 Dec 2016 06:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.092 X-Spam-Level: X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8FuleLGZN8C for ; Fri, 2 Dec 2016 06:19:31 -0800 (PST) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A4DE1296BB for ; Fri, 2 Dec 2016 06:19:30 -0800 (PST) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id 61F201C1901 for ; Fri, 2 Dec 2016 08:19:30 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id E09F01C184F; Fri, 2 Dec 2016 08:19:29 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C315692057; Fri, 2 Dec 2016 09:09:39 -0500 (EST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 72EC49206F; Fri, 2 Dec 2016 09:09:39 -0500 (EST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (unknown [216.32.181.177]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Fri, 2 Dec 2016 09:09:39 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=tkOLzVgooxXZXm/a8fEaowNF5N7g7cy0i/I406mtizM=; b=tqGh06JQmpmQkYU0l3umSgRazXOB0V8AsEhPPGrEmaBozkW79nWnKaeCx2DrPSUjaswncvX7yAMFRnutfjBI73GfxjKqZxd+D3Utd3/MRbhTqtmJGGkx76Q3NIwxQf39vQS4foPvc4lOaoLBQa5w1+ukBdz2E30Em0B7c9dm88w= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1367.namprd14.prod.outlook.com (10.172.158.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Fri, 2 Dec 2016 14:17:24 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.0761.012; Fri, 2 Dec 2016 14:17:24 +0000 From: "Ackermann, Michael" To: Ted Lemon , "Salz, Rich" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFbDwnoZvNGaEa/4tBFYw2nKKDwC7aAgAJbVICAAC0oAIAABEIAgAFpLoCAAA+9gIAAhcgAgAArigCAAANggIAABCng Date: Fri, 2 Dec 2016 14:17:24 +0000 Message-ID: References: <1480648354917.41781@cs.auckland.ac.nz> <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com; x-originating-ip: [167.242.50.39] x-ms-office365-filtering-correlation-id: abfbeac8-38cc-4a88-ce25-08d41abdeff6 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR14MB1367; x-microsoft-exchange-diagnostics: 1; CY4PR14MB1367; 7:Pbnjp4jnIpG4TCJPSwRk86xsXMcuvAj0Urkd73F2c06Lk9KrA2sD1QfY5NIbx11DnedFFo2SNyVWkpSxM4YU1oKAJs5Z/HHCX9p6EuLyLj7Df+VFkGFPVgZy4DEYCjyWkjWvVWC8UlkqpNDPhcr1+X1oCo+PUYSIJUl/Cni6+ZNxVG458HvmzhP9x+vPfTbglS8+UBD6qvrq/MNeZZyEO4OUy66qkrgr9uKnmJxEh27te67NfE06Xd4oR3ZCu60g1ymugoszHpjFTMHAqCRcuGbf6l8+qxzdo/cccxia1dWwcCczvvymuNQExqMfYwkG2c5NDhZa38T11spOEKf+NN1WKLMWCCKSfckEYO9Bej3y0Pti3nsWKP+nkwjP//Pcap8cLrm9eM0I++S8HqQxUDk75Bjlp+YKUGnEp/M2TICwzj3/VtfTcBM7Gk0ymOB6Cz4hxy6iR85RGBZaDo8yEg==; 20:wyzDBb5f4c7ElLsWAwEOqOdQa/lNM7JKk4TkeyHpk5PhR9jPuK/MFJANo0NLDJHqA0zMcSHHfNc7w9TI6sjmrgNf3tzuG7W2RRzS3gD9SoQOFMp9O1girCRsW1Gjcen5UEeI3Q9v5q5X2tHkUXOPB0hzkplP3G4PK4nFuu3F08g= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(148322886591682)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(2016111802025)(6043046)(6072148); SRVR:CY4PR14MB1367; BCL:0; PCL:0; RULEID:; SRVR:CY4PR14MB1367; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(24454002)(199003)(189002)(377454003)(8676002)(93886004)(80792005)(6506004)(101416001)(7736002)(97736004)(5001770100001)(76576001)(305945005)(76176999)(7846002)(74316002)(50986999)(54356999)(229853002)(7696004)(5660300001)(77096006)(68736007)(3280700002)(92566002)(39410400001)(8936002)(86362001)(99286002)(39450400002)(33656002)(38730400001)(106116001)(2950100002)(4326007)(6116002)(105586002)(81156014)(9686002)(81166006)(2906002)(122556002)(102836003)(3846002)(3660700001)(66066001)(106356001)(2900100001)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1367; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.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: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2016 14:17:24.2652 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1367 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 6be06de7-d41b-4d02-a94a-06008ee2ede4 X-VPM-MSG-ID: a95c5d08-4263-4218-a690-92371388b8ca X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:19:35 -0000 +1 On Ted's comments.=20 In Enterprise circles TLS is an unknown acronym and as painful as it is, = we must usually refer to it as SSL, before anyone knows what we are = talking about. =20 Software products are guilty too. Parameter fields frequently reference = SSL. :( -----Original Message----- From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Ted Lemon Sent: Friday, December 2, 2016 8:59 AM To: Salz, Rich Cc: tls=40ietf.org Subject: Re: =5BTLS=5D Confirming consensus: TLS1.3->TLS* Rich, I don't think there is any explanation that can be given for the assertion without collecting a lot of data. That said, the objection makes sense to me. I certainly think of SSL as poison. Of course, the average Joe on the street doesn't even know what TLS stands for, but the people who are deciding what software to run do. In that audience, adding confusion with a new name change is probably bad. So what Hubert said seems self-evident to me, not requiring any explanation. On Fri, Dec 2, 2016 at 8:47 AM, Salz, Rich wrote: >> People already know that SSL3 is worse than =22SSL=22 1.0 though 1.2 ,=20 >> it's logical that SSL 1.3 continues that trend. creating =22SSL=22 4 = will bring more confusion. > > Please explain that assertion. > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz=40jabber.at Twitter: RichSalz=20 > _______________________________________________ > TLS mailing list > TLS=40ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. From nobody Fri Dec 2 06:51:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB8E129459 for ; Fri, 2 Dec 2016 06:51:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxiXgoInnbJm for ; Fri, 2 Dec 2016 06:51:03 -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 769AC1294D4 for ; Fri, 2 Dec 2016 06:42:33 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3A9C890227; Fri, 2 Dec 2016 14:42:33 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2EgV8Y019553 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Dec 2016 09:42:32 -0500 From: Hubert Kario To: "Salz, Rich" Date: Fri, 02 Dec 2016 15:42:31 +0100 Message-ID: <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.10-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart52903866.TI6NV36Sul"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 02 Dec 2016 14:42:33 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:51:04 -0000 --nextPart52903866.TI6NV36Sul Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 2 December 2016 14:12:38 CET Salz, Rich wrote: > > SSL 2 < SSL 3 < "SSL" 1.0 < "SSL" 1.1 < "SSL" 1.2 < "SSL" 4 is not logi= cal > > ordering >=20 > So? Who cares? A couple-hundred people in the IETF. And the issue is t= hat > SSL 3 < "SSL" 1.0 which is the issue no matter what we call what we're > doing here. And the quotes around the last SSL do not belong there. > You can say that calling it "TLS 1.3" promulgates the illogical ordering,= or > you could say it continues a renumbering. A renumbering that the world h= as > never recognized or understood. You can say that "SSL 4" confuses people > twice, or you can say that it restores sanity to a 20-year glitch and > starts us using the same name that the rest of the world, *and our > industry,* uses. what it does is it introduces a second glitch speaking of confusion, do you know that e-mail clients by "SSL" mean "SSL/T= LS"=20 and by "TLS" mean "STARTTLS"? (note the port numbers) https://sils.unc.edu/it-services/email-faq/outlook https://mail.aegee.org/smtp/kmail.html https://sils.unc.edu/it-services/my-computer/email-faq/thunderbird =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart52903866.TI6NV36Sul Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYQYhXAAoJEJKo0bgB0vX1JcMP/jSpbi8fkWlRGgogw6PBZdIj +hcrGh3cngETXbehvVHf0NcsrSN7rEjpHYk3qNRp014GYqMkb/GWp+Sh9kVGAlib +ve+zrZo1wwpSahOwNJilxiRFUAI3AaKdGZRbKV8WH2vB6q5AztJ5LZX3aIhiL7w SMkYBE90TWsp4/Dp60bN7jy4P1OP/CRTu9A4EkzMm1IpYtOwO2KuitLFfGDQEIDq THe1orDZtqsw4fPdO5/bSQfwHM/QqFwU0xGW59CFBV4zVgss/i7lQ7QwB388BgXj 8EvqqfVJjzIBFOoF+MQsuqflY48q3xzLmGDwvhKQ7UrEEhfbVZF23+OzFKyb98GT +/oYsBgXLk47Et4I3Ai7Sdo4k7J71uejZcvtSv4M16YkA2+mcGNm1aUGVAuL5ovR OSGu+n8guqUPliT/bWJ2E+2AQijtDXWKTs58yS5Kw7GUtNESmFCHa70Gl7dvSTKz Gkv80yr919a4AVoPWdq6O60oTkuKhspmIJU4l8IGTL63nQEAtNQxMRRB21I6zQYN luQfxOiLqv39kt9RCqoOgWHSo43UrMQJAUiHea58VfQyqWCS4Y2xT2DC62BEApZJ 0ZzKWGyZ6MnPERSA1XWXoZlFw+jeD62ampg4xXWxaJLW59url2r19/c2hZieRWpe bS5BrbWTTHUNe8+7PfqZ =G/PY -----END PGP SIGNATURE----- --nextPart52903866.TI6NV36Sul-- From nobody Fri Dec 2 06:54:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B066B1294D4 for ; Fri, 2 Dec 2016 06:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.798 X-Spam-Level: X-Spam-Status: No, score=-4.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYCA8Azy0NR9 for ; Fri, 2 Dec 2016 06:54:02 -0800 (PST) Received: from brontes.bolet.org (brontes.bolet.org [62.210.214.227]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45181296E9 for ; Fri, 2 Dec 2016 06:53:58 -0800 (PST) Received: by brontes.bolet.org (Postfix, from userid 1000) id 1F74E205F8; Fri, 2 Dec 2016 15:53:57 +0100 (CET) Date: Fri, 2 Dec 2016 15:53:57 +0100 From: Thomas Pornin To: "Ackermann, Michael" Message-ID: <20161202145357.GA30015@bolet.org> References: <1480648354917.41781@cs.auckland.ac.nz> <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:54:04 -0000 On Fri, Dec 02, 2016 at 02:17:24PM +0000, Ackermann, Michael wrote: > In Enterprise circles TLS is an unknown acronym and as painful as it > is, we must usually refer to it as SSL, before anyone knows what we > are talking about. Software products are guilty too. Parameter > fields frequently reference SSL. :( Actually there is a large variety in what I encounter (I work in a big financial institution, and I have gone through other big organisations). Some will just know "SSL" and talk about SSL for all protocols in the "SSL" family (which so far includes SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2). Some will use "SSL" for SSL 2.0 and SSL 3.0, and "TLS" for the TLS 1.x versions. They then ban "SSL" and want to enforce "TLS". When they encounter regulations that say "don't use TLS 1.0, only TLS 1.1+", they get confused. Some people and software interfaces use "SSL vs TLS" in a completely different way, in the context of protocols like IMAP or FTPS: they use "SSL" to mean "SSL handshake first, then protocol inside it", and "TLS" to mean "protocol first and a STARTTLS command". This distinction is orthogonal to protocol versions. Commercial CA tend to sell "SSL certificates", not "TLS certificates" or "SSL/TLS certificates". In a similar vein, the 'S' in 'HTTPS' does _not_ mean "SSL", but not many people know that. When I encounter someone who knows the differences between all versions, then I am in front of a mirror. The taxonomy is confused and complicated, and people who are maniacal enough to learn and remember it are very rare. If we look at what Microsoft did when it encountered the same kind of terminology mess, it decided that the number following 2000 was "XP". Lately, for server versions, Microsoft uses a year-based numbering, and even so, they depart from it at times, e.g. when they decided that "2009" was really "2008R2". In practice, people don't have problem with gaps in numbering; they are even eager to _create_ gaps when convenient, for instance by not acknowledging the existence of Windows Vista. So my conclusion is that terminology is essentially fluid and chosen by people in the field, without any form of concertation and with a trend toward simplification: the _operational_ notion is to lump versions into two groups, the ones that must be used and the ones that must not be used. There is about nothing IETF can do about it (though a really poorly chosen name might increase confusion even further). The only naming scheme which is kinda coherent is the numbering scheme on the wire (3.0, 3.1...), and even that one fails to capture SSL 2.0 (which is in fact 0.2 on the wire). --Thomas Pornin From nobody Fri Dec 2 06:55:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418B6129636 for ; Fri, 2 Dec 2016 06:55:17 -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, DKIM_SIGNED=0.1, DKIM_VALID=-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=fugue-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 ZE-ypRgSwkIa for ; Fri, 2 Dec 2016 06:55:14 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9836B1297CC for ; Fri, 2 Dec 2016 06:55:07 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id c13so196786995lfg.0 for ; Fri, 02 Dec 2016 06:55:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Cmy+7oEW2e31WLZ+JeUgON0Jax8t088VDvGx+XGJ2Dk=; b=nWVYTmud1NQ+3yFh7xAyBM+uBTh93uprHiNhVjEtz90SHhu6B2ZwDxBseL/7UU2GA5 8jHjS459Cd+JUDj9P4lEWq3trnGg7Snhj6+WoLP9bkBlc5GIOXrCDYt4RtMSZ8zdqpTS +1Nxw/7B0UKuuEADFOOMLMy3fVa+lgCKFkXk9oDh7jddlxMtUVg69RNBYvLZrXYGhvRW fAdDxdLQu8aGG1VZuiZy2JqumfjWhoVr6BzU+kiQjYKcbl/+VmC3v7P2qYTM8Cl2T5A6 PTz6NgMcMaZLqsSAH54EYjA+OLSagNJe8W264d1raORrRh7uYGhvTIhUZ8oxw4x9ygYl +UPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Cmy+7oEW2e31WLZ+JeUgON0Jax8t088VDvGx+XGJ2Dk=; b=I+ycVosnsuujYquJl7rH69YAEh23CtT9xxCDe7lmiDYFkIahHsYFbaXEdPvaqxm703 YLMjdQrVtszL3VxZpPsmSpgADQpmge6r/C5oczZvYQLIJYQrzPbjsCkHz21++EKfPund z/exzG5OWDA+SHV8iaOaIq4k+igUiUAGO96sn4qoNzBcgd4Bq1Egcfckt+HrngdA16BU QsU4/7WooUkBSJnu+cPe5FNQ9u2vd8SyYrJGhZgsMsmdAnB0r6EYyUJEKJxmRZklkY1R KExjXyXDLRAs/JI+DdZh1bccVltF/P+FeGblxqcjl6bGU5+WYAV9PEEJLdFxg4qQwknI MjhQ== X-Gm-Message-State: AKaTC00jQ+ie4WKLbmsUQb8Jdvibw+wm3TYC7t+XnjpCNnrzD7b3Gs7NsIN+f8pMlIwZFty5EnMeiNxOCFOoXw== X-Received: by 10.25.190.79 with SMTP id o76mr17138390lff.56.1480690505708; Fri, 02 Dec 2016 06:55:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.63.132 with HTTP; Fri, 2 Dec 2016 06:54:25 -0800 (PST) In-Reply-To: <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> From: Ted Lemon Date: Fri, 2 Dec 2016 09:54:25 -0500 Message-ID: To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 14:55:17 -0000 The bottom line is that this is an unanswerable question. My advice is to not change the name, because I think more name changes =3D more confusion and it is _way_ too late to put TLS back in the box. But what do I know--I'm just an end user! :) On Fri, Dec 2, 2016 at 9:42 AM, Hubert Kario wrote: > On Friday, 2 December 2016 14:12:38 CET Salz, Rich wrote: >> > SSL 2 < SSL 3 < "SSL" 1.0 < "SSL" 1.1 < "SSL" 1.2 < "SSL" 4 is not log= ical >> > ordering >> >> So? Who cares? A couple-hundred people in the IETF. And the issue is = that >> SSL 3 < "SSL" 1.0 which is the issue no matter what we call what we're >> doing here. And the quotes around the last SSL do not belong there. > >> You can say that calling it "TLS 1.3" promulgates the illogical ordering= , or >> you could say it continues a renumbering. A renumbering that the world = has >> never recognized or understood. You can say that "SSL 4" confuses peopl= e >> twice, or you can say that it restores sanity to a 20-year glitch and >> starts us using the same name that the rest of the world, *and our >> industry,* uses. > > what it does is it introduces a second glitch > > speaking of confusion, do you know that e-mail clients by "SSL" mean "SSL= /TLS" > and by "TLS" mean "STARTTLS"? > (note the port numbers) > https://sils.unc.edu/it-services/email-faq/outlook > https://mail.aegee.org/smtp/kmail.html > https://sils.unc.edu/it-services/my-computer/email-faq/thunderbird > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Dec 2 08:02:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8CB1293F3 for ; Fri, 2 Dec 2016 08:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 gVcMBsaAAUK6 for ; Fri, 2 Dec 2016 08:02:34 -0800 (PST) Received: from mail-wj0-x22a.google.com (mail-wj0-x22a.google.com [IPv6:2a00:1450:400c:c01::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 41C72129435 for ; Fri, 2 Dec 2016 08:02:34 -0800 (PST) Received: by mail-wj0-x22a.google.com with SMTP id v7so235587923wjy.2 for ; Fri, 02 Dec 2016 08:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QxnZvnyxju7JC8j6S6kORVaH0FFiN7x1/IeFCqlzhHw=; b=icWU6f9JPOHwtlB0+GEECzJWJicO8gdbc54sEQJcotkugRoElCFEFT8hJTcRQrDwuu MJXpESFLKsr9jPNkgSgB2AwHXPss22CBPkV05+IY2AEw5TYXYLlK1dyCrwl7bxVqbjeg kb1vJRAHkUwbf3Sz5/ZXbCsQyxBLNV6CjH/RyoLZlsWbYYZQVgkOkIKZSJtJL+GvxL5n B9OcSJ7KADP8xvDFR8VE8aMuczT1Uh5zoUKv+AhuTqjBbLuT+VFsaVJubV5q2uxJj95y 9CGh0hrnBX6c8F1Fckjkr2l9Bz2HdtUGvYl/9Bu7ri+mXv3oGPb/orJ+xCp00VDd+paB n5qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QxnZvnyxju7JC8j6S6kORVaH0FFiN7x1/IeFCqlzhHw=; b=KVqOv868Cv282tAUHpmtR3olb6WqPt2yS35B0JjkW8T++rGPmgfmJ5+IIBufB4QFc8 9xV2vtiXZ3FfkISgSiBVbM1nahkFt4juBraxbiSWA+X9/IHH4guAL6NoRNTC9wZX/Omv 1d4lhvSBdiH6ggelsWC9PEsCkz/6lzrU+hkcaHpSJf49RuZ1erc/eQSZPeXLgKTsPb5p R9CW1I5cAw+NzYQ3xkBHCNz6oUZMqgXaMW6lEAnOQVlCdzaVGZCQQ1SidaG6XkG0Oh+j s3sbserJn+HSrhZv+bMIxVhR28OddIMTVxkr9B0JBfsyFj9iqZ6fxHxZLLvxISczOE0p 94zQ== X-Gm-Message-State: AKaTC02gvt6jlnDBLedMt+cDdAyoE9IZwUAeSoZUWJRlhXgIuwKv79MFTXLrndR6v1AdaDK5cPne21OzJxZ0pg== X-Received: by 10.194.126.38 with SMTP id mv6mr38512239wjb.142.1480694552558; Fri, 02 Dec 2016 08:02:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.170.102 with HTTP; Fri, 2 Dec 2016 08:02:32 -0800 (PST) In-Reply-To: References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> From: Maarten Bodewes Date: Fri, 2 Dec 2016 17:02:32 +0100 Message-ID: To: Ted Lemon Content-Type: multipart/alternative; boundary=e89a8f924038d382f50542af1003 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 16:02:37 -0000 --e89a8f924038d382f50542af1003 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, The point is we are now indeed on draft 18. Changing the name now is very problematic because everybody on the mailinglist already calls it TLS 1.3, for a long time and no matter what you do, a lot of us (who are hopefully the experts) will keep referring to it under that name. If you want a name change, introduce it early (as editor of the RFC, these guys should be able to make this kind of decision) or otherwise keep the name. The same kind of discussion was on the SHA-3 mailing list, where some argued for AHS instead of SHA-3. The same problem ensued there and SHA-3 was kept in the end (although I don't know how the decision was made at that time). Further discussions continue at ssl@ietf.org ;) Regards, Maarten 2016-12-02 15:54 GMT+01:00 Ted Lemon : > The bottom line is that this is an unanswerable question. My advice > is to not change the name, because I think more name changes =3D more > confusion and it is _way_ too late to put TLS back in the box. But > what do I know--I'm just an end user! :) > > On Fri, Dec 2, 2016 at 9:42 AM, Hubert Kario wrote: > > On Friday, 2 December 2016 14:12:38 CET Salz, Rich wrote: > >> > SSL 2 < SSL 3 < "SSL" 1.0 < "SSL" 1.1 < "SSL" 1.2 < "SSL" 4 is not > logical > >> > ordering > >> > >> So? Who cares? A couple-hundred people in the IETF. And the issue i= s > that > >> SSL 3 < "SSL" 1.0 which is the issue no matter what we call what we're > >> doing here. And the quotes around the last SSL do not belong there. > > > >> You can say that calling it "TLS 1.3" promulgates the illogical > ordering, or > >> you could say it continues a renumbering. A renumbering that the worl= d > has > >> never recognized or understood. You can say that "SSL 4" confuses > people > >> twice, or you can say that it restores sanity to a 20-year glitch and > >> starts us using the same name that the rest of the world, *and our > >> industry,* uses. > > > > what it does is it introduces a second glitch > > > > speaking of confusion, do you know that e-mail clients by "SSL" mean > "SSL/TLS" > > and by "TLS" mean "STARTTLS"? > > (note the port numbers) > > https://sils.unc.edu/it-services/email-faq/outlook > > https://mail.aegee.org/smtp/kmail.html > > https://sils.unc.edu/it-services/my-computer/email-faq/thunderbird > > > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republi= c > > > > _______________________________________________ > > 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 > --e89a8f924038d382f50542af1003 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

The point is we are now ind= eed on draft 18. Changing the name now is very problematic because everybod= y on the mailinglist already calls it TLS 1.3, for a long time and no matte= r what you do, a lot of us (who are hopefully the experts) will keep referr= ing to it under that name.

If you want a name change, int= roduce it early (as editor of the RFC, these guys should be able to make th= is kind of decision) or otherwise keep the name.

The same kind of di= scussion was on the SHA-3 mailing list, where some argued for AHS instead o= f SHA-3. The same problem ensued there and SHA-3 was kept in the end (altho= ugh I don't know how the decision was made at that time).

=
Further discussions continue at ssl@ie= tf.org ;)

Regards,
Maarten

2016-12-02 15:= 54 GMT+01:00 Ted Lemon <mellon@fugue.com>:
The bottom line is that this is an unanswerable question.= =C2=A0 =C2=A0My advice
is to not change the name, because I think more name changes =3D more
confusion and it is _way_ too late to put TLS back in the box.=C2=A0 =C2=A0= But
what do I know--I'm just an end user!=C2=A0 =C2=A0:)

On Fri, Dec 2, 2016 at 9:42 AM, Hubert Kario <hkario@redhat.com> wrote:
> On Friday, 2 December 2016 14:12:38 CET Salz, Rich wrote:
>> > SSL 2 < SSL 3 < "SSL" 1.0 < "SSL"= ; 1.1 < "SSL" 1.2 < "SSL" 4 is not logical
>> > ordering
>>
>> So?=C2=A0 Who cares?=C2=A0 A couple-hundred people in the IETF.=C2= =A0 And the issue is that
>> SSL 3 < "SSL" 1.0 which is the issue no matter what w= e call what we're
>> doing here.=C2=A0 And the quotes around the last SSL do not belong= there.
>
>> You can say that calling it "TLS 1.3" promulgates the il= logical ordering, or
>> you could say it continues a renumbering.=C2=A0 A renumbering that= the world has
>> never recognized or understood.=C2=A0 You can say that "SSL 4= " confuses people
>> twice, or you can say that it restores sanity to a 20-year glitch = and
>> starts us using the same name that the rest of the world, *and our=
>> industry,* uses.
>
> what it does is it introduces a second glitch
>
> speaking of confusion, do you know that e-mail clients by "SSL&qu= ot; mean "SSL/TLS"
> and by "TLS" mean "STARTTLS"?
> (note the port numbers)
> https://sils.unc.edu/it-services/email-f= aq/outlook
> https://mail.aegee.org/smtp/kmail.html
> https://sils.unc.edu/it-= services/my-computer/email-faq/thunderbird
>
> --
> Regards,
> Hubert Kario
> Senior Quality Engineer, QE BaseOS Security team
> Web: www.cz.redhat.com
> Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republ= ic
>
> __________________= _____________________________
> 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

--e89a8f924038d382f50542af1003-- From nobody Fri Dec 2 08:09:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F43A1296D1 for ; Fri, 2 Dec 2016 08:09:46 -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 o3dsU3XAKatb for ; Fri, 2 Dec 2016 08:09:44 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 26AF412958E for ; Fri, 2 Dec 2016 08:09:38 -0800 (PST) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id CCBF9F993; Fri, 2 Dec 2016 11:09:35 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 152272107C; Fri, 2 Dec 2016 09:35:43 -0500 (EST) From: Daniel Kahn Gillmor To: Peter Gutmann , Stephen Farrell , David Benjamin , Tony Arcieri , "\" In-Reply-To: <1480667592856.97451@cs.auckland.ac.nz> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> Date: Fri, 02 Dec 2016 09:35:40 -0500 Message-ID: <87y3zytn43.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 16:09:46 -0000 --=-=-= Content-Type: text/plain On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote: > If no-one from Microsoft has any objections, can we just rename it back to > what it's always been for everyone but us, SSL? fwiw, the industry (and stackexchange) uses "SSL" to mean all sorts of things, not only TLS. Yesterday i got an e-mail from a reputable CA reseller that said "Your SSL is expiring in two days! Buy a new SSL now!" Surely no one is proposing that we also re-name the X.509 certificate format to "SSL" just because vendors whose business models revolve around these products are confused about terminology. What else should we rename to "SSL" on that basis? Maybe a load-balancer is also "SSL"! Here's a useful and effective meme for convincing bosses that it's ok to turn off SSLv3: all known versions of SSL are broken and should never be used. Please do not break this meme by trying to rename TLS to SSL. I don't care about the bikeshed over the number: i'd be fine with any of TLS 1.3 or TLS 4 or TLS 2017. But can we please not create *even more* confusion by bikeshedding over the name itself? --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE7bLnT1b88rZyl7c1JOz/Wv9oNwoFAlhBhrwACgkQJOz/Wv9o NwpTsA/+KXMtqeMLlStGdunDTzssp2VpTKkqy6NItuSDNSEeUQebgU1KuQ/bZP2y 6JjDWZ4qaHnUUfE3bIx+3eqc5b5CTnu8px857wjqmDu+kq++A8ptMKM6w/LhliIl cuVJ0QmxVRDrxbtshKRzhxsTBk39a7JvRafl+FJLTrZPOSmjPm0VIBZgzGv/ICPn myn18XHg14Eangoq6tRVjX6wCvqajSaLrB+riezmpERM4YEyeZfER6sVnGjfpm3/ 8uA4EPWLo3yDuXO6eu8fKgdfgJAZxJf+q7G/qvPc6HxezJAQfmXPxCNt4zWaMpwZ jqo3eyzYxRXEv5sSx5D6Xku8r87jBHFpXkKBXKgmC6E4cRdtJRDiQ69S4Y4BnqCe SpGSAP9+CDocqN+JDN2Qov2ItGECZO1m1GDu9HfkQ0+mZDLrXg8RD9PTIvIfg89W wKE5oo3rs5nbXwygGUJc6SB8OMg7aTJbTsg8lU/MUCw+9UFfpJ9jBAzbWrk4Plru puEtkBhWg/6oIPVooynsLG2DTbzJvOJhAorn7IDMPB3IKC+JhtDy+RY0SzrVE+xn MRdgpuAys7wMsTFH1xluv9w6+80ZdosepYPb3eCr9exRlAOWVLn3jT+ZfJKfXgKS f0CPIdZFJISSvzF8jee70zvdVIP5SYb/qnjTVBhqRLV7+LS0oSg= =qJ0q -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 2 08:12:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F8871293F3 for ; Fri, 2 Dec 2016 08:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lhZ4g4JDbmKw for ; Fri, 2 Dec 2016 08:12:06 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 81809129446 for ; Fri, 2 Dec 2016 08:12:06 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DF35D43345B; Fri, 2 Dec 2016 16:12:05 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id C827943343C; Fri, 2 Dec 2016 16:12:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480695125; bh=2OmjxM+nULi4uUAlzsy1Z8MBX8Zr73UdzQl+TxUgrto=; l=283; h=From:To:Date:References:In-Reply-To:From; b=USR7Ag6Flv1w+EFqtPU0uYJsZNHz6uuGGcEGReiDfD2hGKWZP6cp30T97KkUpYhOT 9+uxvtlwmND+PiwD8QSnM1EX7xcsm8zubdUQvKJvW8pHDzjaQRR59TwqZt2A2tO9Ds KO13SZcrQ5LBJRa8iAbRFtjQb/7zvW67Ug0aJS7I= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id C4EA21FC8C; Fri, 2 Dec 2016 16:12:05 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 2 Dec 2016 11:12:05 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 2 Dec 2016 11:12:05 -0500 From: "Salz, Rich" To: Daniel Kahn Gillmor , Peter Gutmann , Stephen Farrell , David Benjamin , Tony Arcieri , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDwX4eAgAJbVYCAAC0nAIAABEIAgAFpLoCAAA++gIAABjwAgABRlQCAAAHGgIAAZTsA///HBFA= Date: Fri, 2 Dec 2016 16:12:05 +0000 Message-ID: <05130404817f4d529f9c29ec62e4adf0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> <87y3zytn43.fsf@alice.fifthhorseman.net> In-Reply-To: <87y3zytn43.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.23] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 16:12:08 -0000 > Here's a useful and effective meme for convincing bosses that it's ok to = turn > off SSLv3: all known versions of SSL are broken and should never be used. > Please do not break this meme by trying to rename TLS to SSL. Is "all known versions before SSL 4" that much worse? From nobody Fri Dec 2 08:48:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 512B3129454 for ; Fri, 2 Dec 2016 08:48:04 -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 zgBPrYAYRbIA for ; Fri, 2 Dec 2016 08:48:01 -0800 (PST) Received: from mmextmx1.mcr.colo.comodoca.net (mmextmx1.mcr.colo.comodoca.net [IPv6:2a02:1788:402:c00::c0a8:9cd5]) (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 E4EEB1295BE for ; Fri, 2 Dec 2016 08:47:50 -0800 (PST) Received: (qmail 18345 invoked by uid 1004); 2 Dec 2016 15:01:08 -0000 Received: from ian.brad.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.202) by mmextmx1.mcr.colo.comodoca.net (qpsmtpd/0.84) with ESMTP; Fri, 02 Dec 2016 15:01:08 +0000 Received: (qmail 14407 invoked by uid 1000); 2 Dec 2016 15:01:08 -0000 Received: from and0004.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES128-SHA encrypted) ESMTPSA; Fri, 02 Dec 2016 15:01:08 +0000 To: Thomas Pornin References: <1480648354917.41781@cs.auckland.ac.nz> <1714292.gybZQF1xmo@pintsize.usersys.redhat.com> <75c46572e29141f69397d4511761ddc3@usma1ex-dag1mb1.msg.corp.akamai.com> <20161202145357.GA30015@bolet.org> From: Rob Stradling Message-ID: Date: Fri, 2 Dec 2016 15:01:08 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20161202145357.GA30015@bolet.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 16:48:04 -0000 On 02/12/16 14:53, Thomas Pornin wrote: > Commercial CA tend to sell "SSL certificates", not "TLS certificates" > or "SSL/TLS certificates". It's worse than that. Many customers, and even some salespeople, seem to think that we sell "SSLs". -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From nobody Fri Dec 2 09:00:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A73B51295DE for ; Fri, 2 Dec 2016 09:00:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.818 X-Spam-Level: X-Spam-Status: No, score=-9.818 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xTLn8rZUa2CY for ; Fri, 2 Dec 2016 09:00:40 -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 BD4591294F6 for ; Fri, 2 Dec 2016 09:00:40 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 33FC03D958; Fri, 2 Dec 2016 17:00:40 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB2H0cSU003937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 2 Dec 2016 12:00:39 -0500 From: Hubert Kario To: tls@ietf.org Date: Fri, 02 Dec 2016 18:00:32 +0100 Message-ID: <1628053.opueYpGO4s@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.10-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <05130404817f4d529f9c29ec62e4adf0@usma1ex-dag1mb1.msg.corp.akamai.com> References: <87y3zytn43.fsf@alice.fifthhorseman.net> <05130404817f4d529f9c29ec62e4adf0@usma1ex-dag1mb1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2557531.qcl9vQDdgg"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Fri, 02 Dec 2016 17:00:40 +0000 (UTC) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:00:43 -0000 --nextPart2557531.qcl9vQDdgg Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 2 December 2016 16:12:05 CET Salz, Rich wrote: > > Here's a useful and effective meme for convincing bosses that it's ok to > > turn off SSLv3: all known versions of SSL are broken and should never be > > used. Please do not break this meme by trying to rename TLS to SSL. >=20 > Is "all known versions before SSL 4" that much worse? given: 1. we have people that need support for SSLv3 and SSLv2 style Client Hello= =20 messages (The Web is not the only place where SSL/TLS is deployed), let alo= ne=20 TLS 1.0 2. TLS 1.2 is not broken (so the statement is demonstrably false) yes, it is much worse =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2557531.qcl9vQDdgg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYQaiwAAoJEJKo0bgB0vX1ZowP/1x2Zif/2rGcom9+JIdsFfMk /DfJUulRoM/V7DSHZzsBvCcu5QB337QIaedddwixxwZ9ayAkTswP/aG0C9uipp6V qVcrJVk8rFavjEkJeZnMffEnsJ0rLHqgHWHk1VantrPuIkxIkkbz65HnFjebGqzW nkNYEulxsnhIPbg7ohCxddKqmpq3L3e+jew3+Td3wQaR/cxD/18//FCHEQ9pui9L nXLnn1W0PNmem+30sOryU3x097tKDw8vz35pIx3gWGaGbZJytCikfdHm0jE9QpOQ nX3eyDUNCE7XU6lat6yUQ98S71m5dH3aPGqxO2lx0uCEyCx/WeVIiDFdKzJmBCLM Hey+APVCDiTJxrzx+Z99JQzkek6sqd5v7k3y9GKttundIwHTssRhXYm9p0spFDDx BIVuzpxA8LIVE6lvgbRR80R+VHzQRVoJ/fGe5wmCtVpXJTK1cIK4XOSABQz1oZFP YEnJFq1Zf23tn9twwYMGtVj6o/qzdHNb/2qNW63u9/FhhpCmsWB4RFnmxv/PC0lc fNCLdT1r6MC+uBRSKVt9kYfL4P8F0FdyzkySztfuaXZuikX8cxUk8IXFs0kBA572 gZwNDRHbTNXJiP0AEIJ0wW1wem5V9GlsZKXSH7MZMeykIlLt4Kb2gHNJuWoZFc8d ODLcq7nQ8mCaWAd9Y/8t =1MGK -----END PGP SIGNATURE----- --nextPart2557531.qcl9vQDdgg-- From nobody Fri Dec 2 09:45:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4FF41270B4 for ; Fri, 2 Dec 2016 09:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.012 X-Spam-Level: X-Spam-Status: No, score=-3.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 l6zt7aurgnlU for ; Fri, 2 Dec 2016 09:45:36 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0133.outbound.protection.outlook.com [104.47.41.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42A321296A5 for ; Fri, 2 Dec 2016 09:45:35 -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=4zyzBKI3B/pLvu0qLCEqdRkseIoc1ixF8O3glfu48MA=; b=WlmLL1YHFTHllIkR+zF6CHdDja8Gf38raKCCMBCsKWuD3ZvSeTwlJJ7AnMXzh1ToS8xo6cBXc6vY0wO57FBLzJPYXdxu/jjoamLqVzGZefx5F4vXRjUOQWa34Hu/M8tvCKnO98VOnYfJevRz1uN8+0qdPQoRrSeXHHYDLPeiRSU= Received: from BN3PR0301MB0836.namprd03.prod.outlook.com (10.160.154.146) by BN3PR0301MB0835.namprd03.prod.outlook.com (10.160.154.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Fri, 2 Dec 2016 17:45:29 +0000 Received: from BN3PR0301MB0836.namprd03.prod.outlook.com ([10.160.154.146]) by BN3PR0301MB0836.namprd03.prod.outlook.com ([10.160.154.146]) with mapi id 15.01.0693.009; Fri, 2 Dec 2016 17:45:29 +0000 From: Andrei Popov To: Peter Gutmann , Stephen Farrell , David Benjamin , "Tony Arcieri" , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFnfYxD1l3raU+THHLUgHfRNqDwC7aAgAJbVICAAC0oAIAABEIAgAFpLoCAAA+9gIAABjwAgABRlgCAAAHGgIAAmKZQ Date: Fri, 2 Dec 2016 17:45:28 +0000 Message-ID: References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> , <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> In-Reply-To: <1480667592856.97451@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB0835; 7:2IU2lCA2pqFH+NS5Cn9xYT5qdeo1+HoabNc52hwFdeNX5dogdFZVFJ4p0RDJH6PzOzcz17sI3urR3PyRRgG1SbPlcfQt1tcKfbzoK6Ao0DYx9T6fOSBzPueG8u0R4AazfHqbBUqwFxsh3YJiDtF79u1Q3alK3IYJeAfesVf9WD5SowlYstQZFCH2FY59CIJiFddWlK9o/K8MNwb+VG869pQj+i7d1aflkOn/a3nMQYJEBWdBDK2t2xGYnaHo2OSVFUAmJNLdkgpSAwf61EocK7lj49qv7IcvSDFm/sS4Nng1Kr3yjSAMLwBpCkaU2loLrHz6g/mSmYxcZr0oq/s9JPLk/gvAOfDyPjKoETsYBv9WjHIu3+tq4+a25VZ89f+i x-ms-office365-filtering-correlation-id: 69d76f9e-b338-43c4-3337-08d41adb0177 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0301MB0835; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(192374486261705)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148)(6047074); SRVR:BN3PR0301MB0835; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0835; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(13464003)(377454003)(50986999)(7736002)(38730400001)(189998001)(107886002)(39410400001)(8676002)(101416001)(6506004)(39060400001)(105586002)(10090500001)(122556002)(7846002)(54356999)(76176999)(77096006)(7696004)(5001770100001)(106116001)(2950100002)(99286002)(68736007)(106356001)(92566002)(8990500004)(5005710100001)(86612001)(86362001)(2906002)(74316002)(97736004)(6116002)(5660300001)(2900100001)(305945005)(39450400002)(3660700001)(8936002)(81156014)(229853002)(81166006)(10290500002)(33656002)(102836003)(76576001)(9686002)(93886004)(3280700002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0835; H:BN3PR0301MB0836.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2016 17:45:28.8850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0835 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:45:39 -0000 Not that I can speak for the whole of Microsoft, but I would not drop TLS s= upport in Windows if it were renamed "SSL":). However, "transport layer security" makes a lot more sense to me than "secu= re sockets layer" because the latter seems to imply network socket-style AP= I, which is not a requirement of this protocol. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann Sent: Friday, December 2, 2016 12:33 AM To: Stephen Farrell ; David Benjamin ; Tony Arcieri ; Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* Stephen Farrell writes: >IIRC that was sort-of a condition for adoption of the work in the IETF=20 >20 years ago, when there were two different protocols already being=20 >deployed and the proponents of one of them said "we'll use that other=20 >one (SSL) but you gotta change the name of the standard or we can't get=20 >our to agree to change to all use the same thing." It was Netscape with SSL vs. Microsoft with PCT. If no-one from Microsoft has any objections, can we just rename it back to = what it's always been for everyone but us, SSL? Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Dec 2 09:59:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC74129810 for ; Fri, 2 Dec 2016 09:59:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, 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 oXbCI5NbihqX for ; Fri, 2 Dec 2016 09:59:01 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1C3D1297EB for ; Fri, 2 Dec 2016 09:58:56 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id n204so286744120qke.2 for ; Fri, 02 Dec 2016 09:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=g2xNISf4j8KeyJs/WXl6fnOjSj5U9RBEMypGGh0dQE0=; b=cu9C1lnqcOjE3oZXITmQU/EifHpLr8eLO8dI43y4QJQMYipj7lqEWatRNbkEm4RPiL aI2EowFY+YzlWVzsBbabvCuAG1BsPEWRcb0ONlz7sc6wh/FHjF5eNarn3mpQhfJnFpLb 52HQQAaPz9nVUz+s5Zyyax8eSJ0Pd7D8+WJnU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=g2xNISf4j8KeyJs/WXl6fnOjSj5U9RBEMypGGh0dQE0=; b=bShwciNgGcm4KIDSK3G1XwcPTfJqI3VZUXQnInMlXZLLPxeuyVOruuJiOEBjS56frO lvCDrSKFLzbnzRLBfDUiI9YIQnAFGV/k1yNTR5NXScWRsu91P6JFGC02e9GPi6/WGg1z M3vpwRYSZv1Z4LIyxesAlp6VIJW9je+r7swNq1ZwobnTCxinOy69Bo6y+SmnWug9K0kb csbBfekMOJ8segqP5kwZit290VV6Pzwi0+XZR6qomMeziH6b0Lh9IQvjj0rIK0NpL4q3 W1btaOqmnpEulooxcK/NbwPAjVMa3xV76RigZCUeZhMcuCkt6RvwPxud0Qy0lpof5J7q BJEg== X-Gm-Message-State: AKaTC00vUc1fOhQerzeC9sp+R14aIzkDmuzDvy5pZ8Wx3BYZIImHx09WQBZTKY3r9pynxKMqBFVMOqO6cfi53Qbl X-Received: by 10.55.8.20 with SMTP id 20mr44313631qki.3.1480701536026; Fri, 02 Dec 2016 09:58:56 -0800 (PST) MIME-Version: 1.0 References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> In-Reply-To: From: David Benjamin Date: Fri, 02 Dec 2016 17:58:44 +0000 Message-ID: To: Andrei Popov , Peter Gutmann , Stephen Farrell , Tony Arcieri , "" Content-Type: multipart/alternative; boundary=001a114c9d60130bee0542b0b1d3 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 17:59:03 -0000 --001a114c9d60130bee0542b0b1d3 Content-Type: text/plain; charset=UTF-8 (To clarify, I was not at all suggesting we go back to SSL. If we had a time machine, I might make other suggestions, but as far as I know we do not.) On Fri, Dec 2, 2016 at 12:45 PM Andrei Popov wrote: > Not that I can speak for the whole of Microsoft, but I would not drop TLS > support in Windows if it were renamed "SSL":). > > However, "transport layer security" makes a lot more sense to me than > "secure sockets layer" because the latter seems to imply network > socket-style API, which is not a requirement of this protocol. > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann > Sent: Friday, December 2, 2016 12:33 AM > To: Stephen Farrell ; David Benjamin < > davidben@chromium.org>; Tony Arcieri ; < > tls@ietf.org> > Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* > > Stephen Farrell writes: > > >IIRC that was sort-of a condition for adoption of the work in the IETF > >20 years ago, when there were two different protocols already being > >deployed and the proponents of one of them said "we'll use that other > >one (SSL) but you gotta change the name of the standard or we can't get > >our to agree to change to all use the same thing." > > It was Netscape with SSL vs. Microsoft with PCT. > > If no-one from Microsoft has any objections, can we just rename it back to > what it's always been for everyone but us, SSL? > > Peter. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114c9d60130bee0542b0b1d3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(To clarify, I was not at all suggesting we go back to SSL= . If we had a time machine, I might make other suggestions, but as far as I= know we do not.)

On Fri= , Dec 2, 2016 at 12:45 PM Andrei Popov <Andrei.Popov@microsoft.com> wrote:
Not that I can speak for the whole of Microsoft, but I= would not drop TLS support in Windows if it were renamed "SSL":)= .

However, "transport layer security" makes a lot more sense to me = than "secure sockets layer" because the latter seems to imply net= work socket-style API, which is not a requirement of this protocol.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann Sent: Friday, December 2, 2016 12:33 AM
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>; David B= enjamin <davidben@chromium.org>; Tony Arcieri <bascule@gma= il.com>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

Stephen Farrell <stephen.farrell@cs.tcd.ie> writes:

>IIRC that was sort-of a condition for adoption of the work in the IETF<= br class=3D"gmail_msg"> >20 years ago, when there were two different protocols already being
>deployed and the proponents of one of them said "we'll use tha= t other
>one (SSL) but you gotta change the name of the standard or we can't= get
>our <bosses> to agree to change to all use the same thing."<= br class=3D"gmail_msg">
It was Netscape with SSL vs. Microsoft with PCT.

If no-one from Microsoft has any objections, can we just rename it back to = what it's always been for everyone but us, SSL?

Peter.

_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a114c9d60130bee0542b0b1d3-- From nobody Fri Dec 2 10:23:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7A1D12973A for ; Fri, 2 Dec 2016 10:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MEgU_xHdOgcE for ; Fri, 2 Dec 2016 10:23:21 -0800 (PST) Received: from mail-wm0-x241.google.com (mail-wm0-x241.google.com [IPv6:2a00:1450:400c:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF34C1295F4 for ; Fri, 2 Dec 2016 10:23:20 -0800 (PST) Received: by mail-wm0-x241.google.com with SMTP id a20so3985092wme.2 for ; Fri, 02 Dec 2016 10:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wuqSwD4YsLiKsbQBwt2FZlNnIOAq6qK3LPy8/HXb/ps=; b=V+g0WkEDI8O8tL/UGeDQ8uJPKpjRzEGjOkGQl4EgMKU8gh04PXDM0bnAdzKtSQzQjE AEtctrWI3ARqkJdzqVo2oV3TYTblPbvxIqsLNjQjIBq5o7rcEeQ7y7dkjTvip+omJrkW vAL3Lt3onaImdfl7iQGYbpRJjVq9X+a2gZHZBj2hpX1wfBcGW+PjU+oP4/1KiMBaNGlp tB+yi1rLNpGZzzPiO3wqXyvZrcAruiEP70qOjqV0Etf+axbG6DvshQvWb7yNdlm4/1mp r63zr6M91evJMAQEl3xdpq4iYi5Y/D995gXXuEWBVthcw6dSbTZ/Ulm39fD1Zm5ck3UD TAvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wuqSwD4YsLiKsbQBwt2FZlNnIOAq6qK3LPy8/HXb/ps=; b=JOoK1DDbin2wC4P65M/L68l9bVmq6ejF75cAdU/rYi6MKSaG+ANGPlf2Xq2QUrPXOy 6/imVT3epFE8ct8pA/S24eonhbJgd5epcaCH4LbR9SyCWdl9uiLBj2FJR3p5h3QpHVUZ hYS1NnlGRNE7CkVbMpLWSiIV5OzbSYTgt6G2th3B3Ya1FS9e8Suoq6dDeeisaJWN2lQJ eZT1ery1V4zha8++8yYvlocmDMc9yQ/dBmrKZs3OsCkfEQkXVNLJk9FTXBQ9runqHE3u ToDu/uAAOCVX8ix0d8wl8K2kEuIUy53gfchnFB/4t+VoNg9J74Ij6X9FpEN0joio0dpK 2FAg== X-Gm-Message-State: AKaTC031P/OEdCP332a3z5n4DrZOPadzAjo3Woug5Er8A7Rz+NL4Zn/swHbogUlrLoZ77g== X-Received: by 10.28.214.84 with SMTP id n81mr3941297wmg.120.1480702999419; Fri, 02 Dec 2016 10:23:19 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g10sm6821749wjw.18.2016.12.02.10.23.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 10:23:18 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: Date: Fri, 2 Dec 2016 20:23:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> To: David Benjamin X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 18:23:23 -0000 > On 2 Dec 2016, at 19:58, David Benjamin wrote: >=20 > (To clarify, I was not at all suggesting we go back to SSL. If we had = a time machine, I might make other suggestions, but as far as I know we = do not.) Can=E2=80=99t we borrow one from tictoc?= From nobody Fri Dec 2 10:34:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40D1B128AB0 for ; Fri, 2 Dec 2016 10:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnBw5cnSdVIj for ; Fri, 2 Dec 2016 10:34:45 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0101.outbound.protection.outlook.com [104.47.33.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBFF41295DA for ; Fri, 2 Dec 2016 10:34:44 -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=GvnMFEJP2NPJzPLgvnPtT4fsi6YwnF7WObjUqP3dSXg=; b=cs7ek4xyCQkVwVCfSAq0newA9pbMJMwEwQA+yE+xcoA3HIBrxg/r3eWfTALhyzhtB2ZfsyRgx3LA0Cy8gdSxc70qYnhYwU3aSNCg2tRhcHkUe3EjXLkmP9WTGaSDqw6gCfXMzYTO0w/n0tf3ttD6/1zlNjllrBJgZ4cPzssXy1k= Received: from BN3PR0301MB0836.namprd03.prod.outlook.com (10.160.154.146) by BN3PR0301MB0836.namprd03.prod.outlook.com (10.160.154.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Fri, 2 Dec 2016 18:34:42 +0000 Received: from BN3PR0301MB0836.namprd03.prod.outlook.com ([10.160.154.146]) by BN3PR0301MB0836.namprd03.prod.outlook.com ([10.160.154.146]) with mapi id 15.01.0693.009; Fri, 2 Dec 2016 18:34:42 +0000 From: Andrei Popov To: Daniel Kahn Gillmor , Peter Gutmann , Stephen Farrell , David Benjamin , Tony Arcieri , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFnfYxD1l3raU+THHLUgHfRNqDwC7aAgAJbVICAAC0oAIAABEIAgAFpLoCAAA+9gIAABjwAgABRlgCAAAHGgIAAZTsAgABB5tA= Date: Fri, 2 Dec 2016 18:34:42 +0000 Message-ID: References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> <87y3zytn43.fsf@alice.fifthhorseman.net> In-Reply-To: <87y3zytn43.fsf@alice.fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:9::1d2] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB0836; 7:6Jn0fm895bz4vcA8biCnoDVuVRtmUuzNeVvyrQXn98GsR0zKgMRV4+LYf9+pYYzXeb2BRTtx20w7Z4la9XF7++UzopqHJA5+S/lOuYljcSTKSrO5LlkED4f+rVFhuK6w6dHHfbaPOxWd9imM26YO65YguINtFjq9HM0B/tVrDdQKZw4JLQE4IuWS9vGv4YD/+MZzeYtGPtAGHWK/XCRH2vWWRWkNPzKafNMD3tcvDRExCSO1ZMVdZg5ycBjxx3v37EhowNtyt8Q1hrZ31wt6z8BR8nbZZyG6nUHZaj3kIOOTH9wL1eJPxGFAirdQXJTIldM+V4ReRWzrKOrHbvtbOe6GxwrAth2fmWHTpwUKzXAIe+oACZxi9DEGoabJHXQl x-ms-office365-filtering-correlation-id: 596a5b37-dbd2-4a25-e3ae-08d41ae1e1f7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0301MB0836; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148)(6047074); SRVR:BN3PR0301MB0836; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0836; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(199003)(189002)(24454002)(377424004)(377454003)(7696004)(97736004)(81156014)(7736002)(189998001)(8936002)(3660700001)(5001770100001)(107886002)(7846002)(8676002)(9686002)(76576001)(86362001)(81166006)(86612001)(2906002)(77096006)(39450400002)(68736007)(3280700002)(93886004)(105586002)(106356001)(101416001)(10290500002)(5005710100001)(54356999)(229853002)(6506004)(106116001)(102836003)(39410400001)(6116002)(2950100002)(5660300001)(74316002)(10090500001)(38730400001)(92566002)(305945005)(33656002)(39060400001)(122556002)(2900100001)(76176999)(8990500004)(99286002)(50986999)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0836; H:BN3PR0301MB0836.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2016 18:34:42.4093 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0836 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 18:34:47 -0000 Indeed, "all known versions of SSL are broken and should never be used" is = what I've been telling people for a while now... -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor Sent: Friday, December 2, 2016 6:36 AM To: Peter Gutmann ; Stephen Farrell ; David Benjamin ; Tony Arcieri ; Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote: > If no-one from Microsoft has any objections, can we just rename it=20 > back to what it's always been for everyone but us, SSL? fwiw, the industry (and stackexchange) uses "SSL" to mean all sorts of thin= gs, not only TLS. Yesterday i got an e-mail from a reputable CA reseller t= hat said "Your SSL is expiring in two days! Buy a new SSL now!" Surely no one is proposing that we also re-name the X.509 certificate forma= t to "SSL" just because vendors whose business models revolve around these = products are confused about terminology. What else should we rename to "SS= L" on that basis? Maybe a load-balancer is also "SSL"! Here's a useful and effective meme for convincing bosses that it's ok to tu= rn off SSLv3: all known versions of SSL are broken and should never be used= . Please do not break this meme by trying to rename TLS to SSL. I don't care about the bikeshed over the number: i'd be fine with any of TL= S 1.3 or TLS 4 or TLS 2017. But can we please not create *even more* confu= sion by bikeshedding over the name itself? --dkg From nobody Fri Dec 2 10:54:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0889D129486; Fri, 2 Dec 2016 10:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.897 X-Spam-Level: X-Spam-Status: No, score=-9.897 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_HI=-5, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=usbank.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4asuRjqzmwb; Fri, 2 Dec 2016 10:54:52 -0800 (PST) Received: from mail9.usbank.com (mail9.usbank.com [170.135.218.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D481F127078; Fri, 2 Dec 2016 10:54:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=usbank.com; i=@usbank.com; q=dns/txt; s=TrustUS; t=1480704892; x=1512240892; h=in-reply-to:references:to:cc:mime-version:subject: message-id:from:date; bh=qhTZs+7V93ObVH+9WK8ZZDVQcYzYYXLEph9HhZdLaNc=; b=KYjP0pBTxm8ElqRDVTLTg0i5UXrTPCVtMXb7pKrWun4gY6lR/E0jtkTm /W1k26H3zg+k/gInnnIBVfBLhYcA6ZcBEfn0QjASdtyN4FIAYvnQDhX7Y 8N6Ud1AJqa5YXBqK+ySWBTimC5DddLNwJWSlxIThNXCb0nM2xPAapUD5X E=; Received: from unknown (HELO mail.svr-internal.com) ([127.0.0.1]) by mail9.usbank.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2016 12:54:28 -0600 X-Loop1: 1 X_fileSizes: None In-Reply-To: References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> <87y3zytn43.fsf@alice.fifthhorseman.net> To: Andrei Popov MIME-Version: 1.0 X-KeepSent: 20D28CBE:F4174135-8625807D:00669BC6; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP3 January 13, 2015 Message-ID: From: darin.pettis@usbank.com Date: Fri, 2 Dec 2016 12:54:43 -0600 X-MIMETrack: Serialize by Router on EPEM104/MN/Servers/USB(Release 9.0.1FP6 HF273|August 01, 2016) at 12/02/2016 12:54:27 PM, Serialize complete at 12/02/2016 12:54:27 PM Content-Type: multipart/alternative; boundary="=_alternative 0067DC158625807D_=" Archived-At: Cc: TLS , "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 18:54:55 -0000 This is a multipart message in MIME format. --=_alternative 0067DC158625807D_= Content-Type: text/plain; charset="US-ASCII" +1 with Andrei. "That SSL should never be used" is the one clear message we have so going back to SSL would muddy those waters too much. Strong vote for staying with TLS. It will become better known over time- especially with the current enterprise push to deprecate all SSL versions from use. Regarding the numbering schema, someone recently mentioned that probably only a few hundred of us are aware of the TLS 1.3 nomenclature at this point and I would concur with that. So, after considering all of the good points that have been circulating, I would like to change my vote to TLS 2017. It provides clarity, recognizes that it is a major change and pulls us out of the whole SSL/TLS numbering confusion/quagmire. Darin From: Andrei Popov To: Daniel Kahn Gillmor , Peter Gutmann , Stephen Farrell , David Benjamin , Tony Arcieri , "" Date: 12/02/2016 12:34 PM Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* Sent by: "TLS" Indeed, "all known versions of SSL are broken and should never be used" is what I've been telling people for a while now... -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor Sent: Friday, December 2, 2016 6:36 AM To: Peter Gutmann ; Stephen Farrell ; David Benjamin ; Tony Arcieri ; Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote: > If no-one from Microsoft has any objections, can we just rename it > back to what it's always been for everyone but us, SSL? fwiw, the industry (and stackexchange) uses "SSL" to mean all sorts of things, not only TLS. Yesterday i got an e-mail from a reputable CA reseller that said "Your SSL is expiring in two days! Buy a new SSL now!" Surely no one is proposing that we also re-name the X.509 certificate format to "SSL" just because vendors whose business models revolve around these products are confused about terminology. What else should we rename to "SSL" on that basis? Maybe a load-balancer is also "SSL"! Here's a useful and effective meme for convincing bosses that it's ok to turn off SSLv3: all known versions of SSL are broken and should never be used. Please do not break this meme by trying to rename TLS to SSL. I don't care about the bikeshed over the number: i'd be fine with any of TLS 1.3 or TLS 4 or TLS 2017. But can we please not create *even more* confusion by bikeshedding over the name itself? --dkg _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls U.S. BANCORP made the following annotations --------------------------------------------------------------------- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. --------------------------------------------------------------------- --=_alternative 0067DC158625807D_= Content-Type: text/html; charset="US-ASCII" +1 with Andrei.  

"That SSL should never be used" is the one clear message we have so going back to SSL would muddy those waters too much.  Strong vote for staying with TLS.  It will become better known over time- especially with the current enterprise push to deprecate all SSL versions from use.  
Regarding the numbering schema, someone recently mentioned that probably only a few hundred of us are aware of the TLS 1.3 nomenclature at this point and I would concur with that.  So, after considering all of the good points that have been circulating, I would like to change my vote to TLS 2017.  It provides clarity, recognizes that it is a major change and pulls us out of the whole SSL/TLS numbering confusion/quagmire.

Darin



From:        Andrei Popov <Andrei.Popov@microsoft.com>
To:        Daniel Kahn Gillmor <dkg@fifthhorseman.net>, Peter Gutmann <pgut001@cs.auckland.ac.nz>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, David Benjamin <davidben@chromium.org>, Tony Arcieri <bascule@gmail.com>, "<tls@ietf.org>" <tls@ietf.org>
Date:        12/02/2016 12:34 PM
Subject:        Re: [TLS] Confirming consensus: TLS1.3->TLS*
Sent by:        "TLS" <tls-bounces@ietf.org>



Indeed, "all known versions of SSL are broken and should never be used" is what I've been telling people for a while now...

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sent: Friday, December 2, 2016 6:36 AM
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>; Stephen Farrell <stephen.farrell@cs.tcd.ie>; David Benjamin <davidben@chromium.org>; Tony Arcieri <bascule@gmail.com>; <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote:
> If no-one from Microsoft has any objections, can we just rename it
> back to what it's always been for everyone but us, SSL?

fwiw, the industry (and stackexchange) uses "SSL" to mean all sorts of things, not only TLS.  Yesterday i got an e-mail from a reputable CA reseller that said "Your SSL is expiring in two days!  Buy a new SSL now!"

Surely no one is proposing that we also re-name the X.509 certificate format to "SSL" just because vendors whose business models revolve around these products are confused about terminology.  What else should we rename to "SSL" on that basis?  Maybe a load-balancer is also "SSL"!

Here's a useful and effective meme for convincing bosses that it's ok to turn off SSLv3: all known versions of SSL are broken and should never be used.  Please do not break this meme by trying to rename TLS to SSL.

I don't care about the bikeshed over the number: i'd be fine with any of TLS 1.3 or TLS 4 or TLS 2017.  But can we please not create *even more* confusion by bikeshedding over the name itself?

      --dkg

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



U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

--------------------------------------------------------------------- --=_alternative 0067DC158625807D_=-- From nobody Fri Dec 2 11:05:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB2D129486 for ; Fri, 2 Dec 2016 11:05:20 -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 18gmj-3QGqAn for ; Fri, 2 Dec 2016 11:05:19 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA2981289C4 for ; Fri, 2 Dec 2016 11:05:18 -0800 (PST) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id A67DF284EAC for ; Fri, 2 Dec 2016 19:05:17 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <1480667592856.97451@cs.auckland.ac.nz> Date: Fri, 2 Dec 2016 14:05:36 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <05EC2930-F262-4D37-9FB9-6339AB0069B4@dukhovni.org> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Thor Simon List-Id: "This is the mailing list 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, 02 Dec 2016 19:05:21 -0000 > On Dec 2, 2016, at 3:33 AM, Peter Gutmann = wrote: >=20 > If no-one from Microsoft has any objections, can we just rename it = back to > what it's always been for everyone but us, SSL? I was with you up to this point, but I do think that going back to SSL = is not a good idea, and takes us off topic. Is there any glimmer of rough consensus on: * TLS 1.3 vs. * TLS 4 vs. * TLS 2017 vs. * TLS 2.0? Opening it up even wider seems like a sure way to get nowhere (which is likely status quo TLS 1.3). --=20 Viktor. From nobody Fri Dec 2 11:15:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E52F4129715 for ; Fri, 2 Dec 2016 11:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.091 X-Spam-Level: X-Spam-Status: No, score=-4.091 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AtbwoypmfeZp for ; Fri, 2 Dec 2016 11:15:46 -0800 (PST) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BEA1296C4 for ; Fri, 2 Dec 2016 11:15:46 -0800 (PST) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id D9512C163C for ; Fri, 2 Dec 2016 13:15:45 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id 4881BC15E6; Fri, 2 Dec 2016 13:15:45 -0600 (CST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B9CBF92072; Fri, 2 Dec 2016 14:05:46 -0500 (EST) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 6E4519206C; Fri, 2 Dec 2016 14:05:46 -0500 (EST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (unknown [207.46.163.114]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Fri, 2 Dec 2016 14:05:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iiUgrIPVOJyvT/5/fRn4cZtIW6ofVA48EMAUNG2dcrI=; b=pjnHRZ9B2HV23TLPsbyoKqyIwAbyqKUixJnUyqCjCIxmtV8MjsjB+0xvyh1QLK7UyKrgLmGcKC64O+Diq96OYOUpyshIoEkv7NdsBR8IXry3oS1HwYc1EoWkFQHUJM9S/RGCWU1Z/Wv+JibJVq3z6YI1xxfYQ6LWaUfWfJervE4= Received: from CY4PR14MB1368.namprd14.prod.outlook.com (10.172.158.148) by CY4PR14MB1365.namprd14.prod.outlook.com (10.172.158.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.9; Fri, 2 Dec 2016 19:15:42 +0000 Received: from CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) by CY4PR14MB1368.namprd14.prod.outlook.com ([10.172.158.148]) with mapi id 15.01.0761.012; Fri, 2 Dec 2016 19:15:42 +0000 From: "Ackermann, Michael" To: "darin.pettis@usbank.com" , Andrei Popov Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFbDwnoZvNGaEa/4tBFYw2nKKDwC7aAgAJbVICAAC0oAIAABEIAgAFpLoCAAA+9gIAABjwAgABRlgCAAAHGgIAAZTsAgABCyQCAAAWYgIAABZKQ Date: Fri, 2 Dec 2016 19:15:42 +0000 Message-ID: References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> <87y3zytn43.fsf@alice.fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com; x-originating-ip: [167.242.50.39] x-ms-office365-filtering-correlation-id: 50b5e489-45dd-40bf-9839-08d41ae79c5b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR14MB1365; x-microsoft-exchange-diagnostics: 1; CY4PR14MB1365; 7:5Kj78msTzqOHySjZK3aiOXSJAaSZZYkvliJHH1EXpIB4EYH+fZS9bMBcCZ+CviOocB9u0DHLQawHjv+yBIDrGPjW649grX5Ex35txcpY/0ZSsdjtEkv4y1VApD0NQxquLRBQPQLHtqhYHMEnH7X7n4vEZdxLNyUDrQb0zzUlH0nm6RJ/BS6YKeFDpnUZrNiejZMSTJnIITZmt+dXnlTYsAanWVez7HtjJ8/GsxqwvLThYoMWh4wg6hSouBpo72+gSvjKvx6xrrTGDeLbI0SvqnNf+5cdL1I3dBmdQfxfPES0gm7uxsotpN/ufQ27oqIBi6TFr4PpmW0wZrsjuHBGlba0+Varw7A2sSnkJftpzc8f4b89tNsYJf5suKnnFaiADSIvLNTDQoF9rrBY12mvBGuBmqAHAhpSj2p64PXnVQ4v+27/xmSppk3XNrL1g9H8J6G9TkWhzCKbQa9kUmZ9lw==; 20:hbdCC90NFyy63E/OdUgV4kdLe2+YNl/7l8jgzGWE1a1pmt/zj2ufChlbM1jXOBQANkmnd3yt478hbLd1kYTeltwGy/TzL83KsYVr1A2sCrUjBW0jzgMaoewVxKluBLQY9w8/nStSsMYXyJzFNIM6uC+vMGi2N7Vqx/qvW3xyq2c= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(2016111802025)(6043046)(6072148); SRVR:CY4PR14MB1365; BCL:0; PCL:0; RULEID:; SRVR:CY4PR14MB1365; x-forefront-prvs: 0144B30E41 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(189002)(13464003)(377424004)(24454002)(504964003)(4326007)(33656002)(8936002)(7906003)(38730400001)(2561002)(2900100001)(101416001)(584604001)(1511001)(9686002)(7846002)(92566002)(8666005)(2421001)(7736002)(68736007)(5660300001)(19609705001)(229853002)(5001770100001)(74316002)(80792005)(97736004)(86362001)(5890100001)(39450400002)(3280700002)(7696004)(66066001)(2906002)(189998001)(50986999)(81156014)(2501003)(3660700001)(39410400001)(8676002)(3846002)(76576001)(122556002)(6116002)(102836003)(790700001)(2950100002)(105586002)(99286002)(76176999)(81166006)(106356001)(77096006)(606004)(54356999)(106116001)(93886004)(6506004); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR14MB1365; H:CY4PR14MB1368.namprd14.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR14MB13683C85C0208865FC45965AD78E0CY4PR14MB1368namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Dec 2016 19:15:42.6816 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR14MB1365 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm02.z120.zixworks.com X-VPM-GROUP-ID: 436e147b-4cc1-4f5f-a7f5-5a1e7d71ccf4 X-VPM-MSG-ID: 37a6107a-f769-4fe3-b7bd-0bfa2d6ae0cf X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Cc: TLS , "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 19:15:51 -0000 --_000_CY4PR14MB13683C85C0208865FC45965AD78E0CY4PR14MB1368namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +2 On removing all references to SSL. From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of = darin.pettis=40usbank.com Sent: Friday, December 2, 2016 1:55 PM To: Andrei Popov Cc: TLS ; Subject: Re: =5BTLS=5D Confirming consensus: TLS1.3->TLS* +1 with Andrei. =22That SSL should never be used=22 is the one clear message we have so = going back to SSL would muddy those waters too much. Strong vote for = staying with TLS. It will become better known over time- especially with = the current enterprise push to deprecate all SSL versions from use. Regarding the numbering schema, someone recently mentioned that probably = only a few hundred of us are aware of the TLS 1.3 nomenclature at this = point and I would concur with that. So, after considering all of the good = points that have been circulating, I would like to change my vote to TLS = 2017. It provides clarity, recognizes that it is a major change and pulls = us out of the whole SSL/TLS numbering confusion/quagmire. Darin From: Andrei Popov = > To: Daniel Kahn Gillmor = >, Peter Gutmann = >, Stephen = Farrell >, = David Benjamin >, = Tony Arcieri >, = =22>=22 = > Date: 12/02/2016 12:34 PM Subject: Re: =5BTLS=5D Confirming consensus: TLS1.3->TLS* Sent by: =22TLS=22 = > ________________________________ Indeed, =22all known versions of SSL are broken and should never be = used=22 is what I've been telling people for a while now... -----Original Message----- From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Daniel Kahn = Gillmor Sent: Friday, December 2, 2016 6:36 AM To: Peter Gutmann = >; Stephen = Farrell >; = David Benjamin >; = Tony Arcieri >; = > = > Subject: Re: =5BTLS=5D Confirming consensus: TLS1.3->TLS* On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote: > If no-one from Microsoft has any objections, can we just rename it > back to what it's always been for everyone but us, SSL? fwiw, the industry (and stackexchange) uses =22SSL=22 to mean all sorts of = things, not only TLS. Yesterday i got an e-mail from a reputable CA = reseller that said =22Your SSL is expiring in two days=21 Buy a new SSL = now=21=22 Surely no one is proposing that we also re-name the X.509 certificate = format to =22SSL=22 just because vendors whose business models revolve = around these products are confused about terminology. What else should we = rename to =22SSL=22 on that basis? Maybe a load-balancer is also = =22SSL=22=21 Here's a useful and effective meme for convincing bosses that it's ok to = turn off SSLv3: all known versions of SSL are broken and should never be = used. Please do not break this meme by trying to rename TLS to SSL. I don't care about the bikeshed over the number: i'd be fine with any of = TLS 1.3 or TLS 4 or TLS 2017. But can we please not create *even more* = confusion by bikeshedding over the name itself? --dkg _______________________________________________ TLS mailing list TLS=40ietf.org https://www.ietf.org/mailman/listinfo/tls U.S. BANCORP made the following annotations --------------------------------------------------------------------- Electronic Privacy Notice. This e-mail, and any attachments, contains = information that is, or may be, covered by electronic communications = privacy laws, and is also confidential and proprietary in nature. If you = are not the intended recipient, please be advised that you are legally = prohibited from retaining, using, copying, distributing, or otherwise = disclosing this information in any manner. Instead, please reply to the = sender that you have received this communication in error, and then = immediately delete it. Thank you in advance for your cooperation. --------------------------------------------------------------------- The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY4PR14MB13683C85C0208865FC45965AD78E0CY4PR14MB1368namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif =21mso=5D><=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

&= =2343;2

O= n removing all  references to SSL.  

<= o:p> 

<= o:p> 

F= rom: = TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of darin.pettis=40usbank.com
Sent: Friday, December 2, 2016 1:55 PM
To: Andrei Popov <Andrei.Popov=40microsoft.com>
Cc: TLS <tls-bounces=40ietf.org>; <tls=40ietf.org> = <tls=40ietf.org>
Subject: Re: =5BTLS=5D Confirming consensus: = TLS1.3->TLS*

 

&= =2343;1 with Andrei.  

&qu= ot;That SSL should never be used" is the one clear message we have so = going back to SSL would muddy those waters too much.  Strong vote for = staying with TLS.  It will become better known over time- especially with the current enterprise push to deprecate all SSL versions = from use.  
Reg= arding the numbering schema, someone recently mentioned that probably only = a few hundred of us are aware of the TLS 1.3 nomenclature at this point = and I would concur with that.  So, after considering all of the good points that have been circulating, I would like to change = my vote to TLS 2017.  It provides clarity, recognizes that it is a = major change and pulls us out of the whole SSL/TLS numbering = confusion/quagmire.

Dar= in



From:        Andr= ei Popov <Andrei.Popov=40microsoft.c= om>
To:        Dani= el Kahn Gillmor <dkg=40fifthhorseman.net>= , Peter Gutmann <pgut001=40cs.auckland.ac.nz= >, Stephen Farrell <stephen.farrell=40cs.tcd.ie= >, David Benjamin <davidben=40chromium.org>= , Tony Arcieri <bascule=40gmail.com>, = "<tls=40ietf.org>" <tls=40ietf.org> =
Date:        12/0= 2/2016 12:34 PM
Subject:        Re: = =5BTLS=5D Confirming consensus: TLS1.3->TLS*
Sent by:        &quo= t;TLS" <tls-bounces=40ietf.org>




Indeed, "all known versions = of SSL are broken and should never be used" is what I've been telling = people for a while now...

-----Original Message-----
From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Daniel Kahn = Gillmor
Sent: Friday, December 2, 2016 6:36 AM
To: Peter Gutmann <pgut001=40cs.auckland.ac.nz= >; Stephen Farrell <stephen.farrell=40cs.tcd.ie= >; David Benjamin <davidben=40chromium.org>; Tony Arcieri <bascule=40gmail.com>; = <tls=40ietf.org> <tls=40ietf.org>
Subject: Re: =5BTLS=5D Confirming consensus: TLS1.3->TLS*

On Fri 2016-12-02 03:33:21 -0500, Peter Gutmann wrote:
> If no-one from Microsoft has any objections, can we just rename = it
> back to what it's always been for everyone but us, SSL?

fwiw, the industry (and stackexchange) uses "SSL" to mean = all sorts of things, not only TLS.  Yesterday i got an e-mail from a = reputable CA reseller that said "Your SSL is expiring in two days=21 =  Buy a new SSL now=21"

Surely no one is proposing that we also re-name the X.509 certificate = format to "SSL" just because vendors whose business models = revolve around these products are confused about terminology.  What = else should we rename to "SSL" on that basis?  Maybe a = load-balancer is also "SSL"=21

Here's a useful and effective meme for convincing bosses that it's ok = to turn off SSLv3: all known versions of SSL are broken and should never = be used.  Please do not break this meme by trying to rename TLS to = SSL.

I don't care about the bikeshed over the number: i'd be fine with any = of TLS 1.3 or TLS 4 or TLS 2017.  But can we please not create *even = more* confusion by bikeshedding over the name itself?

      --dkg

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




U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic = Privacy Notice. This e-mail, and any attachments, contains information = that is, or may be, covered by electronic communications privacy laws, and = is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally = prohibited from retaining, using, copying, distributing, or otherwise = disclosing this information in any manner. Instead, please reply to the = sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your = cooperation.

---------------------------------------------------------------------<= /o:p>


The information contained in this communication is highly confidential = and is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies.

Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan = are nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association.

--_000_CY4PR14MB13683C85C0208865FC45965AD78E0CY4PR14MB1368namp_-- From nobody Fri Dec 2 11:44:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0551C1296DC for ; Fri, 2 Dec 2016 11:44:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id REbKNbGsD-NS for ; Fri, 2 Dec 2016 11:44:33 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 26052129606 for ; Fri, 2 Dec 2016 11:44:32 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 304EB43344C; Fri, 2 Dec 2016 19:44:31 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 1A261433443; Fri, 2 Dec 2016 19:44:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480707871; bh=khzSz3fBuEgUIbty0ZZH5fX/SRHCe/RQpW8teR4Pil4=; l=186; h=From:To:CC:Date:References:In-Reply-To:From; b=Oy4zKbvMp+sim24mv7ky+iAx0QvslRN/WRI6RW2ZuW/MntISSYZuVGjiPUNIro64C qdyoPdoLsmSjkkGjc2Bw5XOt658UVB2JudymkACH+kXaFtKQA1lvjgDm4XpkD2rYo4 QyoXDBD4rXLvsmtqU0IUPNCvjjPHbvpvCABJd+uE= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1647E1FC88; Fri, 2 Dec 2016 19:44:31 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 2 Dec 2016 14:44:30 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 2 Dec 2016 14:44:30 -0500 From: "Salz, Rich" To: Yoav Nir , David Benjamin Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDwX4eAgAJbVYCAAC0nAIAABEIAgAFpLoCAAA++gIAABjwAgABRlQCAAAHGgIAAmkMAgAADtQCAAAbbAP//wsbA Date: Fri, 2 Dec 2016 19:44:30 +0000 Message-ID: <451a97316656443095adbd75d9efe074@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.77] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 19:44:35 -0000 DQo+IENhbuKAmXQgd2UgYm9ycm93IG9uZSBmcm9tIHRpY3RvYz8NCg0KRXZlciBzaW5jZSB0aGV5 IG1lcmdlZCB3aXRoIE5UUCwgaXQgc2VlbXMgdG8gYmUgbG9zdCBpbiBhIHRpbWUgbG9vcCBhbmQg bm9ib2R5IGNhbiBmaW5kIGl0Lg0K From nobody Fri Dec 2 11:46:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C2FC12951F for ; Fri, 2 Dec 2016 11:46:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.597 X-Spam-Level: X-Spam-Status: No, score=-5.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmpAGaPOXtkz for ; Fri, 2 Dec 2016 11:46:17 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 18C3112943A for ; Fri, 2 Dec 2016 11:46:17 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 992D7433434; Fri, 2 Dec 2016 19:46:16 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 82B5D433407; Fri, 2 Dec 2016 19:46:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480707976; bh=4KTFSY9eoml2BlxPhCZJUO50HoNhGfhrkCrkr/riMss=; l=141; h=From:To:CC:Date:References:In-Reply-To:From; b=0BccMbLwU7S7xW7/2akeksWK8PAGvs+huff4StrVCz3R8TGc0fZoZyw48ukj/SMNI 1iFWtRkOSevwyixPAY/iJAqcR8MgTzgtzQHd3OtcF0HvvQWgMVXLJdbwwhczDXgPZJ kVro/2RNDMu3rw0qDIvGegGuDMygrohiXpPkGaBk= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 7E6511FC88; Fri, 2 Dec 2016 19:46:16 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 2 Dec 2016 14:46:15 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 2 Dec 2016 14:46:16 -0500 From: "Salz, Rich" To: "darin.pettis@usbank.com" , Andrei Popov Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDwX4eAgAJbVYCAAC0nAIAABEIAgAFpLoCAAA++gIAABjwAgABRlQCAAAHGgIAAZTsAgABCyQCAAAWYgP//umfw Date: Fri, 2 Dec 2016 19:46:15 +0000 Message-ID: <8c77c271c3d34369acd6934a8b4060dd@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz> <87y3zytn43.fsf@alice.fifthhorseman.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.77] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 19:46:18 -0000 > after considering all of the good points that have been circulating, I wo= uld like to change my vote=20 Woah, are you new here? :) From nobody Fri Dec 2 11:58:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 392CC124281 for ; Fri, 2 Dec 2016 11:58:33 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=azet.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3QJ0uXTdgnR for ; Fri, 2 Dec 2016 11:58:31 -0800 (PST) Received: from mail-wj0-x232.google.com (mail-wj0-x232.google.com [IPv6:2a00:1450:400c:c01::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 3D4ED126BF7 for ; Fri, 2 Dec 2016 11:58:31 -0800 (PST) Received: by mail-wj0-x232.google.com with SMTP id mp19so241471289wjc.1 for ; Fri, 02 Dec 2016 11:58:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=kn+BvQTTi53WVEqiIKayHa8zpbBrCasyvocqg1d8Tow=; b=atPVIW0w1p8yAzGPEnfLS8KBKO2hhfUueVfLr9H5UtVT5At16EuI3SOpjUgFfv17bv K7NpHMZ/Y/WRa5mWhnN0d2fdcBeMR+Jp+MsAtZ1PLyBbvhxnKlSbantmtL9CQpHWKUys rUm2RoIBR/9T6ANS4VYAjVIa/jVBXBWpko+Ek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=kn+BvQTTi53WVEqiIKayHa8zpbBrCasyvocqg1d8Tow=; b=aqPNffZzKDwkdlbfvxpsMOMuo6l68v6MhGmL6zHXUFZScBRtpu1SPqNWTdsvSLutLi SznqKeoXVgKi0397kodoix0fDjcZSVXlzSr3XdtWXGYmWTfAJ0ZbNVgQ4zQ6YhSrRpL3 f+0YQHvrViknqFI9crTzx2/A3c9i/N3vd+ZpZn5S+nWWPtAZfXxTuJx8OgUcZ6Ji4spI 13oWdt6yozOP7nZ9ooQSRkFM5Lzf9PMIchlB9JBqpGMQil3gYRXXG4SlrEJPzAhUEX07 Iw1eA1fMndtBNxPBq6UiCT3U7bZDgcrvUXJQKo0CvfSMJ/SCLJ68a+kVwdgJ90p35yNI PGuw== X-Gm-Message-State: AKaTC01vHV0cP6zRZ25+C9kNsV8hhGoPrDmIrdMkwXDiZILvN3+41FUDZb8JfSJlrEEZvg== X-Received: by 10.194.176.10 with SMTP id ce10mr12437790wjc.155.1480708709565; Fri, 02 Dec 2016 11:58:29 -0800 (PST) Received: from typhoon.azet.org (80-108-49-181.cable.dynamic.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id b7sm7134826wjm.39.2016.12.02.11.58.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 11:58:28 -0800 (PST) Date: Fri, 2 Dec 2016 20:58:27 +0100 From: Aaron Zauner To: Sean Turner Message-ID: <20161202205638.67c3882366@4ac7a46126f5bbe> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3MwIy2ne0vdjdPXF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 19:58:33 -0000 --3MwIy2ne0vdjdPXF Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Sean Turner [18/11/2016 03:13:23] wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should= rebrand TLS1.3 to something else. Slides can be found @ https://www.ietf.= org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. >=20 > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not= rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision = on the list so please let the list know your top choice between: >=20 > - Leave it TLS 1.3 Please let's keep it to TLS 1.3 which we have been talking about for a couple of years now, no-one expects a protocol from this WG with a different name (of course I'd opt for SSLv5 just to mess with people). Aaron --3MwIy2ne0vdjdPXF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYQdJhAAoJEOTbZJL9ubXVndsP/0fSyvMtgrbo2NX3I5KIDF31 w8357S26Qk1KekCFnVolNaRwnB1jo98jQKK9Cbr7jbPft0p9QHldc08RjhLw2pDh zJCHoiO8aWYq0ymj2Uq0NdZjwvqSySq/JTU3AR8acgee+rVT3Jo3ALLGgqWNFVD4 thjS4Nnm16If8sInc4hBu8A+aYztK73cd2w6anPOWNQoMzyiz+1K8qIt/AvvLFUy BhkcpFXUDGR5JSaoxSn7Z8SCVtPTsoBxBphd0iGWkquUO3asTm3YILr9AqZCmGgB o7VbJFzEBGY1g4YiklGYXAmOU8Igl2kbXBBFv9QayXpCqRxVZqxUzoKAnDH4v8Yl 2B79EkEnUWLbFuwwctQuOFey2/gb0+c2U43W/BAL8UKqiyvWBd1UQDScBUcwTO4B JGQ3WfHYDvf+gTLK5KAVOUWqePW+HZ3CqmMzRnq5eab+boLdi8Wo++GDLW+RhbEU PVinIPGr5GK0Q2WPcmPi0bbpGo4FonWi1C5lVYqSER35fMd/sFqATHU1G0+knk4A 62E+jw3U0lYxuVX3nrJcpuXAWu1WrY7YZkLQRcKZ4tvUoMlv4iV+3CRKSV++gpV1 GE6xZSCSg+T7UK5x0V+nNjllFSVYcTCXSdlaRDz/Tp1kS0XwFRygu/uoE7GlfcDz Ftz0Zp1S8YLQjCyWNG+4 =LrK1 -----END PGP SIGNATURE----- --3MwIy2ne0vdjdPXF-- From nobody Fri Dec 2 12:06:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1266F1204D9 for ; Fri, 2 Dec 2016 12:06:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.576 X-Spam-Level: X-Spam-Status: No, score=-4.576 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com; domainkeys=pass (1024-bit key) header.from=mike-list@pobox.com header.d=pobox.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UJrwfWWdi9jP for ; Fri, 2 Dec 2016 12:06:11 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A008412007C for ; Fri, 2 Dec 2016 12:06:11 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 98F3252A63 for ; Fri, 2 Dec 2016 15:06:10 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=message-id :date:from:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; s=sasl; bh=rdpAADKSqwHn 8SCfrX6WNBhJVJ4=; b=k6NU2k0Hxq3PzBhXM7Gf8XxlhZMMVNSS3krTmJWtMlW9 vLnXwIeGKIkx5QQFwPoK328bmHBiaWCCt4Muw832oYpadrfqgEjucOIe6Y+tM1Rm pL7XCTsil1GFdzRqGyehxjlceO8gZS7uf8OjQfoKXXnrp1JSrllDf8pzsJYX9rY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=message-id:date :from:mime-version:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; q=dns; s=sasl; b=ah/vPF 9PN4Lq9nf/fu/zNOv18GwtMjDfeB7aGxQ2wxPq3o8jP10lNX7I44TQvaqD6OLS7L KT3SVWlJAqD7qf9bCiLbDZamOfqInm2MFHrG/1TZXePQy9X0/DezX3hzjUrc71/i OFIP60jjqGxRYuhSiTJAIsHjR4U7ARPztL1kk= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 91EEC52A62 for ; Fri, 2 Dec 2016 15:06:10 -0500 (EST) Received: from iMac-2.local (unknown [174.71.255.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 1407752A61 for ; Fri, 2 Dec 2016 15:06:09 -0500 (EST) Message-ID: <5841D430.9060409@pobox.com> Date: Fri, 02 Dec 2016 12:06:08 -0800 From: Michael D'Errico User-Agent: Thunderbird 2.0.0.24 (Macintosh/20100228) MIME-Version: 1.0 CC: TLS Mailing List References: <20161202205638.67c3882366@4ac7a46126f5bbe> In-Reply-To: <20161202205638.67c3882366@4ac7a46126f5bbe> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Pobox-Relay-ID: C48BF2E2-B8CA-11E6-92C3-B2917B1B28F4-38729857!pb-smtp2.pobox.com Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 20:06:13 -0000 Aaron Zauner wrote: > > (of course I'd opt for SSLv5 just to mess with people). I'm surprised nobody has yet suggested retroactive renaming: SSLv4 == TLS 1.0 SSLv5 == TLS 1.1 SSLv6 == TLS 1.2 SSLv7 == TLS 1.3 Mike From nobody Fri Dec 2 12:09:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 391411293E1 for ; Fri, 2 Dec 2016 12:09:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] 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 MBtjRsgbIgcX for ; Fri, 2 Dec 2016 12:09:28 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id A6E491293F3 for ; Fri, 2 Dec 2016 12:09:15 -0800 (PST) Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com [209.85.216.177]) by linode64.ducksong.com (Postfix) with ESMTPSA id E1DE33A015 for ; Fri, 2 Dec 2016 15:09:14 -0500 (EST) Received: by mail-qt0-f177.google.com with SMTP id w33so262248953qtc.3 for ; Fri, 02 Dec 2016 12:09:14 -0800 (PST) X-Gm-Message-State: AKaTC00748jmlbz4/J1pd8SrulU7oJSP4V1aGo0ZbJEXmPrr3Ut6LE/ACrBBnHokegHzIPQkdO7cp95bibL2Fw== X-Received: by 10.200.52.4 with SMTP id u4mr43437303qtb.186.1480709354475; Fri, 02 Dec 2016 12:09:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.147.78 with HTTP; Fri, 2 Dec 2016 12:09:13 -0800 (PST) In-Reply-To: <20161202205638.67c3882366@4ac7a46126f5bbe> References: <20161202205638.67c3882366@4ac7a46126f5bbe> From: Patrick McManus Date: Fri, 2 Dec 2016 15:09:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a114062fe16fb1f0542b2830a Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 20:09:31 -0000 --001a114062fe16fb1f0542b2830a Content-Type: text/plain; charset=UTF-8 I favor naming the result tls 1.3 - the X in 1.X has effectively become the modern versioning field and we should stick with that road now as the best of a bunch of weak options. -Patrick --001a114062fe16fb1f0542b2830a Content-Type: text/html; charset=UTF-8
I favor naming the result tls 1.3 - the X in 1.X has effectively become the modern versioning field and we should stick with that road now as the best of a bunch of weak options.

-Patrick

--001a114062fe16fb1f0542b2830a-- From nobody Fri Dec 2 13:10:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7AF1293F9 for ; Fri, 2 Dec 2016 13:10:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 s995weiOA__g for ; Fri, 2 Dec 2016 13:10:42 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 488C8128E19 for ; Fri, 2 Dec 2016 13:10:41 -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=1480713042; x=1512249042; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=AHwzJMdEOX4iYFPxgWPW5GezKukTHMeEUhoq5em+V9c=; b=VOCges+tdcS3maoHh5B8HBziwTedQcw4+O2eFX4KIQdw/otGRZgo7wik uyFI1NLNIkKZUuexueVtZ+vx3COPTGjy9h2kpH7erh5y/hqwMgNQhU6b0 puNrt8WMElkxAyI5pbluULnCQu9sqp4iSM9opleNdjBse1VPB97R7y6QD jW46ALhM0szILu4PhAnzaRnw//vPoxdEgqfRbXYkAYoK1vPAihomN8QBN SU8GKx7a7rxNEQ82GWqIL4W44c4jerPM5wefAzQDRhYSiBIh6RCBrN07o F1crV/43q4iFFsXjJE8UHiwZC624xv0WR56L2XMfQejdEqHOUnOe8Q5qD g==; X-IronPort-AV: E=Sophos;i="5.33,288,1477911600"; d="scan'208";a="118552145" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Dec 2016 10:10:40 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 3 Dec 2016 10:10:39 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 3 Dec 2016 10:10:40 +1300 From: Peter Gutmann To: Hubert Kario , "Salz, Rich" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfD667DaatoU6RNleDGo1T66DwCVTAgAGDyICAAQa6CP//KrAAgAFpLoCAAOlzA///rBIAgAArigCAAAVnAIAAAaoAgAAIWoCAAUY33Q== Date: Fri, 2 Dec 2016 21:10:39 +0000 Message-ID: <1480713030492.99579@cs.auckland.ac.nz> References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com>, <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> In-Reply-To: <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:10:45 -0000 Hubert Kario writes:=0A= =0A= >speaking of confusion, do you know that e-mail clients by "SSL" mean=0A= >"SSL/TLS" and by "TLS" mean "STARTTLS"? (note the port numbers)=0A= >https://sils.unc.edu/it-services/email-faq/outlook=0A= >https://mail.aegee.org/smtp/kmail.html=0A= >https://sils.unc.edu/it-services/my-computer/email-faq/thunderbird=0A= =0A= Ugh, how very geeky, all the charm of fetchmail with a GUI bolted on. The= =0A= fact that security geeks suck at UX isn't really proof of anything (other t= han=0A= that you need to let interaction designers do your UX, not security people)= .=0A= =0A= With Apple Mail, all you have to do is click on "Use Secure Sockets Layer" = and=0A= you're done (note the name). With the Android mailer I use it's not even= =0A= that, it's autoconfigured, just point it at your email domain and give a=0A= username and password.=0A= =0A= Peter.= From nobody Fri Dec 2 13:12:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB6091293FE for ; Fri, 2 Dec 2016 13:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-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 XO4hCOYm3ahL for ; Fri, 2 Dec 2016 13:11:57 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86F13120725 for ; Fri, 2 Dec 2016 13:11:57 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id n21so292025392qka.3 for ; Fri, 02 Dec 2016 13:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ruUHIda6mhMJdrNMmEqQHoMcBu/dH3FmVO6tSLC5ob4=; b=QzWsgufbECButFNDjJdScwtGuQXPE0lKOcCao6kioFd5AejCEPPkfMXJNF908wdjhO sggOwsBSQxP1jhCR/B9FCBfOyXeonoVgEihpqQ1FYY+BTxH4jCj4Ny3LKSCvJVoehHuO tfj0/ESxJpULFSd9PJw58C1Dhd7aJfSJyRP0KXcHRHmKzfDxSo1hwU1pvWgPSMmGqqWS kQObgVaQsZjxBAu+Lm2gDlEG3lhSYKa5UNfImaSQL9KE8NQ+FHLj/0hs1lUgzsScmzdV UKu9Oi+1h1fwQPli+iZ6q8MsTcp6itSmEKguqCscwyjWPQDw8FQuNdbXofF/hZq4LYaP q75A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ruUHIda6mhMJdrNMmEqQHoMcBu/dH3FmVO6tSLC5ob4=; b=BsgIyrNwOXmCsjIswz8Q7+ZERahgpo8law0xpPQWm5WS0DGeYp6wnFXt9mRUEtlSoU aVtvEa8ksExWadAUdhe5Mmk3Sp9W5c75ttdX2NFKLknRmDquEkfMPgEEWjMN0uuXIMvs VLDOD9L/zqyAmUFDviCJgD7nR8Dp6kn9PHkSLdw9RzZEDoRjEBhqouvWfctin9qIxO50 ofH4fB6KdCTQY29c9YykADe0FFFAgd7/mNSTtBbeH28Iqx+cX+UHYXRRsEt2J3O4HHBN FGRBMmW/iuEfxHThQyzLr7v4gjZBXiWUoK4HvDd1+rdMTlYbtYFBB3gxa943+qPjgTN4 DE/A== X-Gm-Message-State: AKaTC01tFiP/mRB0uAvp9h70qNZJGlljxUskXGHdNWm/BbBAiBbMR/+MOxV5Eu/dEmSQsA== X-Received: by 10.55.8.20 with SMTP id 20mr45235705qki.3.1480713116700; Fri, 02 Dec 2016 13:11:56 -0800 (PST) Received: from [10.0.20.218] (c-73-167-64-188.hsd1.nh.comcast.net. [73.167.64.188]) by smtp.gmail.com with ESMTPSA id i41sm3511409qtc.18.2016.12.02.13.11.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Dec 2016 13:11:54 -0800 (PST) From: Ted Lemon Message-Id: <1581874A-9BFE-447F-A3E1-2703DFC8E60B@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5EB32F6A-B60C-4E0B-A92A-B093DE6F7C63" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Fri, 2 Dec 2016 16:11:51 -0500 In-Reply-To: <1480713030492.99579@cs.auckland.ac.nz> To: Peter Gutmann References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> <1480713030492.99579@cs.auckland.ac.nz> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:12:00 -0000 --Apple-Mail=_5EB32F6A-B60C-4E0B-A92A-B093DE6F7C63 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On Dec 2, 2016, at 4:10 PM, Peter Gutmann wrote: > Ugh, how very geeky, Really? --Apple-Mail=_5EB32F6A-B60C-4E0B-A92A-B093DE6F7C63 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii On Dec 2, 2016, at 4:10 PM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
Ugh, how very geeky,

Really?

--Apple-Mail=_5EB32F6A-B60C-4E0B-A92A-B093DE6F7C63-- From nobody Fri Dec 2 13:21:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 876EA129407 for ; Fri, 2 Dec 2016 13:21:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 DhcGu1XhO3hO for ; Fri, 2 Dec 2016 13:21:38 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E720129401 for ; Fri, 2 Dec 2016 13:21:37 -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=1480713698; x=1512249698; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KpTdL5Nk9ix9oxKZBqA8RQC5/TLiyJ3NUlHTZgFE+w8=; b=idQ0AZQdKJZJORv2T4ASmkpzL+Di7WmtQvLuSOZjZFbcZIFeOdMGx+hL XfnzO+h335ffs03okzMdqCYOksjpP02p8CcRmbuWDD7VaxkSAnLmf+5XM FvnRT0Oo8n+hYw0xIA2CHOWG/MgezpRaK4NommAhibBh2torcV+S/i6eb FsEaAbYR3uTrXCPRpatqMiBm7JNjXBJ+HVEtnu6NBoWOPt3EO5VCI4tpY Pv8De/wtSOBYla5s7BsInlVjxDbUrAx5PKHNoSDV6KwHQBO20HgvSmW75 T/0oTQ+ckS8TrMwRZP7KxFjGUZm45cWz4HlFz1uwohuPBFISgpsuorf5K w==; X-IronPort-AV: E=Sophos;i="5.33,288,1477911600"; d="scan'208";a="118553454" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Dec 2016 10:21:36 +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 Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 3 Dec 2016 10:21:36 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 3 Dec 2016 10:21:36 +1300 From: Peter Gutmann To: Maarten Bodewes , Ted Lemon Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfD667DaatoU6RNleDGo1T66DwCVTAgAGDyICAAQa6CP//KrAAgAFpLoCAAOlzA///rBIAgAArigCAAAVnAIAAAaoAgAAIWoCAAANTgIAAEwgAgAEy93Q= Date: Fri, 2 Dec 2016 21:21:35 +0000 Message-ID: <1480713686960.84870@cs.auckland.ac.nz> References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> , 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:21:40 -0000 Maarten Bodewes writes:=0A= =0A= >The point is we are now indeed on draft 18. Changing the name now is very= =0A= >problematic because everybody on the mailinglist already calls it TLS 1.3,= =0A= >for a long time and no matter what you do, a lot of us (who are hopefully = the=0A= >experts) will keep referring to it under that name.=0A= =0A= The change was proposed long ago, and deferred by the chairs until now.=A0 = This=0A= is just another variant of the inertia argument.=0A= =0A= Peter.=0A= =0A= = From nobody Fri Dec 2 13:27:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3533129418 for ; Fri, 2 Dec 2016 13:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 32CPplHmZYuG for ; Fri, 2 Dec 2016 13:26:52 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41908128E19 for ; Fri, 2 Dec 2016 13:26:47 -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=1480714007; x=1512250007; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=xaBbBXuVvNJd76wzh1kP9kcW83mtw8dRU/KYrzi3TP8=; b=yJOlTOQQrEIvqwi6AjtFa45YFG0cUnWrN11KiS/3ecdq9FLJX+ip37+v jFxyGapHhrbqXbuXgX/Jm5d5Flo0kQYD0Ua1kR+3BfKX1GbkQBNVP0y3j YUXQj3JPMq7voL9tj6f7YNDnd3dD1us1urmDH/8pNbDyaSYceJuIQROi8 sKlmoYjfSe7WMdYauNLIUnzmSaWTze+u1icdnNnoyszY/KydzivIcJnWX 1gN2iLqaAiYbsWruzCJ2td+vEVTI49rkC8M5PeJjUfrYi5KXL/3dmCut/ BJ/n9M616DTfLUZbbLwbmpMRgdXVswdvwY4BOStKXZG8Dw4x7jNk/9R9q Q==; X-IronPort-AV: E=Sophos;i="5.33,288,1477911600"; d="scan'208";a="118553994" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Dec 2016 10:26:45 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.25) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 3 Dec 2016 10:26:45 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 3 Dec 2016 10:26:45 +1300 From: Peter Gutmann To: "" , Thor Simon Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfD667DaatoU6RNleDGo1T66DwCVTAgAGDyICAAQa6CP//KrAAgAFpLoCAAOlzA///LIYAgABRlgCAANucOf//1tAAACAig5Y= Date: Fri, 2 Dec 2016 21:26:45 +0000 Message-ID: <1480713996834.82440@cs.auckland.ac.nz> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> <0836012d-b4dc-f24c-034f-69f3b7121334@cs.tcd.ie> <1480667592856.97451@cs.auckland.ac.nz>, <05EC2930-F262-4D37-9FB9-6339AB0069B4@dukhovni.org> In-Reply-To: <05EC2930-F262-4D37-9FB9-6339AB0069B4@dukhovni.org> 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] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 21:26:54 -0000 Viktor Dukhovni writes:=0A= =0A= >I was with you up to this point, but I do think that going back to SSL is = not=0A= >a good idea, and takes us off topic.=0A= =0A= It was just something to throw out there, and to point out that no matter w= hat=0A= the WG calls it, the rest of the world will keep calling it SSL. It's been= =0A= twenty years, it's not going to change any more now.=0A= =0A= >Opening it up even wider seems like a sure way to get nowhere (which is=0A= >likely status quo TLS 1.3).=0A= =0A= Yeah, fair enough. It would be nice to finally fix a 20-year-old mistake t= hough.=0A= =0A= Peter.= From nobody Fri Dec 2 14:16:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 137C7129446 for ; Fri, 2 Dec 2016 14:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7bziOK4McQN for ; Fri, 2 Dec 2016 14:16:38 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E628129429 for ; Fri, 2 Dec 2016 14:16:38 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id x186so153282237vkd.1 for ; Fri, 02 Dec 2016 14:16:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mcq10ri3lH6MiOHBC20U6QFHUHcvJKxxwqjiA5msFGM=; b=dEs42f/N0wbyyoBDmCfG27H6gPoHIp/WbcChF/JGl7Qd3OiOqqw+JkarABDH5s0PmW +pbMJaoDy477VfNFIwaxSBb82dA2BS7GFzwokzntk6M+RALiCS7niBDJsEF+nTWSGYTB pBr8aO+MnnpLmbw6cK7t37kOIHldx0yDbLaWmP3UF2Ww+csuG8p9/fj/YEJ1PFb65aJZ dskCMopsOFfqT4/YQkq/FdU6jFC9BFYaU36zpvJZb0ZH9kCk8YlqXyz9BVZLYm01Qylz 4/Bzfyr47zjd6lQY7aoYHMZZQRDCXD8EeNunFPxw/LlhLwIovJzXVNA1fVnAMYn7ha+I wK1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mcq10ri3lH6MiOHBC20U6QFHUHcvJKxxwqjiA5msFGM=; b=A0vjz2PA0O78PVYqNugnDc3/LCyqMS3U6WMqdSIkTGUxQKSlxwR8DN3yZGKRendZGV xsV4b+ECF+ztKnWpHVDEtYM5We/2xlcthKwir7XB20tyKboN/8BmBhutS+/wgYbAKmLO NmOzMvRhDI1+E8DhtWebHuHPRcJsWxWTQpEUA6mHpk6ohIGvq1ouaQ+CJMVmgeMZ/YbY 1FQaDlrYg6TZ790eXr4jxJxJE/xwgcGNWhDxmw0LnpTIzoZTiAaYGFTl9YDQJUi7MmfT Mj4KQfu9wq6IgnljAIC5LGGP7bY88RrYeVkYxpnQOwu0NmmXVhrCr10SWYxkRln4A+HQ 7k5g== X-Gm-Message-State: AKaTC00sb8GMblD9xV2Oplfmu4rgTzGnAsmiHT04waEgaGhNZ4IN/JFi6zomIySkbP0LVpfqn3u+6Ufs1wCgWw== X-Received: by 10.31.98.3 with SMTP id w3mr17936472vkb.20.1480716997562; Fri, 02 Dec 2016 14:16:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.145.144 with HTTP; Fri, 2 Dec 2016 14:16:16 -0800 (PST) In-Reply-To: <1480713686960.84870@cs.auckland.ac.nz> References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> <1480713686960.84870@cs.auckland.ac.nz> From: Tony Arcieri Date: Fri, 2 Dec 2016 14:16:16 -0800 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=94eb2c0951a2a71b0f0542b44a71 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Dec 2016 22:16:41 -0000 --94eb2c0951a2a71b0f0542b44a71 Content-Type: text/plain; charset=UTF-8 On Fri, Dec 2, 2016 at 1:21 PM, Peter Gutmann wrote: > The change was proposed long ago, and deferred by the chairs until now. > This > is just another variant of the inertia argument. You keep dismissing this argument out of hand, but I think it has merit. I think we can all admit the decision to rename SSL -> TLS is a mistake (to the point people are proposing to retroactively re-rename TLS back to SSL). There is now a huge body of work which calls the protocol "TLS 1.3" which will be cited for years to come. You wrote this whole body of work off as the concern of "TLS WG and a small number of people who interact with it" as if a move to a different version number comes at zero cost almost as if this work doesn't matter, but I have a different view: this is one more bit of errata in exactly the same vein as the SSL -> TLS move which anyone consulting this body of work will have to contend with. You will no doubt disagree, so I'm simply saying it for posterity: keeping the version TLS 1.3 is the least confusing option, IMO. -- Tony Arcieri --94eb2c0951a2a71b0f0542b44a71 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 2, 2016 at 1:21 PM, Peter Gutmann <pgut001@cs.auckland.ac.= nz> wrote:
The change was proposed long ago, and deferred by the chairs until now.= =C2=A0 This
is just another variant of the inertia argument.

You keep dismissing this argument out of hand, but I think it has mer= it.

I think we can all admit the decision to renam= e SSL -> TLS is a mistake (to the point people are proposing to retroact= ively re-rename TLS back to SSL).

There is now a h= uge body of work which calls the protocol "TLS 1.3" which will be= cited for years to come. You wrote this whole body of work off as the conc= ern of "TLS WG and a small number of = people who interact with it" as if a move to a different version numbe= r comes at zero cost almost as if this work doesn't matter, but I have = a different view: this is one more bit of errata in exactly the same vein a= s the SSL -> TLS move which anyone consulting this body of work will hav= e to contend with.

You will no doubt disagree= , so I'm simply saying it for posterity: keeping the version TLS 1.3 is= the least confusing option, IMO.

--
<= div class=3D"gmail-m_6082946429572102653gmail_signature">Tony Arcieri
--94eb2c0951a2a71b0f0542b44a71-- From nobody Fri Dec 2 19:34:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54CD12957A for ; Fri, 2 Dec 2016 19:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bU9L0gmyCaP9 for ; Fri, 2 Dec 2016 19:34:38 -0800 (PST) Received: from mail-vk0-x231.google.com (mail-vk0-x231.google.com [IPv6:2607:f8b0:400c: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 0ADE9129575 for ; Fri, 2 Dec 2016 19:34:38 -0800 (PST) Received: by mail-vk0-x231.google.com with SMTP id p9so155726270vkd.3 for ; Fri, 02 Dec 2016 19:34:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=06t5vLhcKlT4aWj/6xyKLn7OsB7Be4lvCv7h+4xnzzk=; b=ycMVJc5IV47eaUbHgxkO97ZbMWZpPZg1aujvmWgf0BNfQP83iKgI64pA5VgYHDR2XH XzO7EeShvNBGNdAlX7VyBLERr5M/BbPLb3juv9giaQUiK1bsXtzYb4NaAIT2lWALMJL7 SZkTgV134jO+tvX2Hn4t5QAicqFB4MA47Pvplpcc4DBDEoxcag7JK55Yx3+rnf7AZLon YVtJ3z8EBc39XVTzR+I4tKC0DKYRCMQFGAECtPCHAljcFW7IsgX+UWjcekumUc1BmPYd kgHHTeg502eqGRpSbVWvM7sz46pVUHNA59f4g60C4BPKI+g3FSJ8CEdqcb7JOgcRrscZ TJDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=06t5vLhcKlT4aWj/6xyKLn7OsB7Be4lvCv7h+4xnzzk=; b=eSY6HcyOlqC3xGMx3NoQhif9KdbR5wqYuk9+1yM9f2LbOOu4nY47frhI+jTq4G4W19 x8B1Gq88ftwNrWPGUplUznRSqwtXgLEjteuOfbNGOOSLq/ZTGiSvl6E+CC/rxr3Isv14 qGxGAAVWYD6xqPFVHYjbTfA5cb7miGlu9mcmFj6qAqu9QBQkK58OAYSQiOjlAGvqkaP0 iUWgjWvwRAHv1ZKheoJGcX4czDpeoWm31eVGANGXxgdTEYr4TcBU42Ll5eVXResxtqhF Vana0u2/CiLSr0Xe/SOmOrdWTNmB4Cv8HQCVm41Lz2KhEqsng8NK77Vc3KABmKlwKX3M LpIA== X-Gm-Message-State: AKaTC01k4X4xToOJ4TRvbYN5i+Wns9KVv+id3P9ex//vhxs0RCf0Fl+4z0vhJHzpOeR4DfSSzfW2pCRC3KQpug== X-Received: by 10.31.170.208 with SMTP id t199mr15341575vke.6.1480736077160; Fri, 02 Dec 2016 19:34:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.145.144 with HTTP; Fri, 2 Dec 2016 19:34:16 -0800 (PST) In-Reply-To: References: From: Tony Arcieri Date: Fri, 2 Dec 2016 19:34:16 -0800 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a11432a6ae2ada30542b8bbde Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 03:34:40 -0000 --001a11432a6ae2ada30542b8bbde Content-Type: text/plain; charset=UTF-8 On Thu, Nov 17, 2016 at 6:12 PM, Sean Turner wrote: > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. I guess we're at the deadline, but I have a compromise I think makes sense: - Keep this version TLS 1.3 - For the next version of TLS, drop the 1.x and call it TLS 4 -- Tony Arcieri --001a11432a6ae2ada30542b8bbde Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 17, 2016 at 6:12 PM, Sean Turner <sean@sn3rd.com> wrote= :
The consensus in the room was to leave = it as is, i.e., TLS1.3, and to not rebrand it to TLS 2.0, TLS 2, or TLS 4.= =C2=A0 We need to confirm this decision on the list so please let the list = know your top choice between:

- Leave it TLS 1.3
- Rebrand TLS 2.0
- Rebrand TLS 2
- Rebrand TLS 4

by 2 December 2016.

I guess we're at th= e deadline, but I have a compromise I think makes sense:

- Keep this version TLS 1.3
- For the next version of TLS,= drop the 1.x and call it TLS 4=C2=A0

--
Tony Arcieri<= br>
--001a11432a6ae2ada30542b8bbde-- From nobody Fri Dec 2 19:49:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98D67129593 for ; Fri, 2 Dec 2016 19:49:04 -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 4oQBkZVvKrLR for ; Fri, 2 Dec 2016 19:49:03 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE945129592 for ; Fri, 2 Dec 2016 19:49:02 -0800 (PST) Received: from [172.31.24.203] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 99FA8284EAC for ; Sat, 3 Dec 2016 03:49:01 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Fri, 2 Dec 2016 22:49:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "" List-Id: "This is the mailing list 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, 03 Dec 2016 03:49:04 -0000 > On Dec 2, 2016, at 10:34 PM, Tony Arcieri wrote: >=20 > The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this = decision on the list so please let the list know your top choice = between: >=20 > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 >=20 > by 2 December 2016. >=20 > I guess we're at the deadline, but I have a compromise I think makes = sense: >=20 > - Keep this version TLS 1.3 > - For the next version of TLS, drop the 1.x and call it TLS 4=20 That "next version", will perhaps be the one after the QC = crypto-apocalypse... More seriously I don't expect another TLS version after this for a = decade or so. The adoption cycle is so long, it makes little sense to rev the protocol with any frequency. So get it right now, near-term revisions seem unlikely. So I see your proposal as not a compromise, but rather as staying with the status quo, for better or worse and for quite some time... --=20 Viktor. From nobody Fri Dec 2 19:58:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6371295A2 for ; Fri, 2 Dec 2016 19:58:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BopmWP4NIOVD for ; Fri, 2 Dec 2016 19:58:07 -0800 (PST) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (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 741B612959B for ; Fri, 2 Dec 2016 19:58:07 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-03v.sys.comcast.net with SMTP id D1SXcvhd5MppVD1SgcBwYE; Sat, 03 Dec 2016 03:58:06 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1480737486; bh=ztRkQO5zRftppY3UICY2w8LS3J3s5lfbhzuSq2fX64A=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=VNRr5WYq/1RVkFXVo2vpdacYswXeNN/kFhNWzWFGHps59BJk1l9bDd/u7WtiJudZT Rxz1kqOa9Jj5tSA3KsN6fyQ91Sk9g1nLdkGQjiKTCSdUvTSPwHrru++Hkllv6NcHeD AnLxfsGj/fdXeklhSAu2pY9h6ud2K+GWk5sH8evhMCCq337TOmBYOSPaYiU0G2EumD 5AFgY/A6I7Q1DSCpuz+tlaMWjAY4nRnYjCGeRemNvSezVTi7s7I494FZ1jyEmAsTQ+ nLCu/fJfRm+gh2e8ohXBoqFR2bjxLquQ37y3AYREh383nij+HTkATYsMR1M3o85NCU 6Y0QzhEt2XEMA== Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-ch2-08v.sys.comcast.net with SMTP id D1SVcIlzoLEc2D1SacIJ5e; Sat, 03 Dec 2016 03:58:04 +0000 Received: from odin.ULTHAR.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id uB33vssj027604 for ; Fri, 2 Dec 2016 22:57:54 -0500 Received: (from draco@localhost) by odin.ULTHAR.us (8.15.2/8.15.2/Submit) id uB33vshk027603 for tls@ietf.org; Fri, 2 Dec 2016 22:57:54 -0500 Date: Fri, 2 Dec 2016 22:57:54 -0500 From: Scott Schmit To: tls@ietf.org Message-ID: <20161203035754.GA27160@odin.ulthar.us> References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> <1480713686960.84870@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-CMAE-Envelope: MS4wfP3dVyxAoSUzgaOW3FNHEe4VIhc4Hb1wYQdi1Ru4r8a/dH1WnwjwnThSFuV0RHqZnNxzZVINOW34qoJ6+sqYVlGEMr8xIBdtdCZ45E02oOMJ4NiBitP8 eu/b8zwMO7ewsiPnAnHgSQoAn3Fh/AH2YNU= Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 03:58:09 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2016 at 02:16:16PM -0800, Tony Arcieri wrote: > On Fri, Dec 2, 2016 at 1:21 PM, Peter Gutmann > wrote: >=20 > > The change was proposed long ago, and deferred by the chairs until now. > > This > > is just another variant of the inertia argument. >=20 >=20 > You keep dismissing this argument out of hand, but I think it has merit. >=20 > I think we can all admit the decision to rename SSL -> TLS is a mistake (= to > the point people are proposing to retroactively re-rename TLS back to SSL= ). >=20 > There is now a huge body of work which calls the protocol "TLS 1.3" which > will be cited for years to come. You wrote this whole body of work off as > the concern of "TLS WG and a small number of people who interact with it" > as if a move to a different version number comes at zero cost almost as if > this work doesn't matter, but I have a different view: this is one more b= it > of errata in exactly the same vein as the SSL -> TLS move which anyone > consulting this body of work will have to contend with. >=20 > You will no doubt disagree, so I'm simply saying it for posterity: keeping > the version TLS 1.3 is the least confusing option, IMO. SSL 3.0 was defined in November 1996 (20 years ago). RFC 7568 (sslv3diediedie) was published in June 2015. That's about 18.5 years. TLS 1.0 is still in use, it was standardized in January 1999. It's not dead yet, but there has been talk of it. That's almost 18 years ago. So these protocols tend to last multiple decades (granted, this is a small sample size, but it's what we've got). This draft has been in development since April 2014, 2.6 years ago. Over that time, the wire protocol has changed multiple times and incompatibly. So not even all of that 2.6 years of details is still applicable to the protocol we're going to publish as an RFC. So why would mixing up searched for the final protocol with the draft versions be a good thing? =20 Development versions get new names when they get delivered all the time. Frankly, at $DAYJOB, development versions are always different than the final delivered version, by definition. Doing otherwise is poor version control. The volume of work that will be published in the hopefully 18 or more years that this draft is in deployment will dwarf the current body of work. If it doesn't, then we will have completely failed. Finally, at the top of every internet draft, the IETF states: > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." So, no, we have *not* been calling the next version of TLS "TLS 1.3" for 2.6 years. We have been calling it "a work in progress, subject to change at any time." Anyone doing otherwise is arguably as confused as those who don't even know what TLS is. And there are a lot more of the latter than the former. But no, I would not support calling the next TLS version "SSL 4/2017" -- the harm of invalidating the "SSL is broken, TLS is (more) secure" advice is too great. I'd support calling it RSSL (really secure ...) before I'd support that. --=20 Scott Schmit --vkogqOf2sHV7VnPd Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIINuQYJKoZIhvcNAQcCoIINqjCCDaYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggrhMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkqhkiG9w0BAQsFADB9 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xp ZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tf rh4bdcC1Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR +8eklf/EqeZWRLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I706 2uHsskM8b7gPxmcCoO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo1 2SLBO5tbk8h2imbKTC8iMs+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aM svi2raFhC643SOGvErWWPPnSEfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEG MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIG A1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggr BgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggr BgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQW BBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu 8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGLhK0PAQJbnOEjJyMEvTTw cAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm7NKezWVnCHuwb3pt gFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAIhV4L8aaya1u4 s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1stp+C7omqM 5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8wBUa BxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe 3X+rn0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvS odfiar0wiM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqm RHYj1TjMSw0lAl7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK 7zmjozCCBPcwggPfoAMCAQICEGPKwxkQcAfNHxuyTp+gD8wwDQYJKoZIhvcNAQELBQAwdTEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENs aWVudCBDQTAeFw0xNjA1MjEwMDE3MDlaFw0xOTA4MjEwMDE3MDlaMEAxGzAZBgNVBAMMEmku Z3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9rQGNvbWNhc3QubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoYYlhqtcVPaI5BU1UTWTzpRI/w2jkAq5 KGx4m8a0hYOeT/rO1IiFU8QqEg+17ygK2i5eFAk6Vbe54hXC8hfEP8a3JjCcNhPURA0HsTiH 31DAgZv50G8BYQMubml9FMHV+inthbwyWfrDIADM6AuOaqhohZnHb2vL2h4VgJHh9dnh0MQr DjJXcTaE4k6+VRrEaDW00V4saSYzjlLedrw9F9m2hntYE9dP9Eqros5r5XYv2WRlJMsKSfBy k2hrMIeCX6fkXvs5lw8FjdW/6GZlG+VyckAHwtyig92kLWj5GGb+PsSkFR9lHZ6d4SqRtGnr X5i5c7+yO1EeFdWTulQSCwIDAQABo4IBtjCCAbIwDgYDVR0PAQH/BAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBSeE/ViLQNUr8n+ O2ZP3xm3TmFVPjAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggrBgEFBQcB AQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5BggrBgEFBQcw AoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0MDgGA1Ud HwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQxLmNybDAd BgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMEcGA1UdIARAMD4wPAYLKwYBBAGBtTcBAgUwLTArBggrBgEFBQcCARYf aHR0cHM6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEABj7z gikcowksyBx01urOlbVzBQYEuDTVaTmARQeIsQEkbvorJQ3Pna+38UL2tMoNoIYpGGo+9OwS 13knWprlYPHDD/4XYoPCsnPRHTfQItYeUTcWvG48YykD8XE9OLEhTY2P5yv0blumxyDPuRnD kyeWsoFoDVUo4miLAaY4nuos9oYRd0Kqznt88UmbwDQc4Id3uGf83nJCPmyZfd07enMVCyL/ uC8ThSHxBuK1lag1hQTFlBI8LsWF/+ZMQtUxTkmNxy3gIAYL/vOnsJTx+HV6Wa7V0ZxYbjzq jR1oIkJRye/G8LUykc7/uF8KYS1CRlts+9BeP98xXOGOrc6EezGCApwwggKYAgEBMIGJMHUx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBD bGllbnQgQ0ECEGPKwxkQcAfNHxuyTp+gD8wwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMjAzMDM1NzU0WjAvBgkqhkiG 9w0BCQQxIgQgn3JzlrWTNODIgJr2iyX6R+r2bqye/RUpdLs3fhujXU8weQYJKoZIhvcNAQkP MWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAQErGSzu8scNafi7TU2BPoJsEIQ/eTNGLbTO9ejv/IOxo CqCM+7p6lViZ2vJuzH62xpivED8bPYcFbuOqVCGZ5Exwpm1tU17a7456Qun9WZUm3Zref/by zXKw8n54XZzGToeCtmW3lOwwsWoLIYb3Hy2MVwgrVa3nyiu10goJjOuuVhlg5Gwugoq/InDN FmypKf+mr3yF/jaaE/M+fbfGJqm2OKLXUnKHgdG6CU4jeGYqtVzwP7V9+q6FADSJrLACoxD1 yRxbNR6GypKrFwNofqv0o6rIJebYIb4PUK98I7IuUzKPihqHepB5X/izhMEzTi9XldRwF+cd hFYlIVnp6g== --vkogqOf2sHV7VnPd-- From nobody Fri Dec 2 20:02:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B8D1295A5 for ; Fri, 2 Dec 2016 20:02:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 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, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kF6TysOsAAAj for ; Fri, 2 Dec 2016 20:02:53 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB8281295A1 for ; Fri, 2 Dec 2016 20:02:53 -0800 (PST) Received: from resomta-ch2-08v.sys.comcast.net ([69.252.207.104]) by resqmta-ch2-05v.sys.comcast.net with SMTP id D1XDc2YWrGIG7D1XJchdtO; Sat, 03 Dec 2016 04:02:53 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1480737773; bh=iRwjHSBHgw0STX1LXCUljlslweT92HXb6hko22NrVas=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=Yjp4vAdL9sUhhbItivlLexr5/NmUSfUT/iToVs4JZGsph2Wl728Ec9i6fBVgqSYAp 4UcvCTdTR04kRmHYUK4nfzCfL+xos1Od/K+MWv1d+sjfysrESp2D9+TM69fZ8kuY3n zojMyF8xqbbzEC0XD1qpt9NhxwHudVtRoTNN0kUaDxrD6Lpo4jBmp/FjUGumbr3dWT IAqzGWJyuIgBbUFcv9Ajqq6xuWefFB1anauHAgt+Ud6+iV+oBanwHS1hw5HIKi7reV u8/78oLMUUlCRXI5FY/Av3aAzRIJ5rw1LZkH+OviUxpg521XK7oyPByWx7BCCLeGZR zYszvkd369Asw== Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-ch2-08v.sys.comcast.net with SMTP id D1X8cImvjLEc2D1XCcIJRv; Sat, 03 Dec 2016 04:02:51 +0000 Received: from odin.ULTHAR.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id uB342fvW027656 for ; Fri, 2 Dec 2016 23:02:41 -0500 Received: (from draco@localhost) by odin.ULTHAR.us (8.15.2/8.15.2/Submit) id uB342fwP027654 for tls@ietf.org; Fri, 2 Dec 2016 23:02:41 -0500 Date: Fri, 2 Dec 2016 23:02:41 -0500 From: Scott Schmit To: tls@ietf.org Message-ID: <20161203040241.GB27160@odin.ulthar.us> References: <1480566504487.58214@cs.auckland.ac.nz> <1480648354917.41781@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary="lEGEL1/lMxI0MVQ2" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-CMAE-Envelope: MS4wfGqdZLYh8kE1xhIw06EHXrw8vvBYt76Q68zT3KXNXXyipT2GFccTnabvrsGvjOHDLJQb5190B3udjwEAz8vDHOrD8g60m90YDedNknwXW6IqCyLMTZ1p GCU99rX8+NEoAP/O0l8ssNrVtMxG5ipgJrI= Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 04:02:55 -0000 --lEGEL1/lMxI0MVQ2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 02, 2016 at 03:35:00AM +0000, David Benjamin wrote: > I think TLS 4 makes everything worse, not better. >=20 > In hindsight, renaming SSL 3.1 was a terrible mistake. But TLS 1.2 is goi= ng > to exist for a long time. If we call the next one 4, we have to explain a > gap in the versioning (1.0, 1.1, 1.2, 4?) and placing 2.0 and 3.0 after 1= =2E2 > becomes even more inviting. >=20 > Short of a time machine so we can call this SSL 3.4, the best fix is to l= et > SSL 3.0 fall away. This is already semi-plausible (it's out of all > browsers) and is only going to become more realistic over time. Certainly > it will be faster than TLS 1.2 going away and undoing TLS 4's version gap > problem. (TLS 1.3 even places SSL 3.0 as a MUST NOT, for what little teeth > that has.) >=20 > Once SSL 3.0 falls away, we'll be left with 1.0, 1.1, 1.2, and 1.3, which > is a plausible numbering progression. There'll still be the mess with SSL > being the informal name for the protocol family, but that isn't a numberi= ng > problem. Then "TLS 2017" should be even better. It's neither < 3 nor similar enough to SSL versions as to be confused with them. And the shift in versioning strategy is so typical it would probably not even draw serious notice. --=20 Scott Schmit --lEGEL1/lMxI0MVQ2 Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIINuQYJKoZIhvcNAQcCoIINqjCCDaYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggrhMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkqhkiG9w0BAQsFADB9 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xp ZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tf rh4bdcC1Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR +8eklf/EqeZWRLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I706 2uHsskM8b7gPxmcCoO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo1 2SLBO5tbk8h2imbKTC8iMs+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aM svi2raFhC643SOGvErWWPPnSEfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEG MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIG A1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggr BgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggr BgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQW BBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu 8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGLhK0PAQJbnOEjJyMEvTTw cAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm7NKezWVnCHuwb3pt gFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAIhV4L8aaya1u4 s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1stp+C7omqM 5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8wBUa BxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe 3X+rn0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvS odfiar0wiM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqm RHYj1TjMSw0lAl7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK 7zmjozCCBPcwggPfoAMCAQICEGPKwxkQcAfNHxuyTp+gD8wwDQYJKoZIhvcNAQELBQAwdTEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENs aWVudCBDQTAeFw0xNjA1MjEwMDE3MDlaFw0xOTA4MjEwMDE3MDlaMEAxGzAZBgNVBAMMEmku Z3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9rQGNvbWNhc3QubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoYYlhqtcVPaI5BU1UTWTzpRI/w2jkAq5 KGx4m8a0hYOeT/rO1IiFU8QqEg+17ygK2i5eFAk6Vbe54hXC8hfEP8a3JjCcNhPURA0HsTiH 31DAgZv50G8BYQMubml9FMHV+inthbwyWfrDIADM6AuOaqhohZnHb2vL2h4VgJHh9dnh0MQr DjJXcTaE4k6+VRrEaDW00V4saSYzjlLedrw9F9m2hntYE9dP9Eqros5r5XYv2WRlJMsKSfBy k2hrMIeCX6fkXvs5lw8FjdW/6GZlG+VyckAHwtyig92kLWj5GGb+PsSkFR9lHZ6d4SqRtGnr X5i5c7+yO1EeFdWTulQSCwIDAQABo4IBtjCCAbIwDgYDVR0PAQH/BAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBSeE/ViLQNUr8n+ O2ZP3xm3TmFVPjAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggrBgEFBQcB AQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5BggrBgEFBQcw AoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0MDgGA1Ud HwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQxLmNybDAd BgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMEcGA1UdIARAMD4wPAYLKwYBBAGBtTcBAgUwLTArBggrBgEFBQcCARYf aHR0cHM6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEABj7z gikcowksyBx01urOlbVzBQYEuDTVaTmARQeIsQEkbvorJQ3Pna+38UL2tMoNoIYpGGo+9OwS 13knWprlYPHDD/4XYoPCsnPRHTfQItYeUTcWvG48YykD8XE9OLEhTY2P5yv0blumxyDPuRnD kyeWsoFoDVUo4miLAaY4nuos9oYRd0Kqznt88UmbwDQc4Id3uGf83nJCPmyZfd07enMVCyL/ uC8ThSHxBuK1lag1hQTFlBI8LsWF/+ZMQtUxTkmNxy3gIAYL/vOnsJTx+HV6Wa7V0ZxYbjzq jR1oIkJRye/G8LUykc7/uF8KYS1CRlts+9BeP98xXOGOrc6EezGCApwwggKYAgEBMIGJMHUx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBD bGllbnQgQ0ECEGPKwxkQcAfNHxuyTp+gD8wwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMjAzMDQwMjQxWjAvBgkqhkiG 9w0BCQQxIgQghNciII3ipOQ6ZvQYwRV9oLnKZrN8sQnYTwblwqO6gvYweQYJKoZIhvcNAQkP MWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAQg32q/cqrhcpC9aiuut7oa3IKuGXVM2vlYOZ0WJAFjRf vJptmwtuTq9rS6720TOt84MAEY+OHezfsazae+l0tJFJUVYZiQySHv5U79eJE1w58zLtbUHj 6sWT2xvUU8CY8hkU8ch89ziT5Zyt18BQR8mU4APvpQtOgh0+qx38g8KuElI0+jCIHZ9nzFP3 AFfjAX3AQYP3wCN006AwZm2yrz9mqwMiYaY7y0GMJTNInsX7dq0djBZl6N0tt6FQBFAc7ALd Fo347FBmhsqvu6d9WEFOQZI+8zU4XGz/r2Y2oKNxQEs7MwUFnXYyrhDwjJx0BUVUmAsGLb9a 5xmvXunatA== --lEGEL1/lMxI0MVQ2-- From nobody Fri Dec 2 20:22:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A14291295A3 for ; Fri, 2 Dec 2016 20:22:08 -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 Wv8bqIoHgBfw for ; Fri, 2 Dec 2016 20:22:07 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 D6269129404 for ; Fri, 2 Dec 2016 20:22:06 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id b35so300644794uaa.3 for ; Fri, 02 Dec 2016 20:22:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=64LhP65LFqIa8vd+symfv+9DkDf0PXi31tKh4aFQqXk=; b=qMzZVvJ7jnbPPlNPGHPRvaD/aaAuPrKOycK6QRGsAyxA8k6H195M/QpXdjPPrqy5ZB S9qK/elTsGokzNaHVTVZjskil9VuANAZjftDC7TttoctF6sgppmcKaKzLn9mNlWvxIZb Jjq00GH9YGndnRHB9KiuePLY9GXwuK4rh13ZTA5uYNxwKmuzwW6ca6CgNXhupa0yO/pP Y6c+6Luc/rR63s56ZezauSh3CGB+Irkonxv+SP6gBVQlwWLiXGAXzWvHo8iLF0R5US7l IdsqJZORY3GCIK9XOH3odWopSVADEhFbS1Wk7ysAMIoP8IhyxswOncURSjUNbp/4XEcx siHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=64LhP65LFqIa8vd+symfv+9DkDf0PXi31tKh4aFQqXk=; b=BB+ZEsrxHh13H+HwUJoU8W5cuRnpnCQnDGhBJX/+MBmOqtzEeu/MP/8CpsjntE5Afu Pr3vIiVDFrO3Kho9o7ClYtIwoExBI56wCGQdTPNWETVl4OZUPPQ+WAK3Soe2Slc+rYVW zx7JeXrXf2p6/rzQZbOKnnGZp39OmA+nM9ZBRYrkadEZ5DkO3IYb0zGz0EWWTzJRwwjZ VFPQKGDLPpbXfanGjnyu5M0eNtYGtSPX1fLoVXU1h3aF2FGRNT2CkzH91ycfmtwTuV6d dfEwgcmkajvxClDiwRk/sIuBCbyVDNsnhqZJnjFEmLaA29zpQKAja9D6IQnpuXfXy8tE aRng== X-Gm-Message-State: AKaTC01GwW7IhbE8jMCOOuf8rM+TeC+tfSzHsQfDxrSNN6tTERoImZLPVVK3+HnIs1Wjdi1BYQ+zbxuryTBTZg== X-Received: by 10.176.64.234 with SMTP id i97mr30216792uad.7.1480738925938; Fri, 02 Dec 2016 20:22:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.145.144 with HTTP; Fri, 2 Dec 2016 20:21:45 -0800 (PST) In-Reply-To: <20161203035754.GA27160@odin.ulthar.us> References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> <1480713686960.84870@cs.auckland.ac.nz> <20161203035754.GA27160@odin.ulthar.us> From: Tony Arcieri Date: Fri, 2 Dec 2016 20:21:45 -0800 Message-ID: To: Scott Schmit Content-Type: multipart/alternative; boundary=94eb2c123566af91010542b9651c Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 04:22:08 -0000 --94eb2c123566af91010542b9651c Content-Type: text/plain; charset=UTF-8 On Fri, Dec 2, 2016 at 7:57 PM, Scott Schmit wrote: > This draft has been in development since April 2014, 2.6 years ago. > Over that time, the wire protocol has changed multiple times and > incompatibly. So not even all of that 2.6 years of details is still > applicable to the protocol we're going to publish as an RFC. So why > would mixing up searched for the final protocol with the draft versions > be a good thing? > The wire format is one thing, but there is work that has been done at a much higher level referencing "TLS 1.3", e.g. TRON work: http://prosecco.gforge.inria.fr/personal/karthik/pubs/proscript-tls-tron-2016.pdf > The volume of work that will be published in the hopefully 18 or more > years that this draft is in deployment will dwarf the current body of > work. If it doesn't, then we will have completely failed. While more security analysis against whatever-the-new-TLS-is-called will certainly happen, I would imagine it would be split against whatever-the-next-TLS-version-is-called. And the thing is, a lot of the extant research about "TLS 1.3" is fantastic, so much so that I think it will be routinely cited. Certainly there will be new research, but much of the groundwork has already been laid. >From what I can tell, the main argument for changing the version is to *reduce confusion*. I am incredibly unconvinced rebranding TLS 1.3 to TLS 4/2017/9000 will actually accomplish the intended goal. A recent example of what sort of confusion I could see arise: ECMAScript. They moved from a numbered branding (ES6/ES7) to a year-based branding (ES2016/ES2017). People continue to use both, so now you have to maintain a mental mapping of which-version-to-which-year. The optimal solution to me as far as reducing these sort of mental gymnastics goes is to keep the version as "TLS 1.3" and drop the 1.x in the next release. This gets the "TLS 4" advocates what they want, just not right away, without renaming the current release at the last minute. -- Tony Arcieri --94eb2c123566af91010542b9651c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Dec 2, 2016 at 7:57 PM, Scott Schmit <i.grok@comcast.net> wrote:
This draft h= as been in development since April 2014, 2.6 years ago.
Over that time, the wire protocol has changed multiple times and
incompatibly.=C2=A0 So not even all of that 2.6 years of details is still applicable to the protocol we're going to publish as an RFC.=C2=A0 So w= hy
would mixing up searched for the final protocol with the draft versions
be a good thing?

= The wire format is one thing, but there is work that has been done at a muc= h higher level referencing "TLS 1.3", e.g. TRON work:

=C2=A0
The volume o= f work that will be published in the hopefully 18 or more
years that this draft is in deployment will dwarf the current body of
work.=C2=A0 If it doesn't, then we will have completely failed.

While more security analysis against whatever-the-= new-TLS-is-called will certainly happen, I would imagine it would be split = against whatever-the-next-TLS-version-is-called. And the thing is, a lot of= the extant research about "TLS 1.3" is fantastic, so much so tha= t I think it will be routinely cited. Certainly there will be new research,= but much of the groundwork has already been laid.

From what I can tell, the main argument for changing the version is to *re= duce confusion*. I am incredibly unconvinced rebranding TLS 1.3 to TLS 4/20= 17/9000 will actually accomplish the intended goal.

A recent example of what sort of confusion I could see arise: ECMAScript.= They moved from a numbered branding (ES6/ES7) to a year-based branding (ES= 2016/ES2017). People continue to use both, so now you have to maintain a me= ntal mapping of which-version-to-which-year.

The o= ptimal solution to me as far as reducing these sort of mental gymnastics go= es is to keep the version as "TLS 1.3" and drop the 1.x in the ne= xt release. This gets the "TLS 4" advocates what they want, just = not right away, without renaming the current release at the last minute.

--
Tony Arcieri<= br>
--94eb2c123566af91010542b9651c-- From nobody Sat Dec 3 05:58:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42A391297F1 for ; Sat, 3 Dec 2016 05:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWJzlPxL-alo for ; Sat, 3 Dec 2016 05:58:49 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001: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 25FFE1297EA for ; Sat, 3 Dec 2016 05:58:49 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id m5so390529674ioe.3 for ; Sat, 03 Dec 2016 05:58:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w/F8QQacsctndahlnRxSw+KD4vbJDRKHOshqa/xLW7c=; b=wqYwV7geUUhPYgZSQCbuWXEah24AMrH4oVMpzN0Xp9WlV267/3xTw88lquXxbCp6aG BXzmXPmWZZDB8s9TcJ9omuDgbU7Lo0ET99Tw1Zp4JGU8FSbraOEWleN32AErp+TyO8bo XekSD0NQZmsBGh2WofUb4XDBtdUSV88LoDnPtYtkvLGSLPuNIubDuD/EtEF+3rD7+JoT kg5+IFE9cAeQaFJxTQtau7GmntQ+UFWFBvVH8nCDFr+FOBR0q7ccj9VJSj6tVHw2tiAx pH8/TZ6WEyFqnkAnqnOSNAbGhZ6qZCRyu6EeyEqGvFapFePFFT9S8sGNUTKLQmW4xcU8 R/1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w/F8QQacsctndahlnRxSw+KD4vbJDRKHOshqa/xLW7c=; b=ZTMXZ+pV8HoLvN9sFYV0q5xK/OBnL+bh5fNMf/fpxNHzkhHMAKh62YyQqzXYMYIihB 65kPyO+rhNHb8eURw9MCZ/dqFSnq7KgdkJJN8fJDC2gwYTnOwK8jN5HV/o04W9VPawex BWG14dfHfrJ7WB0047C5u2oFwz6di+/TWro7q+hcqqKgw/0vJfN0DoEaRBcD+qcRMTs+ ePCu9E/8Lg6CF+USAKaLswQU/+s+BC3QtTzmqXWKO2qNkG2bGM3TpVFpWiIkwmpufO/f doUhIfIAx86j8nNOIt6pUhhP3euUg0SjxOg5o4XULcyDZpwjKw5QQ6mbhO6ngayKRhLZ ux8g== X-Gm-Message-State: AKaTC01ZoBRahBPIpcsudljT+DvnhdbYzvXV8k3wjxdNvMVennO9aBmw3H2O39QphMGOwFAqr1gwpO10b/KNBQ== X-Received: by 10.107.15.153 with SMTP id 25mr42643678iop.168.1480773528405; Sat, 03 Dec 2016 05:58:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.89.8 with HTTP; Sat, 3 Dec 2016 05:58:27 -0800 (PST) In-Reply-To: References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> <1480713686960.84870@cs.auckland.ac.nz> <20161203035754.GA27160@odin.ulthar.us> From: Karthik Bhargavan Date: Sat, 3 Dec 2016 14:58:27 +0100 Message-ID: To: Tony Arcieri Content-Type: multipart/alternative; boundary=001a113ee4fc274c040542c17413 Archived-At: Cc: Scott Schmit , "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 13:58:51 -0000 --001a113ee4fc274c040542c17413 Content-Type: text/plain; charset=UTF-8 > > The wire format is one thing, but there is work that has been done at a > much higher level referencing "TLS 1.3", e.g. TRON work: > > http://prosecco.gforge.inria.fr/personal/karthik/pubs/ > proscript-tls-tron-2016.pdf > Thanks for the reference but this draft paper does not count as a publication. Yes, there are other published papers that have appeared during the last year that use the name TLS 1.3, but I think academics will keep out of this (re)naming debate because it does not matter so much for us. We are already citing draft versions in our papers, because a proof for draft 10 does not carry over to draft 18. When the RFC comes out, we'll start consistently citing the published protocol, whatever it is called. Again, I'll keep out of the protocol name discussion, but I don't think the name will add too much confusion for academic works, or put another way, it will not reduce the confusion which already exists between various draft versions and the final RFC. > > >> The volume of work that will be published in the hopefully 18 or more >> years that this draft is in deployment will dwarf the current body of >> work. If it doesn't, then we will have completely failed. > > > While more security analysis against whatever-the-new-TLS-is-called will > certainly happen, I would imagine it would be split against > whatever-the-next-TLS-version-is-called. And the thing is, a lot of the > extant research about "TLS 1.3" is fantastic, so much so that I think it > will be routinely cited. Certainly there will be new research, but much of > the groundwork has already been laid. > > From what I can tell, the main argument for changing the version is to > *reduce confusion*. I am incredibly unconvinced rebranding TLS 1.3 to TLS > 4/2017/9000 will actually accomplish the intended goal. > > A recent example of what sort of confusion I could see arise: ECMAScript. > They moved from a numbered branding (ES6/ES7) to a year-based branding > (ES2016/ES2017). People continue to use both, so now you have to maintain a > mental mapping of which-version-to-which-year. > > The optimal solution to me as far as reducing these sort of mental > gymnastics goes is to keep the version as "TLS 1.3" and drop the 1.x in the > next release. This gets the "TLS 4" advocates what they want, just not > right away, without renaming the current release at the last minute. > > -- > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113ee4fc274c040542c17413 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The wire format is one th= ing, but there is work that has been done at a much higher level referencin= g "TLS 1.3", e.g. TRON work:

=
<= /div>


Thanks for= the reference but this draft paper does not count as a publication. Yes, t= here are other published papers that have appeared during the last year tha= t use the name TLS 1.3, but I think academics will keep out of this (re)nam= ing debate because it does not matter so much for us. We are already citing= draft versions in our papers, because a proof for draft 10 does not carry = over to draft 18. When the RFC comes out, we'll start consistently citi= ng the published protocol, whatever it is called.

= Again, I'll keep out of the protocol name discussion, but I don't t= hink the name will add too much confusion for academic works, or put anothe= r way, it will not reduce the confusion which already exists between variou= s draft versions and the final RFC.
=C2=A0
=C2=A0
The volume of work that will be published in the hopeful= ly 18 or more
years that this draft is in deployment will dwarf the current body of
work.=C2=A0 If it doesn't, then we will have completely failed.

While more security analysis against whatev= er-the-new-TLS-is-called will certainly happen, I would imagine it would be= split against whatever-the-next-TLS-version-is-called. And the thing = is, a lot of the extant research about "TLS 1.3" is fantastic, so= much so that I think it will be routinely cited. Certainly there will be n= ew research, but much of the groundwork has already been laid.
From what I can tell, the main argument for changing the versi= on is to *reduce confusion*. I am incredibly unconvinced rebranding TLS 1.3= to TLS 4/2017/9000 will actually accomplish the intended goal.
<= br>
A recent example of what sort of confusion I could see arise:= ECMAScript. They moved from a numbered branding (ES6/ES7) to a year-based = branding (ES2016/ES2017). People continue to use both, so now you have to m= aintain a mental mapping of which-version-to-which-year.

The optimal solution to me as far as reducing these sort of mental g= ymnastics goes is to keep the version as "TLS 1.3" and drop the 1= .x in the next release. This gets the "TLS 4" advocates what they= want, just not right away, without renaming the current release at the las= t minute.

--
Tony Arcieri

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


--001a113ee4fc274c040542c17413-- From nobody Sat Dec 3 08:55:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507D2129978 for ; Sat, 3 Dec 2016 08:55:27 -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 XNSaXnj1LESv for ; Sat, 3 Dec 2016 08:55:25 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E02D129977 for ; Sat, 3 Dec 2016 08:55:25 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id p16so278852733qta.0 for ; Sat, 03 Dec 2016 08:55:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ovQUReSW+J4bTO7SNGAJnH2mlNjZKCgQTSnOaPtWe8M=; b=ZgY3RfpLMZ1oSwMXhyFx4SD4QqmuToeEqSJJWE+Lohfrk3uoelRithdra/CFAjmhbz yIEJADWzv6QxN9SlSZvp1vuwmMURaBWN2MFup375WK+NgjrYjFjErNEV41ycEzbxalvT HCywcdceRo/g/2oHo9qkLgHJlyuHh2G3T5/+A= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=ovQUReSW+J4bTO7SNGAJnH2mlNjZKCgQTSnOaPtWe8M=; b=euYV+2RbNIjw+WrHzklgNBO3ME4vWGFVDLWj4Zo4/kpMzHUHLVi0A/zBuVFxmKR5rQ v2OFs79cA3mOhASBrwfF9xdFRV6Avknfw/Uq7aOHgtmR3cfnGANQdYSYOyp7UpEIogLY rf2wwKsF+q+4vSEejR7LA1IkWZJV6TceqbSyflGo6YArZsOG3H2G0i3awGory0s9JhcV sEvxVplKRH+LZsCBwhA6Ue9T9o8rzKgHmSh0moCFLml+oKmYbMeOWZDvgSk7cp8BwtAw +IfujvAeQTDqEXYKAQV9WG2UfmkvqI076pN2Ew28WPDSBJs9HxPEMsK9GkoVkmtEizg9 Nw0g== X-Gm-Message-State: AKaTC00xbkJUsFponab0a67E1ULFiOFyAHoD8/kHRQuOumCmJ/rpYEez2UWa2ox4Lz06lw== X-Received: by 10.200.35.214 with SMTP id r22mr44186243qtr.30.1480784124464; Sat, 03 Dec 2016 08:55:24 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id m62sm5234729qkd.44.2016.12.03.08.55.23 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 03 Dec 2016 08:55:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Sat, 3 Dec 2016 11:55:21 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] closing thread -> Re: Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Dec 2016 16:55:27 -0000 At this point I don=E2=80=99t think it=E2=80=99s December 2nd anywhere = in the world, so it=E2=80=99s time to close this thread. Joe and I will = take a couple of days to review the 130+ messages. spt > On Nov 17, 2016, at 21:12, Sean Turner wrote: >=20 > At IETF 97, the chairs lead a discussion to resolve whether the WG = should rebrand TLS1.3 to something else. Slides can be found @ = https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr= 612-01.pdf. >=20 > The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this = decision on the list so please let the list know your top choice = between: >=20 > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 >=20 > by 2 December 2016. >=20 > Thanks, > J&S From nobody Sat Dec 3 16:29:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C693129454 for ; Sat, 3 Dec 2016 16:29:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] 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 wh1eNi0WuOP3 for ; Sat, 3 Dec 2016 16:29:41 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC5E5129450 for ; Sat, 3 Dec 2016 16:29:39 -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=1480811381; x=1512347381; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=8hZraedajYJ/zvKEJCZMstKKfow8EnLY5QhydeJzZ6k=; b=voVfP8HU0trPTwP4x1pR8Oiml5VVtQEyyilstsMeuO/BAVccLgXOleUP MPJ+00gzy0b+eMBIjeNNwPLbhmpMoxjg3GDFQEbUmbqGC/VEWC7aP+cLr IsaAq1+GxMWsV5xvBK4E1PZhtpuBbGaVX+GLq1jyMl7Cr1zavYNGO29vB vCO4w3TbQuhntxo2/ryNh0iIlMMbVCg0QsF3WF0lr7TRzRQLzJr2s7a+z i1kP0rVAmlYOaQ6eZ6I3k1jWe5ki0qJ46kNDkVjjXRQ9sbFv0m0CNXHJX pH4/6gthLjvM05Bw0TyNtkhAkmc2fuo9VHRDAa3jhNSaIl2AfOewbnWbE w==; X-IronPort-AV: E=Sophos;i="5.33,295,1477911600"; d="scan'208";a="118696361" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from uxcn13-tdc-a.uoa.auckland.ac.nz ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Dec 2016 13:29:38 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 4 Dec 2016 13:29:31 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sun, 4 Dec 2016 13:29:31 +1300 From: Peter Gutmann To: Tony Arcieri Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfD667DaatoU6RNleDGo1T66DwCVTAgAGDyICAAQa6CP//KrAAgAFpLoCAAOlzA///rBIAgAArigCAAAVnAIAAAaoAgAAIWoCAAANTgIAAEwgAgAEy93T//zV1AABSJ0dy Date: Sun, 4 Dec 2016 00:29:31 +0000 Message-ID: <1480811360237.56950@cs.auckland.ac.nz> References: <1708522.6z7rVghrrH@pintsize.usersys.redhat.com> <310c930ad6264e49b6c6862d99b63ef0@usma1ex-dag1mb1.msg.corp.akamai.com> <2394990.KnQcpSKGuD@pintsize.usersys.redhat.com> <1480713686960.84870@cs.auckland.ac.nz>, 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: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 00:29:43 -0000 Tony Arcieri writes:=0A= =0A= >There is now a huge body of work which calls the protocol "TLS 1.3"=0A= =0A= When you say "huge body of work" you're referring to an IETF draft with "no= =0A= formal status, subject to change or removal at any time; therefore they sho= uld=0A= not be cited or quoted in any formal document" (in other words a no-op), an= d=0A= some research reports/papers and blog posts, pretty much invisible to anyon= e=0A= outside the WG and a few people who follow it in the crypto community.=A0 T= o=0A= quote Douglas Adams, "this must be some new use of the word huge with which= I=0A= wasn't previously familiar".=0A= =0A= So I'll maintain my point that the only real argument that's been put forwa= rd=0A= for 1.3 is inertia, "we've always done it this way and I don't want to=0A= change".=A0 And that's why I support 4, or 2017, or whatever: The WG can pr= etend=0A= it's meant to be called TLS, everyone else can keep calling it SSL like the= y=0A= always have, but no matter what, the numbers will work out.=A0 No matter ho= w you=0A= choose to label the alphabetical part, either 4 or 2017 is obviously the=0A= newer, better version number.=0A= =0A= Peter.=0A= =0A= = From nobody Sat Dec 3 22:21:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 739D0128B38 for ; Sat, 3 Dec 2016 22:21:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 yr52_jaQ6IEO for ; Sat, 3 Dec 2016 22:21:45 -0800 (PST) Received: from KECGATE08.INFOSYS.COM (kecgate08.infosysconsulting.com [122.98.10.33]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543CE127A90 for ; Sat, 3 Dec 2016 22:21:45 -0800 (PST) Received: from KECGATE08.INFOSYS.COM (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 4D3083433A; Sun, 4 Dec 2016 11:48:19 +0530 (IST) Received: from BLRKECHUB12.ad.infosys.com (unknown [10.66.236.44]) by KECGATE08.INFOSYS.COM (Postfix) with ESMTP id 0588C342DE; Sun, 4 Dec 2016 11:48:19 +0530 (IST) Received: from BLRKECMBX12.ad.infosys.com ([fe80::f8b7:7e01:84d7:4675]) by BLRKECHUB12.ad.infosys.com ([::1]) with mapi id 14.03.0210.002; Sun, 4 Dec 2016 11:45:31 +0530 From: Mohan Sekar To: Tony Arcieri , Sean Turner Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfMq9Jy8Uzok6kpMB10rSiGaD1TYgAgAIM+eA= Date: Sun, 4 Dec 2016 06:15:29 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.13.91] Content-Type: multipart/alternative; boundary="_000_FBCFF214B47FE544AFE2125E075EC1F8B8A0F5BLRKECMBX12adinfo_" MIME-Version: 1.0 X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1544-8.0.0.1202-22740.005 X-TM-AS-Result: No--24.299-5.0-31-10 X-imss-scan-details: No--24.299-5.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1544-8.0.1202-22740.005 X-TMASE-Result: 10--24.299500-10.000000 X-TMASE-MatchedRID: vEvJ7Rh1lGiIs4Pn4FVe+Res/RxhysDb+kuaU6pTXgKRl9YdphffeoI7 s5f4WtvN8nz3TH+6RI6kDGGiBV4DLAcs8tT8q3JQvHKClHGjjr3WSrKtwxqWpfYJJvEjULXnHAQ QhWwz+SlXDkqNOGllDkmlX2scVfeP7a7m7fE5C+HBtFDYGmaWKhrL4FDGAJ+Flvs2jSyutOTsoE FnZAFTLNDbef4/mkgxFCOLNe0Jd9NZiostRfaYC7iMC5wdwKqddwX/SSKrKHgPGMG6AkHPPKBDB 389eXAYAqw+WvX1QFR2QRPOro/h7Vy8LiE9LxheIj0zFI5DoJItUSMDHceMrqTsE8Z/jrr+ig5r FZgkeRd4XRigqDnz6rH7Mq/zhRAL8SfOLQ+4zH+eAiCmPx4NwGmRqNBHmBvepTwPRvSoXL3Fsa+ Yz2ePkyq2rl3dzGQ1pKe7FpJH0/WqqetAF0C7+wO7EoQDyryHEGfq2NY48wCisWFP+Lbm3g== X-TMASE-SNAP-Result: 1.811037.0001-0-1-22:0,12:0 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Dec 2016 06:21:47 -0000 --_000_FBCFF214B47FE544AFE2125E075EC1F8B8A0F5BLRKECMBX12adinfo_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgb24gVG9ueSBjb21tZW50DQoNCi0gS2VlcCB0aGlzIHZlcnNpb24gVExTIDEuMw0KLSBGb3Ig dGhlIG5leHQgdmVyc2lvbiBvZiBUTFMsIGRyb3AgdGhlIDEueCBhbmQgY2FsbCBpdCBUTFMgNA0K DQpNb2hhbiBTZWthcg0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIE9mIFRvbnkgQXJjaWVyaQ0KU2VudDogU2F0dXJkYXksIERlY2VtYmVyIDMsIDIw MTYgOTowNCBBTQ0KVG86IFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT4NCkNjOiA8dGxzQGll dGYub3JnPiA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIENvbmZpcm1pbmcgY29u c2Vuc3VzOiBUTFMxLjMtPlRMUyoNCg0KT24gVGh1LCBOb3YgMTcsIDIwMTYgYXQgNjoxMiBQTSwg U2VhbiBUdXJuZXIgPHNlYW5Ac24zcmQuY29tPG1haWx0bzpzZWFuQHNuM3JkLmNvbT4+IHdyb3Rl Og0KVGhlIGNvbnNlbnN1cyBpbiB0aGUgcm9vbSB3YXMgdG8gbGVhdmUgaXQgYXMgaXMsIGkuZS4s IFRMUzEuMywgYW5kIHRvIG5vdCByZWJyYW5kIGl0IHRvIFRMUyAyLjAsIFRMUyAyLCBvciBUTFMg NC4gIFdlIG5lZWQgdG8gY29uZmlybSB0aGlzIGRlY2lzaW9uIG9uIHRoZSBsaXN0IHNvIHBsZWFz ZSBsZXQgdGhlIGxpc3Qga25vdyB5b3VyIHRvcCBjaG9pY2UgYmV0d2VlbjoNCg0KLSBMZWF2ZSBp dCBUTFMgMS4zDQotIFJlYnJhbmQgVExTIDIuMA0KLSBSZWJyYW5kIFRMUyAyDQotIFJlYnJhbmQg VExTIDQNCg0KYnkgMiBEZWNlbWJlciAyMDE2Lg0KDQpJIGd1ZXNzIHdlJ3JlIGF0IHRoZSBkZWFk bGluZSwgYnV0IEkgaGF2ZSBhIGNvbXByb21pc2UgSSB0aGluayBtYWtlcyBzZW5zZToNCg0KLSBL ZWVwIHRoaXMgdmVyc2lvbiBUTFMgMS4zDQotIEZvciB0aGUgbmV4dCB2ZXJzaW9uIG9mIFRMUywg ZHJvcCB0aGUgMS54IGFuZCBjYWxsIGl0IFRMUyA0DQoNCi0tDQpUb255IEFyY2llcmkNCg== --_000_FBCFF214B47FE544AFE2125E075EC1F8B8A0F5BLRKECMBX12adinfo_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mIzQzOzEgb24gVG9ueSBjb21tZW50PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gS2VlcCB0 aGlzIHZlcnNpb24gVExTIDEuMzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LSBGb3IgdGhlIG5leHQgdmVyc2lvbiBvZiBUTFMsIGRyb3AgdGhlIDEueCBhbmQgY2FsbCBpdCBU TFMgNCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Nb2hhbiBTZWthcjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZy b206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0Bp ZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+VG9ueSBBcmNpZXJpPGJyPg0KPGI+U2VudDo8 L2I+IFNhdHVyZGF5LCBEZWNlbWJlciAzLCAyMDE2IDk6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+IFNl YW4gVHVybmVyICZsdDtzZWFuQHNuM3JkLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ICZsdDt0bHNA aWV0Zi5vcmcmZ3Q7ICZsdDt0bHNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBbVExTXSBDb25maXJtaW5nIGNvbnNlbnN1czogVExTMS4zLSZndDtUTFMqPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUaHUsIE5vdiAxNywg MjAxNiBhdCA2OjEyIFBNLCBTZWFuIFR1cm5lciAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNlYW5Ac24z cmQuY29tIiB0YXJnZXQ9Il9ibGFuayI+c2VhbkBzbjNyZC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgY29uc2Vu c3VzIGluIHRoZSByb29tIHdhcyB0byBsZWF2ZSBpdCBhcyBpcywgaS5lLiwgVExTMS4zLCBhbmQg dG8gbm90IHJlYnJhbmQgaXQgdG8gVExTIDIuMCwgVExTIDIsIG9yIFRMUyA0LiZuYnNwOyBXZSBu ZWVkIHRvIGNvbmZpcm0gdGhpcyBkZWNpc2lvbiBvbiB0aGUgbGlzdCBzbyBwbGVhc2UgbGV0IHRo ZSBsaXN0IGtub3cgeW91ciB0b3AgY2hvaWNlIGJldHdlZW46PGJyPg0KPGJyPg0KLSBMZWF2ZSBp dCBUTFMgMS4zPGJyPg0KLSBSZWJyYW5kIFRMUyAyLjA8YnI+DQotIFJlYnJhbmQgVExTIDI8YnI+ DQotIFJlYnJhbmQgVExTIDQ8YnI+DQo8YnI+DQpieSAyIERlY2VtYmVyIDIwMTYuPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGd1 ZXNzIHdlJ3JlIGF0IHRoZSBkZWFkbGluZSwgYnV0IEkgaGF2ZSBhIGNvbXByb21pc2UgSSB0aGlu ayBtYWtlcyBzZW5zZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LSBLZWVwIHRoaXMgdmVyc2lvbiBUTFMgMS4zPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEZvciB0aGUgbmV4dCB2ZXJzaW9u IG9mIFRMUywgZHJvcCB0aGUgMS54IGFuZCBjYWxsIGl0IFRMUyA0Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ub255IEFyY2llcmk8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_FBCFF214B47FE544AFE2125E075EC1F8B8A0F5BLRKECMBX12adinfo_-- From nobody Mon Dec 5 15:14:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2639129E90 for ; Mon, 5 Dec 2016 15:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, 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 7w4GcezXodst for ; Mon, 5 Dec 2016 15:13:58 -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 45FEE129E85 for ; Mon, 5 Dec 2016 15:13:58 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id q130so175441388qke.1 for ; Mon, 05 Dec 2016 15:13:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=nIAWo16Hb7z7HzknkVswyEIrp5HWSot6WLMwJdPT4Kg=; b=GAFckqo1ekPTarwepqrwMV1EJ+BabQP73CND42c/WNxjKFxPldcpohBkgMeIKwfOc1 6vwpoLc2bvT8uv6omeGtKAoBGNxp8/USoeI9U1WA8O8pJAtMOrRg+UDBAiyKVIQ4pNWh 0J1HopYWIYnXqZaT+gTamT+VhDC0s/ypnukEwOW1A2xxCIpZ0TcyHlODhh+zbCwEN1HC bBxurVJHjfXHfBuql84jq8xAg+/XjfYySGvC7wFEF51OHH2lZWWX6TZQ5TJnBHUeee5/ wATrL3bEi40oEifB7h9Z/EJYgO0IGhFNBkESGSDGTInlYeffuKr2tqBPiy/jJlKO8k4s PhYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=nIAWo16Hb7z7HzknkVswyEIrp5HWSot6WLMwJdPT4Kg=; b=F+vNqI852VA1q4Z4P0L5QCjLB1LcBpCX6wUpKv8cA2mjc0/pSMVFdc5sHPr2xDf+Oy qFC3iTHBBzY6zO4Dd9zmIX9C6uSyaEY7qn0g3WkvI36ILzLN2KSLIPFvb9U0SBRrJ8M+ OAgT1NT8soB3IKpQDj5kLs7/A/igLaulOJHPETFRBstHLRZwJ41EI5xKuI2u8PHLrPO1 QXKB6MLJnYIACw3XD7fmodM23UgnR4Kl8T9sUE37Nv2QcATndvpm1BSMIq0YMVUVmDhU EqBnlLVwUILxWOy4cq+IuRs78/6ZXd4ifqo5Pzg4/X7RDi39AkTf/VRDa4gkeELQZrTE Ol0Q== X-Gm-Message-State: AKaTC018eytM4FewPT0uI8WYX6yg0SQ4amUPMoZbOI6FkjRTBG7M9xIRIvNG/5iUjZGcDH4/DElRWU59N/C3QATR X-Received: by 10.55.155.215 with SMTP id d206mr22786842qke.81.1480979637244; Mon, 05 Dec 2016 15:13:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.233.239.69 with HTTP; Mon, 5 Dec 2016 15:13:56 -0800 (PST) In-Reply-To: <20161127151304.gaqxot5wqcmcey7n@pinky.local> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> <20161127151304.gaqxot5wqcmcey7n@pinky.local> From: Victor Vasiliev Date: Mon, 5 Dec 2016 18:13:56 -0500 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0776ee32eda00542f171e7 Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 23:14:01 -0000 --94eb2c0776ee32eda00542f171e7 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 27, 2016 at 10:13 AM, Alessandro Ghedini wrote: > On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote: > > I am currently trying to figure out how much of QUIC certificate > > compression can be adapted to work with TLS. I will submit a draft as > soon > > as I have a working prototype. > > FWIW I too have started working on a prototype for gzip compressing > certificates > based on BoringSSL: > https://github.com/ghedo/boringssl/tree/cert_compress > > It's not complete yet and I only implemented compression so far based on > what > Chromium does with QUIC. I also haven't really tested it yet (but at least > it > builds AFAICT :) ). > > This looks promising! I am currently working on figuring out a better pre-shared dictionary (based on CT logs analysis) so I don't have that much code for the actual TLS parts. > I'd like to do some tests as well to measure the benefits of this (e.g. > download certificates from CT logs and see how effective the compression > is). > > I am using CT logs as a reference too. > I also started working on a draft for gzip compression of certificates at: > https://github.com/ghedo/tls-certificate-compression > > Or that's the current scope anyway. Maybe it would also make sense to > include > the full QUIC certificate caching part, but I didn't want to duplicate > RFC7924. > > My intention would be to use gzip-compressed certs on first connect, and > then > use RFC7924 for consecutive handshakes. > > My plan was to start with a zlib-based compression, and then introduce some more efficient algorithm as a second step. I've been looking into the alternatives, but I'd have to actually finish the dictionary refresh before doing any evaluation. RFC 7924 is another good place to start. There are multiple improvements to it that I have in mind, but it would probably be reasonable to begin by actually getting RFC 7924 support into the common implementations. > The text is not complete and I haven't submitted it yet, though it would be > nice if we could work on the same draft together, in order to avoid > duplicating > work (I can give you or anyone interested commit access to the repo). > > Cheers > I would be happy to collaborate on the draft! The TLS 1.2 story should be relatively straightforward, but with TLS 1.3 Certificate message format we'd have to figure out the correct layering. -- Victor. --94eb2c0776ee32eda00542f171e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sun, Nov 27, 2016 at 10:13 AM, Alessandro Ghedini= =C2=A0<alessandro@ghedini.me>=C2=A0wrote:
On Sat, Nov 2= 6, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote:
> I am currently = trying to figure out how much of QUIC certificate
> compression can b= e adapted to work with TLS.=C2=A0 I will submit a draft as soon
> as = I have a working prototype.

FWIW I too have started working o= n a prototype for gzip compressing certificates
based on BoringSSL:
<= a href=3D"https://github.com/ghedo/boringssl/tree/cert_compress" rel=3D"nor= eferrer" target=3D"_blank">https://github.com/ghedo/boringssl/tree/cer= t_compress

It's not complete yet and I only implemented comp= ression so far based on what
Chromium does with QUIC. I also haven't= really tested it yet (but at least it
builds AFAICT :) ).


This looks promising!=C2=A0 I am currently worki= ng on figuring out a better pre-shared dictionary
(based on C= T logs analysis) so I don't have that much code for the actual TLS part= s.
=C2=A0
= I'd like to do some tests as well to measure the benefits of this (e.g.=
download certificates from CT logs and see how effective the compressio= n is).


I am using CT logs as a refe= rence too.
=C2=A0
I also started working on a draft for gzip compression of certifica= tes at:
https://github.com/ghedo/tls-cer= tificate-compression

Or that's the current scope anyway. May= be it would also make sense to include
the full QUIC certificate caching= part, but I didn't want to duplicate RFC7924.

My intention woul= d be to use gzip-compressed certs on first connect, and then
use RFC7924= for consecutive handshakes.


My pla= n was to start with a zlib-based compression, and then introduce some
=
more efficient algorithm as a second step.=C2=A0 I've been looking= into the alternatives,
but I'd have to actually finish the d= ictionary refresh before doing any evaluation.

RFC= 7924 is another good place to start.=C2=A0 There are multiple improvements= to it
that I have in mind, but it would probably be reasonable t= o begin by actually getting
RFC=C2=A07924=C2=A0support into the c= ommon implementations.
=C2=A0
The text is not complete and I haven't submitted it= yet, though it would be
nice if we could work on the same draft togethe= r, in order to avoid duplicating
work (I can give you or anyone interest= ed commit access to the repo).

Cheers

I would be happy to collaborate on the draft!= =C2=A0 The TLS 1.2 story should be relatively
straightforward, but with TLS 1.3 Certificate message format we'd ha= ve to figure out
the correct layering.

=C2=A0 -- = Victor.
--94eb2c0776ee32eda00542f171e7-- From nobody Mon Dec 5 15:25:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3B9129E69 for ; Mon, 5 Dec 2016 15:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Hqp2_06h6of9 for ; Mon, 5 Dec 2016 15:25:48 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68F50129E7E for ; Mon, 5 Dec 2016 15:25:41 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 566B7284F7E; Mon, 5 Dec 2016 23:25:40 +0000 (UTC) Date: Mon, 5 Dec 2016 23:25:40 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20161205232540.GV26244@mournblade.imrryr.org> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> <20161127151304.gaqxot5wqcmcey7n@pinky.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Dec 2016 23:25:50 -0000 On Mon, Dec 05, 2016 at 06:13:56PM -0500, Victor Vasiliev wrote: > This looks promising! I am currently working on figuring out a better > pre-shared dictionary (based on CT logs analysis) so I don't have that > much code for the actual TLS parts. What is the likelihood that a dictionary that is good today will continue to be good 10+ years from now? Presumably, an effective dictionary is strongly tied to the current list of popular issuer DNs, and the list of popular issuers may well change significantly over the lifetime of the protocol. -- Viktor. From nobody Mon Dec 5 16:36:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E7712963A for ; Mon, 5 Dec 2016 16:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, 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 j8QATvO-lKbk for ; Mon, 5 Dec 2016 16:36:20 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A5AD128B38 for ; Mon, 5 Dec 2016 16:36:20 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id x190so364794069qkb.0 for ; Mon, 05 Dec 2016 16:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=xw9/Fz3L5eH84mgE0Dv9nKEHzthW0i+KhmpxQoG/Q44=; b=ERqZCdCoUdhDCfJ1/+pg7P5xvUP+3EzJStQmHQjmcIVdCA9dqD6+nyikuya7M8MknG pTbEcmk49PBHG6q4CZRfnZYsEnS9VeQwU3FIJVqNusjXFseCoJ7B6NvWiHS5vaPqbPti Fqm5pgWuV2NedpkhFbFLdCmPdGVwgtAHu4JEqbixI3Tpdja50dOKymoxyC/z1VPskSku lqRjt2x6Wx+Cn0XXRmDqMPcxDjAqpkaiZGD3yBulthLVgD5dhsEEp+xBGPooWwqDkuMn hpOCGwvK/oAzzj5qubUMtiDcELPMO9vyWQ5G7W9WBEOh/a6MH2S05oDaKQgsr7s52rrL Iupw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=xw9/Fz3L5eH84mgE0Dv9nKEHzthW0i+KhmpxQoG/Q44=; b=DET6emzK9ADYn38yR+mCUFhlr4Yq8lMxO1ehpGyh0Y6T1X4jiTihZGTCJDOkMk7Jcz U9uqDXCnbt3HH6hECzUJ5PKtWPJCn59wsxvuqftKjCJksaIuGnm147RyixAgj1w7ewWf aO8dZWMqoTst7UafbNkU3+2Kw8ZgNMRByC+ojXctWpQNJ4DrwMk9+TrNqPBWWJHeMGAV yZ8yApWDoR89hDHqTkXFLzIRRobCTHcjQhdxAC23cK6uTnAyB3UmOp3ZsF5kMbx4Lvd9 4Ng2UwxTDIz5HK+AbWTF+onfYmXfJ+gxxaMlwXkUvxqzPydjx5OUBIAH83weAkktQKfV v9qQ== X-Gm-Message-State: AKaTC03LVij/Zj6PMwoOidpi+QNF3blyrx3VSLq5U3HTfHy7me1MfdSxuhgLSadNLk+Ee1AwCFdIbHBKArpmd3FY X-Received: by 10.233.220.71 with SMTP id q68mr53021769qkf.153.1480984579267; Mon, 05 Dec 2016 16:36:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.233.239.69 with HTTP; Mon, 5 Dec 2016 16:36:18 -0800 (PST) In-Reply-To: <20161205232540.GV26244@mournblade.imrryr.org> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> <20161127151304.gaqxot5wqcmcey7n@pinky.local> <20161205232540.GV26244@mournblade.imrryr.org> From: Victor Vasiliev Date: Mon, 5 Dec 2016 19:36:18 -0500 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0438e0c41c530542f2978b Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 00:36:22 -0000 --94eb2c0438e0c41c530542f2978b Content-Type: text/plain; charset=UTF-8 The intent is to make it agnostic of specific common issuers. There are a plenty of common strings which are not going to change for a while. OIDs are a good example (some of the OIDs are quite huge!), as are the common TLDs, "https://", etc. Some of them will, of course, become outdated as technology evolves (I suspect we might see less of, say, sha256WithRsaEncryption OID 5-10 years from now, and more of whatever the crypto trend of the day is), but we can just make a new one and assign a different compression algorithm ID to it, which should scale reasonably well given the speed at which TLS evolves. On Mon, Dec 5, 2016 at 6:25 PM, Viktor Dukhovni wrote: > On Mon, Dec 05, 2016 at 06:13:56PM -0500, Victor Vasiliev wrote: > > > This looks promising! I am currently working on figuring out a better > > pre-shared dictionary (based on CT logs analysis) so I don't have that > > much code for the actual TLS parts. > > What is the likelihood that a dictionary that is good today will > continue to be good 10+ years from now? Presumably, an effective > dictionary is strongly tied to the current list of popular issuer > DNs, and the list of popular issuers may well change significantly > over the lifetime of the protocol. > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0438e0c41c530542f2978b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The intent is to make it agnostic of specific co= mmon issuers.=C2=A0 There are a
plenty of common strings which ar= e not going to change for a while.=C2=A0 OIDs are a
good example = (some of the OIDs are quite huge!), as are the common TLDs,
"= ;https://", etc.=C2=A0 Some of them will, of course, become outdated a= s technology
evolves (I suspect we might see less of, say, sha256= WithRsaEncryption OID 5-10
years from now, and more of whatever t= he crypto trend of the day is), but we
can just make a new one an= d assign a different compression algorithm ID to it,
which should= scale reasonably well given the speed at which TLS evolves.

= On Mon, Dec 5, 2016 at 6:25 PM, Viktor Dukhovni <ietf-dane@dukhovni.o= rg> wrote:
On Mon, Dec 05, 2016 at 06:1= 3:56PM -0500, Victor Vasiliev wrote:

> This looks promising!=C2=A0 I am currently working on figuring out a b= etter
> pre-shared dictionary (based on CT logs analysis) so I don't have = that
> much code for the actual TLS parts.

What is the likelihood that a dictionary that is good today will
continue to be good 10+ years from now?=C2=A0 Presumably, an effective
dictionary is strongly tied to the current list of popular issuer
DNs, and the list of popular issuers may well change significantly
over the lifetime of the protocol.
<= br> --
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

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

--94eb2c0438e0c41c530542f2978b-- From nobody Tue Dec 6 10:26:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBD1129A6A for ; Tue, 6 Dec 2016 10:26:31 -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 RAWJ-6WAegnd for ; Tue, 6 Dec 2016 10:26:29 -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 53B96129A98 for ; Tue, 6 Dec 2016 10:25:01 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id n6so355142772qtd.1 for ; Tue, 06 Dec 2016 10:25:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=nDk+P7Gkja9MP3nTYxX+f0HtMDzBi+8o9w7ryO68r3M=; b=j+xt9UEsYPNVQg+J80Ezo6hINC8LAfr66exHlYsYJDtgFlelJetNpPDZZpahXr9U/k m3zK+6+XRDEZy8QUwJIAhNKEQLgUXIKHlIW8Ff09nCNm3C/ebYSboe0Yl0WserHwh1LL dEuc9goKsEn2IT1okmbVqdT4XwCeYa6vTCbpE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=nDk+P7Gkja9MP3nTYxX+f0HtMDzBi+8o9w7ryO68r3M=; b=WGhe5OboJ7lrBCF1xq9bqdkSECCKvYgfvHB4UBQxMFYJisVwnpiC+jPV9vL/o4GxMP IDSyrW1ofwhJSoF7yPg3Xi0ZOosXxGVMVsOA2bF6PwJxMM7RPDOvS0re2x0OEHnhi5CR hHxcYeBTic565G5dSr81ZlbOjh0nsgi11mFRkjYestTW6MkP1P0knTHOuoNdxESp31ZI CM/O7bjng2546CPU2gtiEAY0JShSRPGk/Ye2KGd1ktU2KG6TY6OPx4vJqOelx2CvSeGT W8HjV0+6ddXrIQUdMKel4OJhIQ4Yaq0FVGtSbPyOVevFf/ww3+wrpDIeka0teHK2VXCA O4wA== X-Gm-Message-State: AKaTC01xWzqQCw6iBtK6QVUJmzZknmY05ywVhgmvAfwJVB1Svczy3qrdODR1E1PB/lQ4tA== X-Received: by 10.237.45.38 with SMTP id h35mr65368629qtd.9.1481048700422; Tue, 06 Dec 2016 10:25:00 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id m129sm12642319qkb.48.2016.12.06.10.24.59 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 06 Dec 2016 10:24:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> Date: Tue, 6 Dec 2016 13:24:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4CFC10D6-CB4B-496C-89AF-87340B0822D9@sn3rd.com> References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 18:26:31 -0000 Just a reminder that this WGLC will close on Friday December 9th. spt > On Nov 18, 2016, at 18:55, Sean Turner wrote: >=20 > All, >=20 > This is a working group last call for the =E2=80=9C4492bis to = Standards Track" draft available @ = http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/. Please = review the document and send your comments to the list by 9 December = 2016. =20 >=20 > Note that we are particularly interesting in the issue Yoav raises in = the following message: > https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk >=20 > Thanks, > J&S From nobody Tue Dec 6 14:19:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D02EE1295B1 for ; Tue, 6 Dec 2016 14:18: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 7ecv9cG3k9ZW for ; Tue, 6 Dec 2016 14:18:58 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10D9A12959B for ; Tue, 6 Dec 2016 14:18:58 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id n6so361393014qtd.1 for ; Tue, 06 Dec 2016 14:18:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F7HnCeThIk2kx/AYsXtgNvqq9JqUj4+EZrIxXBBc+DE=; b=O8tJ4IUIeh/7/o5dRPRN3e7KwdOy5QDPmhzebrCn6ID3I2aTvmqmInxdI+3Omhdb2v WcsveldD3hMdpdg44l9FX03P0kt8RKr4rfZots22Tm73S8/dl+jYmmnWGa1WHWtAeu4v sqfJGSwGI049mLzgJ4+1eQuXoPSKKuC7uX/DPGl0uKDmPKSiH5kdtHbGT8nlup+ScrTR wc5oApe4RqFrUgGmGVvXk9NUGKNOIeCfVYLLtaK8xHlqJLYRRBtuQ2zRBX0KrXgq4RcA 5ocQ5Qkp++ahjBaRa5GYMtYazPTEgpmK31ka5AaaaXnsiM+Uo+IKIOB2XJy9NVakrDMT KOug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F7HnCeThIk2kx/AYsXtgNvqq9JqUj4+EZrIxXBBc+DE=; b=PsnzAmofY2W3tO+ogRZlm5qXywtQS9xolqprQh7Iw6e+In8QT9d677ism+uKsAnku5 h/alzGyQktyAdZpQjptKTUOUafyQUGu5Q/1As+rI4lU49yzjnz5x5WI6JWoq2bdXhxRk 2Jrk5DDJCKu48OQEvxpP/Qt686T6CiMhOBKDbyhDWBLYGCKEC6wJaWpOo81MAVEUxXYE P5ZDqAK5uG0c4wI6nf4wj8sDVPlt9VPfr2eE/IPIxpRpv2smzDhPozqasvXx4JhKJdt6 JasmdpqXTYZ6rg33TlJnftWGhGyNwCsx2MDujSKWnHkz4Azm8s7T4xFSROqIwuD6K/cM MTjg== X-Gm-Message-State: AKaTC0313OhvSWGVpa5yH2B0rBuje8iS+OeGxJyKYBlz+Sk291eCLCnHxd8kDTaiiuC7I6ippf6I+fJGbwuGSg== X-Received: by 10.200.44.27 with SMTP id d27mr64143919qta.278.1481062737153; Tue, 06 Dec 2016 14:18:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 6 Dec 2016 14:18:56 -0800 (PST) In-Reply-To: <4CFC10D6-CB4B-496C-89AF-87340B0822D9@sn3rd.com> References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <4CFC10D6-CB4B-496C-89AF-87340B0822D9@sn3rd.com> From: Martin Thomson Date: Wed, 7 Dec 2016 07:18:56 +0900 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Dec 2016 22:19:00 -0000 On 7 December 2016 at 03:24, Sean Turner wrote: > Just a reminder that this WGLC will close on Friday December 9th. A timely reminder :) I reviewed the document and it looks pretty good. I'd have sent a PR with some minor changes to grammar. The question I wanted to ask was how we wanted to manage the relationship with TLS 1.3, particularly for EdDSA. The draft asks for a NEW codepoint in the hash and signature algorithms structure. That clobbers a whole bunch of space that TLS 1.3 is going to rework. I don't think it's a good idea to perform concurrent surgery on this registry, particularly since new codepoints have the effect of taking out new swathes of space. At best we send confusing signals to IANA. I would prefer to take the arrangement that we have in TLS 1.3 and backport it here so that we have a consistent story. I also think that taking a single 2 octet codepoint from the SignatureScheme space is better all around. If we don't do that, then - at a minimum - I'd like to see PRs for both this document and TLS that recommend values for the code points and deal with the consequences of the new codepoint allocation. Finally, I think that there is an opportunity here to observe that TLS 1.3 doesn't include any EC signals (neither ECDH nor ECDSA) in the cipher suite. From nobody Wed Dec 7 13:28:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46FC9129BDE for ; Wed, 7 Dec 2016 13:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896] 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 bFKo8IB1-qyi for ; Wed, 7 Dec 2016 13:28:33 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id C7694129BDA for ; Wed, 7 Dec 2016 13:28:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 951A3158D9; Wed, 7 Dec 2016 23:28: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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id KAYk4C8_3brj; Wed, 7 Dec 2016 23:28:30 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id EFE392310; Wed, 7 Dec 2016 23:28:29 +0200 (EET) Date: Wed, 7 Dec 2016 23:28:22 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20161207212822.GA859@LK-Perkele-V2.elisa-laajakaista.fi> References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <4CFC10D6-CB4B-496C-89AF-87340B0822D9@sn3rd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Dec 2016 21:28:35 -0000 On Wed, Dec 07, 2016 at 07:18:56AM +0900, Martin Thomson wrote: > On 7 December 2016 at 03:24, Sean Turner wrote: > > Just a reminder that this WGLC will close on Friday December 9th. > > A timely reminder :) > > I reviewed the document and it looks pretty good. I'd have sent a PR > with some minor changes to grammar. > > The question I wanted to ask was how we wanted to manage the > relationship with TLS 1.3, particularly for EdDSA. > > The draft asks for a NEW codepoint in the hash and signature > algorithms structure. That clobbers a whole bunch of space that TLS > 1.3 is going to rework. I don't think it's a good idea to perform > concurrent surgery on this registry, particularly since new codepoints > have the effect of taking out new swathes of space. At best we send > confusing signals to IANA. > > I would prefer to take the arrangement that we have in TLS 1.3 and > backport it here so that we have a consistent story. I also think > that taking a single 2 octet codepoint from the SignatureScheme space > is better all around. I actually reviewed the document and noticed the exact same thing. Also, in my TLS implementation, doing EdDSA in TLS 1.2 by backporting the TLS 1.3 mechanism (using ECDSA legacy type) just fell naturally out of the implementation. It was easier to have all the machinery needed to handle it than not to have that machinery. -Ilari From nobody Thu Dec 8 10:05:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0404412949B for ; Thu, 8 Dec 2016 10:05:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 xE6rAiTpl9hb for ; Thu, 8 Dec 2016 10:05:09 -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 2BA991294DD for ; Thu, 8 Dec 2016 10:05:09 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id w33so418488360qtc.3 for ; Thu, 08 Dec 2016 10:05:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=K8u1obmnB9TrFDjMm8m4KueG20Aun1Mu6EGOBdSvoNU=; b=aU+uqO5Af4Q+E0t+/oeItPv7ekwndXAY8UjATwyiP3apNoAdS9FcyjKWdMectWdxJz PLCf1HmtpriZEhXbYkAhO7uiII41UZBMeiM3MRY1QAhkxNRnTQgLXCU5brzweNR/uJ2s nlOSEP5oi8hzg/QmeVqgYtAPZ1X+KOrv6sHVg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=K8u1obmnB9TrFDjMm8m4KueG20Aun1Mu6EGOBdSvoNU=; b=higBRqZ2VNxxfMU6yJM6tCMbk+M7FrRE17mGrvK8RS+0hl1qu27YmH4gtwQ4cgELG5 cVL5sPMtwracv1WQKxmC94XUZVIrxiHNMfXPbme25eFjmi9WZZ2GRgV67eMyPwNrsP/g BSFnsI6y46LcTeJ3y9uqhdifJiwBNq6o6YMlEThI2kslr1rMrk0xQKi61vhyi4ZofV6M 4t9f6ysbfjpJdnKwYNzad5uZ2bw+8MGU5SoaqotC5vE/5vaS7fyUSzN+cyaAoHhH6Thl eDVhqyVJLil66XKj5eefpWXGkGnyrlNpuKdb0KHk7wwFL5LM+2n1xguJTnY0xrtH0U+O Cxwg== X-Gm-Message-State: AKaTC01YiLKu53O8DBPzS2ED5NkUl8tWX0iglCoZQf3oVZwO/YEiba7w5q80qZKCjyiabw== X-Received: by 10.200.34.5 with SMTP id o5mr63429298qto.32.1481220308205; Thu, 08 Dec 2016 10:05:08 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id 31sm17902988qty.30.2016.12.08.10.05.07 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Dec 2016 10:05:07 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 8 Dec 2016 13:05:06 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 18:05:11 -0000 All, There=E2=80=99s been some interest on the list and more in Seoul to = adopt http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ = as a TLS WG item. We marked the draft as a "Candidate for WG = Adoption=E2=80=9D in the datatracker, but now it=E2=80=99s time to = officially do the WG call for adoption. So, if you would like for this = draft to become a WG document and you are willing to review various = versions as it moves through the process, then please let the list know = by December 21st. If you are opposed to this being a WG document, = please say so (and say why). Cheers, J&S= From nobody Thu Dec 8 10:27:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 181311293D8 for ; Thu, 8 Dec 2016 10:27:37 -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 U5VsMXgRnwGs for ; Thu, 8 Dec 2016 10:27:34 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A19A129494 for ; Thu, 8 Dec 2016 10:27:34 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id n6so419993186qtd.1 for ; Thu, 08 Dec 2016 10:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=o32fcCSti//8sqU9R6tUN4bvfCS+LKfNe9cG20YGUKU=; b=CyZDlp4YlI5HCpMle9Cm77A4m/VxIOdbYRY2tEYym5F/2jX59M7t2aUsRNUnSu5J8+ q2N13WM/YG9xrCUVmB0uzDtmuhhA/xBaWEBY8TO4BChB2GX6oKRgEbKz2YzzyMqKdCP6 QmvuTzD7GyaA7jzwN+zF1hS7gdmOKudB7I2ss= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=o32fcCSti//8sqU9R6tUN4bvfCS+LKfNe9cG20YGUKU=; b=Cu8Av9hishSusqhrJrnqjqX7odoRnjLgVI6GO1ouTldNgSSdUDwjakXz39F0FCtdNq yGdikxah4/ghAAWYvPqBe+bfeTSQBY1gndfHRv7otLaaPTZX97fvbDM16CHede4qgoxu WtaWD7OXgCbfpDS8wVDyvm5MrIgmcQeljV7KG1/+uZ8hqUQzlr3P+y/UK49L2zX4vR9p IdzniwxgAvF6S/0Hh7kzzZZ+27BFq4epxgLh6BVzU4fRtR1n7U2Pe8RIm9/Pj6JIYFXn 7piFQku1IQPhX7pBwfhtKwiKiHxQsKDDUjD7W/qN7Wbz4m73fa9d84AJFpb/VJ0mmpIU rGdA== X-Gm-Message-State: AKaTC010MDIgynd0Vb++gw4koabnQWZ9qq2YORf4Y9wZcy8Z+sh+UQMHQNW7qbziToMp7g== X-Received: by 10.200.53.239 with SMTP id l44mr73918782qtb.60.1481221653469; Thu, 08 Dec 2016 10:27:33 -0800 (PST) Received: from [172.16.0.92] (pool-173-73-120-80.washdc.east.verizon.net. [173.73.120.80]) by smtp.gmail.com with ESMTPSA id x123sm17848532qkx.46.2016.12.08.10.27.32 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 08 Dec 2016 10:27:33 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Thu, 8 Dec 2016 13:27:32 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] WG adoption call: draft-davidben-tls-grease X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 18:27:37 -0000 All, There=E2=80=99s been some interest on the list in = http://datatracker.ietf.org/doc/draft-davidben-tls-grease/ (aka=20 Applying Generate Random Extensions And Sustain Extensibility to TLS = Extensibility). We=E2=80=99d like to determine whether there=E2=80=99s = enough interest to adopt the draft as a WG item. So, if you would like = for this draft to become a WG document and you are willing to review = various versions as it moves through the process, then please let the = list know by December 21st. If you are opposed to this being a WG = document, please say so (and say why). Cheers, J&S= From nobody Thu Dec 8 10:31:36 2016 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 C3F2F12969E; Thu, 8 Dec 2016 10:31:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148122189479.6970.568364084606560054.idtracker@ietfa.amsl.com> Date: Thu, 08 Dec 2016 10:31:34 -0800 Archived-At: Subject: [TLS] The TLS WG has placed draft-davidben-tls-grease in state "Call For Adoption By WG Issued" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 18:31:35 -0000 The TLS WG has placed draft-davidben-tls-grease in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-davidben-tls-grease/ Comment: WG call for adoption ends 20161221. From nobody Thu Dec 8 10:34:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728F91295DD for ; Thu, 8 Dec 2016 10:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, 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 vVhVxfCKtrVl for ; Thu, 8 Dec 2016 10:34:21 -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 C898812952B for ; Thu, 8 Dec 2016 10:34:20 -0800 (PST) Received: by mail-ua0-x234.google.com with SMTP id 51so456196239uai.1 for ; Thu, 08 Dec 2016 10:34:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c2Vc7O58LZucEAiT3XBWRXDGKdQgwIYA0KuRTtfCxlc=; b=Pqs7C7+syNwlYfgAQXbiaptAj5Bk4DvyaqPjmwEBTNPGHe/JdxpQjGw6Bxpvi4mR1A ftxslwDfal1/RCuw1ANBsmAI1sbWUS+xA3smgBLVW/gnTTBecpqvRvxO7rWdbpkI4yWn 4sTunyTvwQaK2Aogja2Ran0LV0SANjuonDdCBaOfa88PFiMlix9f7ksFuPuV52ukjcvG JH/20DxQrMj4PdvPvYlaLkms3I+5L9eq7NheTZeoEAvvj99adIPlqyMtptra1Qrztx2b P+m0Z16rEjaXcPz0WJq3Wb5cMY2nfCQYzdtiR6kxCp/BT+vT6WphsScAOufQePZ0SEqa o4tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c2Vc7O58LZucEAiT3XBWRXDGKdQgwIYA0KuRTtfCxlc=; b=KGZnZEH7tKs3X2ih/LMy8U3kdU9qUoApI1DSVAGfFsJJemBC9kRedk2GjN69soKS7y 7BssUplZNSg24R0pDNmJ2FqpOjWP1anmB0Ysrk/rx4KtaeBFgzeiIUyvmtnPjVRvNTqX +hKFNdqmlt8wMa+7uqG4X/5nkVWKBtO7HNEykgKPIXOq2JCp37HVT3aWJqz8j8VCboay 1bioUxgRwfb8y5hzjPzf0IZhb1clqsrrAc8KW8xysoIzOKPhsQD5AmoQ9d2abHHh143L 1ssJH0srylsoLmQW2xeszagwB4ZnrrGqEKGig+4DgqCxbJ2icve+46kcnFBJLoNo2G2B Utmg== X-Gm-Message-State: AKaTC00J2G2VAfPXwQipNOxC74IMlnhZSOR0kEzxlaY8ycTWyN7zQfsj1ShH3dSNbSv/f46wMB2G34fg9J11k1R7 X-Received: by 10.159.39.7 with SMTP id a7mr50049335uaa.95.1481222059849; Thu, 08 Dec 2016 10:34:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.132 with HTTP; Thu, 8 Dec 2016 10:34:19 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 8 Dec 2016 10:34:19 -0800 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=94eb2c1244f6b64757054329e2e9 Archived-At: Cc: "" Subject: Re: [TLS] WG adoption call: draft-davidben-tls-grease X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 18:34:26 -0000 --94eb2c1244f6b64757054329e2e9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm very supportive of this draft being adopted. FWIW, I'd love to see similar mechanisms in other protocols as well. - jana On Thu, Dec 8, 2016 at 10:27 AM, Sean Turner wrote: > All, > > There=E2=80=99s been some interest on the list in http://datatracker.ietf= .org/ > doc/draft-davidben-tls-grease/ (aka > Applying Generate Random Extensions And Sustain Extensibility to TLS > Extensibility). We=E2=80=99d like to determine whether there=E2=80=99s e= nough interest to > adopt the draft as a WG item. So, if you would like for this draft to > become a WG document and you are willing to review various versions as it > moves through the process, then please let the list know by December 21st= . > If you are opposed to this being a WG document, please say so (and say wh= y). > > Cheers, > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1244f6b64757054329e2e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm very supportive of this draft being adopted. FWIW,= I'd love to see similar mechanisms in other protocols as well.
- jana

On Thu, Dec 8, 2016 at 10:27 AM, Sean Turner <sean@sn3rd.com= > wrote:
All,

There=E2=80=99s been some interest on the list in http://datatracker.ietf.org/doc/draft-davidben-tls-grease/= (aka
Applying Generate Random Extensions And Sustain Extensibility to TLS Extens= ibility).=C2=A0 We=E2=80=99d like to determine whether there=E2=80=99s enou= gh interest to adopt the draft as a WG item.=C2=A0 So, if you would like fo= r this draft to become a WG document and you are willing to review various = versions as it moves through the process, then please let the list know by = December 21st. If you are opposed to this being a WG document, please say s= o (and say why).

Cheers,

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

--94eb2c1244f6b64757054329e2e9-- From nobody Thu Dec 8 10:57:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAB241295DD for ; Thu, 8 Dec 2016 10:57:04 -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 fLV54-zYir7I for ; Thu, 8 Dec 2016 10:57:03 -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 CC43E1294BB for ; Thu, 8 Dec 2016 10:57:02 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id t125so328264573ywc.1 for ; Thu, 08 Dec 2016 10:57:02 -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=vnCPI+BSLtp9ntYFJ6mcPhOpEAUCQB0quNpZbeglZAM=; b=g03ipGoi2jkn5phTthPkSRYL3nIZl16Xxoymo3+PD7OX+TWGMyOXYJDOpJEdIpa3NE P92gnWRCiKpF392v5vYEHcewqw2/Jx+nMicfkZGAuGsU2QdTkc2quaARnnNhtz7WTHHk QDQh4UNn0JcxEbr6W3vFkA70QW7QIH1HUA4T5cEuzQcm/iX8AW//WmtWGTc7ge6j5f6w U35rRNHzb4KPb2/b4O0s5ZqawWiksOvX8uAQLxrsNVf6md5MJNtirurzE2XIoO2r5T5W WpGZGbEhqEYO/md32NfozUSU2ZyT9la1cOxWTo5Y7lEocrZlaMnKq5iO8KYokcaMT4FE vDqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vnCPI+BSLtp9ntYFJ6mcPhOpEAUCQB0quNpZbeglZAM=; b=Ddcr+gZ/fQg5N0YCnzpZC0SN3EKc6DHc8tz6MZxh2Uj6iINFCBAUTef/S6kWqF4r85 3RUpOtY6XKAg9lkEeAcYRN5UrFBxv17CVOSKnU23Z/Kn/grS0oZuHmOwgqfbtuK4J29G Qcjc2H4Yub2yySbXQg7gxxO4XCrXYMBY/fWrnLE6P6Q5LbIoIrTB3wEBIleVOkrLMfd1 mpJJ7dElxCc0yxUL73wyT/FIAkf3vn4nGurAOWEmVDmoGw960EKE3LH54bWYjVj8jvYj 4p3NF+jmpokMwdw1CTDjUK6kTvs3zCOcYS+bvOjVY0AB9H3gmHeo6rWIxmWWyQ5dGCnk fqcA== X-Gm-Message-State: AKaTC01xT+/c9/sZ/okcloMPjEqeryg40OrudK8WLKkeMmio6TGdYs+u7Zh8M+87TwirjV8tJzYN4vx8pSALeg== X-Received: by 10.129.78.71 with SMTP id c68mr69371501ywb.21.1481223422067; Thu, 08 Dec 2016 10:57:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Thu, 8 Dec 2016 10:56:21 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 8 Dec 2016 08:56:21 -1000 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a114dac9ce843e105432a334f Archived-At: Cc: "" Subject: Re: [TLS] WG adoption call: draft-davidben-tls-grease X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 18:57:05 -0000 --001a114dac9ce843e105432a334f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Thu, Dec 8, 2016 at 8:27 AM, Sean Turner wrote: > All, > > There=E2=80=99s been some interest on the list in http://datatracker.ietf= .org/ > doc/draft-davidben-tls-grease/ (aka > Applying Generate Random Extensions And Sustain Extensibility to TLS > Extensibility). We=E2=80=99d like to determine whether there=E2=80=99s e= nough interest to > adopt the draft as a WG item. So, if you would like for this draft to > become a WG document and you are willing to review various versions as it > moves through the process, then please let the list know by December 21st= . > If you are opposed to this being a WG document, please say so (and say wh= y). > > Cheers, > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dac9ce843e105432a334f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Thu, Dec 8, 2016 at 8:27 AM, Sean Turner <<= a href=3D"mailto:sean@sn3rd.com" target=3D"_blank">sean@sn3rd.com> wrote:
All,

There=E2=80=99s been some interest on the list in http://datatracker.ietf.org/doc/draft-davidben-tls-grease/= (aka
Applying Generate Random Extensions And Sustain Extensibility to TLS Extens= ibility).=C2=A0 We=E2=80=99d like to determine whether there=E2=80=99s enou= gh interest to adopt the draft as a WG item.=C2=A0 So, if you would like fo= r this draft to become a WG document and you are willing to review various = versions as it moves through the process, then please let the list know by = December 21st. If you are opposed to this being a WG document, please say s= o (and say why).

Cheers,

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

--001a114dac9ce843e105432a334f-- From nobody Thu Dec 8 10:58:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 255331295DD for ; Thu, 8 Dec 2016 10:58:39 -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 uNIdUtx_PRov for ; Thu, 8 Dec 2016 10:58:36 -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 8C2FB12954C for ; Thu, 8 Dec 2016 10:58:36 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id r204so329332426ywb.0 for ; Thu, 08 Dec 2016 10:58:36 -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=84Jgf5wWLLiaGxGCamUudv17RCeIPIrITPB+5WhUxS0=; b=G+AuBng6szul9uW3kfUhtEUfK8os61l285SVpFlM4oCl5k45uwX1hu4Rxe9xrpszYq 92n16bGweAFMItw0kiFYwkUrGu7SHM7zpHRcMtZ1xUPFk12QyzZaJ4bu3lFRkFMZYANq XgW09WuDY/ZZE9noJsAoqpIkZzufQlO93gyN6UBm2oyLJLeNYxdis4K/rWHxreT+g6AU rku/cLzItclENOyFuD7/E3/qOHkC6RrRhVBn0BWTRN0Gis6sTez1c81DGZZqo+vf3ZR/ RgdBX0GJMjkXywr8dPUb5xkzQBgKdUFcEF/CSwFyUdj4QpyyCHvGm4Nt6WYTG+xNtciD 3Oig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=84Jgf5wWLLiaGxGCamUudv17RCeIPIrITPB+5WhUxS0=; b=Yqm/AxS4IHdL+2kADIUEeGh5cy6NNoUP8f4LoGPa+g5VGYPbhQhp2yj/V8JbqFS9U6 FfTUaFToNvxDYNKyx8dT+uxMkPeq0LJMWTy8A9fEgijVE1TXnD4v1WQl3YjeDNRDOftD 8533Qcwvs9IEclumX9VYT9i7C1HDxzBPyUQvpv/10K7hy4Z/ffjAC1dLO57OFJaTFLR5 PGJ1IvuR9nzwVgAMGyWs5Dvo4HBlDIUpDobaIvcpyPMT0HqiUDHltzTU+G8EuRJcx8zI 3213kbXUbrOPpCMQHMALVKfpBDF2W73cxDjxJlhgVzYjHoyRyv//e4auX4Jnb2IzGYfB gfyA== X-Gm-Message-State: AKaTC02CYmd7+H5KfQgf/kqiNE7lgNhRHC8sTAMzCzo7N1mf2z+4wRxvcBOrcbMH4ZyBby+HjwuoPL/2+PO9Fg== X-Received: by 10.129.81.78 with SMTP id f75mr69468012ywb.149.1481223515823; Thu, 08 Dec 2016 10:58:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Thu, 8 Dec 2016 10:57:55 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 8 Dec 2016 08:57:55 -1000 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a114564047ecb2a05432a392e Archived-At: Cc: "" Subject: Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 18:58:39 -0000 --001a114564047ecb2a05432a392e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Thu, Dec 8, 2016 at 8:05 AM, Sean Turner wrote: > All, > > There=E2=80=99s been some interest on the list and more in Seoul to adopt > http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ as a TLS > WG item. We marked the draft as a "Candidate for WG Adoption=E2=80=9D in= the > datatracker, but now it=E2=80=99s time to officially do the WG call for a= doption. > So, if you would like for this draft to become a WG document and you are > willing to review various versions as it moves through the process, then > please let the list know by December 21st. If you are opposed to this > being a WG document, please say so (and say why). > > Cheers, > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114564047ecb2a05432a392e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Thu, Dec 8, 2016 at 8:05 AM, Sean Turner <<= a href=3D"mailto:sean@sn3rd.com" target=3D"_blank">sean@sn3rd.com> wrote:
All,

There=E2=80=99s been some interest on the list and more in Seoul to adopt <= a href=3D"http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/"= rel=3D"noreferrer" target=3D"_blank">http://datatracker.ietf.org/doc/= draft-thomson-tls-tls13-vectors/ as a TLS WG item.=C2=A0 We marked= the draft as a "Candidate for WG Adoption=E2=80=9D in the datatracker= , but now it=E2=80=99s time to officially do the WG call for adoption.=C2= =A0 So, if you would like for this draft to become a WG document and you ar= e willing to review various versions as it moves through the process, then = please let the list know by December 21st.=C2=A0 If you are opposed to this= being a WG document, please say so (and say why).

Cheers,

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

--001a114564047ecb2a05432a392e-- From nobody Thu Dec 8 11:11:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0AE129545 for ; Thu, 8 Dec 2016 11:11: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T3zRz8lJCUq7 for ; Thu, 8 Dec 2016 11:11:35 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA0651296A8 for ; Thu, 8 Dec 2016 11:11:33 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 51so457186503uai.1 for ; Thu, 08 Dec 2016 11:11:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SiGfLuA2kthf+fbzTY72Gwr9OUFiRHnGSo9peB4i5a4=; b=gJTz2HDfLd01WfN8uNrb0AN3lFLzhlUkcs/gvdV/3vti4YJ2ykS41/wCLpaCsV1AJM dkYpJUfufw9XZVFy233AdPMv87Lq/JsI3WFaFFBtoa353TLnL7W8I3RbBJ7nzBZQzZzl hpck8L23V64bPB9vekU6ylvhmuPxbP8SHRrtrs3NM18bcW/DlqcQAb/OKYXlX76H/i2b QiAV34kV88glSbaHm3SBi0s9qFohlLKLXSURkcmofelCzNgLDbAX+/VdF5Nf2vkDBJsu u7RtGlEL2TNEsqKo7+hbhbhDhRxxpV6lM/SOgW5ljOueFn20BMJXCMYmC2+/yWUWuUVQ yFFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SiGfLuA2kthf+fbzTY72Gwr9OUFiRHnGSo9peB4i5a4=; b=UklKiHeCEpCPK4IDO2C6hK8PykOXRusH/ulaHYB9FaICcNInvFRhsJWB/SIRUmk2xM 41Ut9FjNgb2s1vJM3ytCAmgMifuRu4qzTvx1apP1IGdJS+NrvBTxxQhWz0LUHkkFPFn+ lgYomcjeQtAnIga4dCf3M/C4/x2PK8fPOAcBsjGNor+MNMJOYYxUfeTqSNaG3aILl0BJ 4DkOGPPlfGQk3VXB/XqAs7HyXhO3wFslXyCFv4laTI+J705DQP8ZGzNHKsZ0ENB2ahOD nsibI4qonq9hj1sjW2PNAymPf57jjXEXGUcqTeINOt3Jlx80eSOCAXP4g8xtRsgzvYfC kd5w== X-Gm-Message-State: AKaTC00gYbIWDSf5Bj69ZgCNdw1f5WhSDKUWDs14iGHjAEm3n/J5YuUvHMSFFnIAUqX7fHm5bvTZHnSYDXWGSw== X-Received: by 10.159.49.22 with SMTP id m22mr58077694uab.72.1481224292351; Thu, 08 Dec 2016 11:11:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.106.71 with HTTP; Thu, 8 Dec 2016 11:11:31 -0800 (PST) In-Reply-To: References: From: Richard Barnes Date: Thu, 8 Dec 2016 09:11:31 -1000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=f403045dd8f4c785ed05432a67fb Archived-At: Cc: "" Subject: Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 19:11:37 -0000 --f403045dd8f4c785ed05432a67fb Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Thu, Dec 8, 2016 at 8:57 AM, Eric Rescorla wrote: > +1 > > On Thu, Dec 8, 2016 at 8:05 AM, Sean Turner wrote: > >> All, >> >> There=E2=80=99s been some interest on the list and more in Seoul to adop= t >> http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ as a >> TLS WG item. We marked the draft as a "Candidate for WG Adoption=E2=80= =9D in the >> datatracker, but now it=E2=80=99s time to officially do the WG call for = adoption. >> So, if you would like for this draft to become a WG document and you are >> willing to review various versions as it moves through the process, then >> please let the list know by December 21st. If you are opposed to this >> being a WG document, please say so (and say why). >> >> Cheers, >> >> J&S >> _______________________________________________ >> 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 > > --f403045dd8f4c785ed05432a67fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Thu, Dec 8, 2016 at 8:57 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
+1
<= div class=3D"HOEnZb">

On Thu, Dec 8, 2016 at 8:05 AM, Sean Turner <sean@sn3rd= .com> wrote:
All,

There=E2=80=99s been some interest on the list and more in Seoul to adopt <= a href=3D"http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/"= rel=3D"noreferrer" target=3D"_blank">http://datatracker.ietf.org/doc/= draft-thomson-tls-tls13-vectors/ as a TLS WG item.=C2=A0 We marked= the draft as a "Candidate for WG Adoption=E2=80=9D in the datatracker= , but now it=E2=80=99s time to officially do the WG call for adoption.=C2= =A0 So, if you would like for this draft to become a WG document and you ar= e willing to review various versions as it moves through the process, then = please let the list know by December 21st.=C2=A0 If you are opposed to this= being a WG document, please say so (and say why).

Cheers,

J&S
_______________________________________________
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


--f403045dd8f4c785ed05432a67fb-- From nobody Thu Dec 8 11:17:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A879D129545 for ; Thu, 8 Dec 2016 11:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8vQmIkXflaoj for ; Thu, 8 Dec 2016 11:17:17 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 7CD66126B6D for ; Thu, 8 Dec 2016 11:17:17 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id p42so20547929ioo.1 for ; Thu, 08 Dec 2016 11:17:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8N5xTximcBhmKPPLJ2hOgasoF0o9ePUSlqeNSN9L0j8=; b=NaXFL+ozLFT/ISbARLZ+PviHh8QS0dQ0Edm0/GLOFYVaso0ZBVlgHkcJMfTS11z4Vo d61Bv8vvTSk7xZSDbNSTWtwGtX1pxSO0wbnkJk6tHzPcXq2LXt5Z6vBCp8SBZMg4qZAi 7pEcCIlDTTf5zTFWrj+iFCbL7Y8xJrY4oGdAI7rnv8OSKmhJjtS57cRkGMsOWHd1jAMF Y/RWpB0l8P+b+JUs6gXfsZZlCCjt/1kU0b5cIbJYQWz5W5C31UJqueI/C9qH/dt9VgiU lZoaCGPeDm+ea4ty7cDiUJDQZsxgKUYmeBetvBKirK0QgC1vofnqFms9v4Pu2ExMZ0pk 8/qA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8N5xTximcBhmKPPLJ2hOgasoF0o9ePUSlqeNSN9L0j8=; b=J5X6NG58qfYKrvzjKsbeFhF+ISFh2t0FnHs3ivMSmB1mtjJ5cNkgsrcH72ayuODt4i SxNgzeWJbN+MF2BdtBZWbKYHMD/dXg6gntfxPFNubp1ibkl8tPRUPvgYh3jxYk+Tz2IF 8yaju3i8+aBeiNSF0RBqTNHsBIBLBzyylgT/eNeKat3L8ehXf2bCoYMGWUdfN7GABnmC GVk0wnj+4oTX6zk5F0df+Y9YrRAAc73ubSKd9qn2F95SUvhSVctpfkg0ZzztiAwAvDdp Wk03jXPLJZ0yBQmF0o6iR03z2Jgos8jIdGPt4QgWgiXA3KjGD48HIayiZUtePt0v7i/W PXNQ== X-Gm-Message-State: AKaTC00OBB70gULmp2bkHN44uGuX0FcU5dmsh174EQHzR2WYq3iQjGQQCsnPUBwqdDLcjRdriBKS0ugFwYlwMg== X-Received: by 10.107.154.206 with SMTP id c197mr67234098ioe.97.1481224636658; Thu, 08 Dec 2016 11:17:16 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.22.83 with HTTP; Thu, 8 Dec 2016 11:17:16 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Thu, 8 Dec 2016 11:17:16 -0800 X-Google-Sender-Auth: ujtco73tF1ZqyyyiJlN5LarFGso Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1140fadc4cf8ee05432a7cb8 Archived-At: Cc: "" Subject: Re: [TLS] WG adoption call: draft-davidben-tls-grease X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 19:17:20 -0000 --001a1140fadc4cf8ee05432a7cb8 Content-Type: text/plain; charset=UTF-8 On Thu, Dec 8, 2016 at 10:56 AM, Eric Rescorla wrote: > +1 > I'm not sure whether I could as an independent voice on this topic, but I strongly support adoption of this draft. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --001a1140fadc4cf8ee05432a7cb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Dec 8, 2016 at 10:56 AM, Eric Rescorla <ekr@rtfm.com> wrote:<= br>
+1

I'm not sure whether I could as an independent voice o= n this topic, but I strongly support adoption of this draft.

=

Cheers

AGL
--
Adam Langley agl@imperialviolet.org https://www.imperialviolet.org
--001a1140fadc4cf8ee05432a7cb8-- From nobody Thu Dec 8 13:32:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C14E61296E4 for ; Thu, 8 Dec 2016 13:32:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.607 X-Spam-Level: X-Spam-Status: No, score=-3.607 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MN-ykXO-dsQp for ; Thu, 8 Dec 2016 13:32:22 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id A713E1295A5 for ; Thu, 8 Dec 2016 13:32:22 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 2E696433451; Thu, 8 Dec 2016 21:32:22 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 1824F43344F; Thu, 8 Dec 2016 21:32:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1481232742; bh=ZHMtSymz3dsl2PWKmdfUP+Y9jkRpn+IRvEWzP41xv+c=; l=4940; h=To:References:Cc:From:Date:In-Reply-To:From; b=FAG2VOmRVD9yFf88gCk66RQlXiUMxXU48xCg573fi50XsyPWxPDYpRGgIm3+0OwBd 5y6CzmmX/yhU+1B8mhyArc0Zai2HvuHt2liwHliujVSZgn8rI4wfhXtMOm+BvRlFTf naMEAZZIbHbLOrkBf+60/oC81vF/IxkKCASXujfo= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id E04301FC98; Thu, 8 Dec 2016 21:32:21 +0000 (GMT) To: Sean Turner References: From: Benjamin Kaduk Message-ID: <53f9def4-586a-460c-9a5f-5fdaa6f3150a@akamai.com> Date: Thu, 8 Dec 2016 15:32:21 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------6BDD9C58D62DFD2C19F2DD47" Archived-At: Cc: "" Subject: Re: [TLS] WG adoption call: draft-davidben-tls-grease X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 21:32:25 -0000 This is a multi-part message in MIME format. --------------6BDD9C58D62DFD2C19F2DD47 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Also +1 -Ben On 12/08/2016 12:56 PM, Eric Rescorla wrote: > +1 > > On Thu, Dec 8, 2016 at 8:27 AM, Sean Turner > wrote: > > All, > > There’s been some interest on the list in > http://datatracker.ietf.org/doc/draft-davidben-tls-grease/ > > (aka > Applying Generate Random Extensions And Sustain Extensibility to > TLS Extensibility). We’d like to determine whether there’s enough > interest to adopt the draft as a WG item. So, if you would like > for this draft to become a WG document and you are willing to > review various versions as it moves through the process, then > please let the list know by December 21st. If you are opposed to > this being a WG document, please say so (and say why). > > Cheers, > > J&S > _______________________________________________ > 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 --------------6BDD9C58D62DFD2C19F2DD47 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Also +1

-Ben

On 12/08/2016 12:56 PM, Eric Rescorla wrote:
+1

On Thu, Dec 8, 2016 at 8:27 AM, Sean Turner <sean@sn3rd.com> wrote:
All,

There’s been some interest on the list in http://datatracker.ietf.org/doc/draft-davidben-tls-grease/ (aka
Applying Generate Random Extensions And Sustain Extensibility to TLS Extensibility).  We’d like to determine whether there’s enough interest to adopt the draft as a WG item.  So, if you would like for this draft to become a WG document and you are willing to review various versions as it moves through the process, then please let the list know by December 21st. If you are opposed to this being a WG document, please say so (and say why).

Cheers,

J&S
_______________________________________________
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

--------------6BDD9C58D62DFD2C19F2DD47-- From nobody Thu Dec 8 13:36:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA54C12958C for ; Thu, 8 Dec 2016 13:36:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xE-Rws4CdJfN for ; Thu, 8 Dec 2016 13:36:52 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id AFDB01297BE for ; Thu, 8 Dec 2016 13:36:51 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 33FE843343C for ; Thu, 8 Dec 2016 21:36:51 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 1CA4543343A for ; Thu, 8 Dec 2016 21:36:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1481233011; bh=PxyRRsc6X8q5VNXMFG08sufNExwCadPzhcYxYY93GG4=; l=2775; h=To:References:From:Date:In-Reply-To:From; b=zrxYa8swolSTn4HUYvsWF3TVbMyRz78Rc8cygkQak0UF1QAwzGDkaPYaYQQkBL/8l jcTkvB9ms0vL0Ppc39CwI2cBuGtafRnA/GvXKdJFFspSvDlLtqI9sinaDS6wJyMe0U Hso31zGQQex7kFqGcERYpNa44h2JxS3twYaMZ2ao= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id EB9D21FC98 for ; Thu, 8 Dec 2016 21:36:50 +0000 (GMT) To: "" References: From: Benjamin Kaduk Message-ID: <4f7e5fc2-605d-eb30-0a02-2410a5dccaa2@akamai.com> Date: Thu, 8 Dec 2016 15:36:50 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------66B67DBD1DD5E2E1D6C2488B" Archived-At: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 21:36:54 -0000 This is a multi-part message in MIME format. --------------66B67DBD1DD5E2E1D6C2488B Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit I think we should adopt the document. I'm happy to review the document, though I don't expect to be validating the vectors themselves. -Ben On 12/08/2016 12:05 PM, Sean Turner wrote: > All, > > There’s been some interest on the list and more in Seoul to adopt http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ as a TLS WG item. We marked the draft as a "Candidate for WG Adoption†in the datatracker, but now it’s time to officially do the WG call for adoption. So, if you would like for this draft to become a WG document and you are willing to review various versions as it moves through the process, then please let the list know by December 21st. If you are opposed to this being a WG document, please say so (and say why). > > Cheers, > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------66B67DBD1DD5E2E1D6C2488B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit I think we should adopt the document.  I'm happy to review the document, though I don't expect to be validating the vectors themselves.

-Ben

On 12/08/2016 12:05 PM, Sean Turner wrote:
All,

There’s been some interest on the list and more in Seoul to adopt http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ as a TLS WG item.  We marked the draft as a "Candidate for WG Adoption†in the datatracker, but now it’s time to officially do the WG call for adoption.  So, if you would like for this draft to become a WG document and you are willing to review various versions as it moves through the process, then please let the list know by December 21st.  If you are opposed to this being a WG document, please say so (and say why).

Cheers,

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

--------------66B67DBD1DD5E2E1D6C2488B-- From nobody Thu Dec 8 14:02:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33D95129A6D for ; Thu, 8 Dec 2016 14:02:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 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, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xoexC_TYUpXa for ; Thu, 8 Dec 2016 14:02:40 -0800 (PST) Received: from BAY004-OMC2S18.hotmail.com (bay004-omc2s18.hotmail.com [65.54.190.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9678C129A84 for ; Thu, 8 Dec 2016 14:02:00 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com ([65.54.190.124]) by BAY004-OMC2S18.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Thu, 8 Dec 2016 14:02:00 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fKbe6rc//B3zEY9PgWOddgqzYrF7JartYsEkDLoUFtA=; b=OJJgAxTqjJ5a3Xf501Y5XcmGNMzf0qx7xwBzSa4tMk9FPYRAkKoipk7E+OAaAoYUAUyrYxeO/hZ8zI4yqw35kMDxNDh4VdWZo5PTewu5Af1hXWnkIFzeghb8whxTauqQBGc+hx1hKV+/1U7w0oj210eL/b2msScdCLmuW7Vgv6775Q+ho7wrw0AsF7BsALdPWWwmzv53gGM9OLgGizbYZ4pesfkKyKWiaohp+65KoginsKIfpdySvmXBxRDWfEJza4L4IJkPLYG+mj0fXMuTji3ve1MlyD4PrKfB1F8n8/+gCk3kdrq4mBXB58CFO4HwIBzQfqIM7Icc4C3T3CfEuw== Received: from BY2NAM03FT032.eop-NAM03.prod.protection.outlook.com (10.152.84.54) by BY2NAM03HT128.eop-NAM03.prod.protection.outlook.com (10.152.85.232) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.6; Thu, 8 Dec 2016 22:01:59 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.84.55) by BY2NAM03FT032.mail.protection.outlook.com (10.152.84.228) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.761.6 via Frontend Transport; Thu, 8 Dec 2016 22:01:58 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0761.018; Thu, 8 Dec 2016 22:01:58 +0000 From: Xiaoyin Liu To: Richard Barnes , Eric Rescorla Thread-Topic: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors Thread-Index: AQHSUX2jJU0NeAzvdU2KfPl93sQEsaD+ZvyAgAADzYCAAC+dsg== Date: Thu, 8 Dec 2016 22:01:58 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ipv.sx; dkim=none (message not signed) header.d=none;ipv.sx; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:3D4031567278DED5B714E355532AB344F14A20B4F80F3429E7A0E4E2FAEDD26B; UpperCasedChecksum:D5F368602310152330AB24E574BC2BF302C30BDE9DBC1210973700BC1B44E555; SizeAsReceived:7662; Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [YVyh1ocL3FhmuDLt9yBy7D+P0CCaJy+6] x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; BY2NAM03HT128; 5:15Yepl3M6v2/RLoVjpGHMmLi1DPFt9BKizKHN/2xNl0Q4+gVfLWcEe0mOzzCuIxNQ1zjE97gKQTOjUF4VALsTmzztM+9DU0qvnujFh/KXK+V3EL8bI7MUDNVQvH2oo0gyVeWZVNOe1V5RtrGJE1JXg==; 24:rda3ThmsHTDik0VHvLRBbewSGtoUkfTZMY4EzzuFrueYqSeTvIfdo64x5eOA8hC3gKxNVHJtoS86KB6HGAuw3nU4uhhATMlHaHWUGzy8QU8=; 7:x9z3Dygp60VAHHaju7/0ErTOuNss1xNKpfKbUAsrNIVUlKNXLoIkzb+hVGNFjGzVdCazRiIGsJn7v+6SM1MlcWxfXUkSEZ9vSBXBA0le6DOygQPg9tZCppBvbtngc+4N2b8XwX9k1T+ltJztRSa5z3jJzXF+EmtkdhDoeIBb+wTmnX0OGmCLBtG4hRmi8xCmGEnNwXF1WMICLpxcELESW3dH1tFaxvwcaB4pIgbx4vt90+RP/aGFNpP2qQ+/iDD1g7ErG+z3mt237bOJqP3NJPOH5AhJybfEAoMzrp+fTcJXq/J5RveC9WTRRgFfZxZNp89073EfDi7I1Qv1nqSAB6KFCgyi2LhS9B6G+GA/q6RMLLYs92tBbuzEhkzEfUaG3/HAaUVyKzfsPn25dBw5naFubQDtG833yvF6cy9GIxeFaYkXP3HfXi6Jpfd4RBh9xycxq95JVwXZlGGwJu3GzQ== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2NAM03HT128; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: ed6624c3-7daf-4c28-d91a-08d41fb5d4ba x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(5061506293)(5061507293)(1603103113)(1603101340)(1601125047); SRVR:BY2NAM03HT128; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:BY2NAM03HT128; BCL:0; PCL:0; RULEID:; SRVR:BY2NAM03HT128; x-forefront-prvs: 0150F3F97D spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0778276A7C1CBA9E26471547FF840CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Dec 2016 22:01:58.3638 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2NAM03HT128 X-OriginalArrivalTime: 08 Dec 2016 22:02:00.0483 (UTC) FILETIME=[B377EF30:01D2519E] Archived-At: Cc: "" Subject: Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Dec 2016 22:02:42 -0000 --_000_CY1PR15MB0778276A7C1CBA9E26471547FF840CY1PR15MB0778namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: Richard Barnes Sent: Thursday, December 8, 2016 2:11 PM To: Eric Rescorla Cc: Subject: Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors +1 On Thu, Dec 8, 2016 at 8:57 AM, Eric Rescorla > wrote: +1 On Thu, Dec 8, 2016 at 8:05 AM, Sean Turner > wrote: All, There's been some interest on the list and more in Seoul to adopt http://da= tatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ as a TLS WG item. = We marked the draft as a "Candidate for WG Adoption" in the datatracker, bu= t now it's time to officially do the WG call for adoption. So, if you woul= d like for this draft to become a WG document and you are willing to review= various versions as it moves through the process, then please let the list= know by December 21st. If you are opposed to this being a WG document, pl= ease say so (and say why). Cheers, J&S _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CY1PR15MB0778276A7C1CBA9E26471547FF840CY1PR15MB0778namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

From: Richard Barnes
Sent: Thursday, December 8, 2016 2:11 PM
To: Eric Rescorla
Cc: <tls@ietf.org>
Subject: Re: [TLS] WG adoption call: draft-thomson-tls-tls13-vectors=

 

+1

On Thu, Dec 8, 2016 at 8:57 AM, Eric Rescorla <ekr@rtfm.com><= /span> wrote:
+1

On Thu, Dec 8, 2016 at 8:05 AM, Sean Turner <sean@sn3rd.com&= gt; wrote:
All,

There’s been some interest on the list and more in Seoul to adopt http://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/<= /a> as a TLS WG item.  We marked the draft as a "Candidate for WG= Adoption” in the datatracker, but now it’s time to officially = do the WG call for adoption.  So, if you would like for this draft to become a WG document and you are willing to review various v= ersions as it moves through the process, then please let the list know by D= ecember 21st.  If you are opposed to this being a WG document, please = say so (and say why).

Cheers,

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


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


--_000_CY1PR15MB0778276A7C1CBA9E26471547FF840CY1PR15MB0778namp_-- From nobody Fri Dec 9 22:55:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00AE51297AC for ; Fri, 9 Dec 2016 22:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.098 X-Spam-Level: X-Spam-Status: No, score=-107.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 95Aud6ARCXXP for ; Fri, 9 Dec 2016 22:55:11 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694CF129702 for ; Fri, 9 Dec 2016 22:55:11 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 622BFB80F8C; Fri, 9 Dec 2016 22:55:10 -0800 (PST) To: yngve@spec-work.net, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161210065510.622BFB80F8C@rfc-editor.org> Date: Fri, 9 Dec 2016 22:55:10 -0800 (PST) Archived-At: Cc: rfc-editor@rfc-editor.org, ashwini.oruganti@gmail.com, tls@ietf.org Subject: [TLS] [Technical Errata Reported] RFC6961 (4882) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Dec 2016 06:55:13 -0000 The following errata report has been submitted for RFC6961, "The Transport Layer Security (TLS) Multiple Certificate Status Request Extension". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6961&eid=4882 -------------------------------------- Type: Technical Reported by: Ashwini Oruganti Section: 2.2 Original Text ------------- opaque OCSPResponse<0..2^24-1>; Corrected Text -------------- opaque OCSPResponse<1..2^24-1>; Notes ----- - The text below the definition states: Only one OCSP response, with a length of at least one byte, may be sent for status_type "ocsp". - `OCSPResponse` was originally (correctly) defined in RFC6066 (https://tools.ietf.org/html/rfc6066#section-8) with a lower bound of 1 byte. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6961 (draft-ietf-tls-multiple-cert-status-extension-08) -------------------------------------- Title : The Transport Layer Security (TLS) Multiple Certificate Status Request Extension Publication Date : June 2013 Author(s) : Y. Pettersen Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Dec 12 00:53:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9A01294FF for ; Mon, 12 Dec 2016 00:53:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SZJ2p8dvNZdH for ; Mon, 12 Dec 2016 00:53:39 -0800 (PST) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06FD9129475 for ; Mon, 12 Dec 2016 00:53:38 -0800 (PST) Received: from vsmta13.fe.internet.bosch.com (unknown [10.4.98.53]) by imta24.fe.bosch.de (Postfix) with ESMTP id 80A7CD801DB for ; Mon, 12 Dec 2016 09:53:35 +0100 (CET) Received: from SI-MBX1009.de.bosch.com (vsgw22.fe.internet.bosch.com [10.4.98.11]) by vsmta13.fe.internet.bosch.com (Postfix) with ESMTP id 5988F2E40C9F for ; Mon, 12 Dec 2016 09:53:35 +0100 (CET) Received: from SI-MBX1009.de.bosch.com (10.3.230.31) by SI-MBX1009.de.bosch.com (10.3.230.31) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 12 Dec 2016 09:53:35 +0100 Received: from SI-MBX1009.de.bosch.com ([fe80::10dd:4e6e:2230:2153]) by SI-MBX1009.de.bosch.com ([fe80::10dd:4e6e:2230:2153%20]) with mapi id 15.00.1236.000; Mon, 12 Dec 2016 09:53:34 +0100 From: "Grehl Felix (ETAS-PSC/ECE1)" To: "tls@ietf.org" Thread-Topic: DTLS: Multiple application records in a datagram Thread-Index: AdJUVInr32hetxF0RsKi2tdsW22nHw== Date: Mon, 12 Dec 2016 08:53:34 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.44.114.13] Content-Type: multipart/alternative; boundary="_000_c1577b34a5794eabbbc2bcc9bb4f51ddSIMBX1009deboschcom_" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22754.006 X-TMASE-MatchedRID: rk+eI4QUOnJUO3zzgy+7kFT/YzREB9OKNU8z+tFJHR1tw+n+iKWyyFu6 0iJoidH6F9DBRyDKvIJJpV9rHFX3j+2u5u3xOQvhwbRQ2Bpmlioay+BQxgCfhZb7No0srrTk7KB BZ2QBUyzQ23n+P5pIMRQjizXtCXfTWYqLLUX2mAtB6yOrxc8xu7PksiHb4g58j2iyfwmt0k+fT+ tFD2StEUvnk+TiAq32Iog2od+iX+fezO9WekFnOEg5Iem1vm3HuacNrbMY+LQQHQ+7AkbTsZm3C kZsyRGFwmm5gw944w+6rmzU3nJhUA5VocU4CFzq2x/FmlC/aoyb/LTS0T1K1so/pjLBvlo2EW4+ DfKR/mG7sLiGJ4XBUoAy6p60ZV62jWQsmj6To3LQLWxBF9DMQWxlRJiH4397IDnnCjjFHvq1pQc LvUR3gBFxXCG2Me0K1ZCnlh14ZFuZL/dSpD97dGYwkBhr5wD0uyM3dVyVA3x4PpJbzMWdHhSKfy UyHWKE Archived-At: Subject: [TLS] DTLS: Multiple application records in a datagram X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 08:53:42 -0000 --_000_c1577b34a5794eabbbc2bcc9bb4f51ddSIMBX1009deboschcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have a question regarding records in DTLS 1.2. RFC6347 says: "Multiple DT= LS records may be placed in a single datagram. They are simply encoded cons= ecutively". However, what happens if one UDP datagram contains multiple records of type= application? Which way should an implementation handle this case? 1) Both records are merged such that the application layer gets them as= a single message (message =3D UDP datagram), or 2) Each record is passed as a separate message to the application layer= (message =3D DTLS record) Best regards, Felix --_000_c1577b34a5794eabbbc2bcc9bb4f51ddSIMBX1009deboschcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have a question regarding = records in DTLS 1.2. RFC6347 says: “Multiple DTLS records may be plac= ed in a single datagram. They are simply encoded consecutively”.=

However, what happens if one= UDP datagram contains multiple records of type application? Which way shou= ld an implementation handle this case?

 

1= )   &= nbsp; Both records are merged= such that the application layer gets them as a single message (message =3D= UDP datagram), or

2= )   &= nbsp; Each record is passed a= s a separate message to the application layer (message =3D DTLS record)

 

Best regards,

Felix=

 

--_000_c1577b34a5794eabbbc2bcc9bb4f51ddSIMBX1009deboschcom_-- From nobody Mon Dec 12 05:13:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6DC129AF8 for ; Mon, 12 Dec 2016 05:13:25 -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 EvedVoSqA-u2 for ; Mon, 12 Dec 2016 05:13:23 -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 2278C129AF1 for ; Mon, 12 Dec 2016 05:13:23 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id t125so63948440ywc.1 for ; Mon, 12 Dec 2016 05:13:23 -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=trh7jnvsE712CCU5tCSy2x0aSPfo7TsPZ6sqOSf7pt0=; b=fV+wS9C/rGOHhY18s3jvrotKfh0G5LQlpqxT0JJsNlZu4p4Yh8uKPh5rjcZrRLZ0XO cXc09gxwyqFNfv3f0BGcsM/g0mh1sEsns5XD+hqggzFJyyEBbdC27aSq57dpUp3SrZAw YCgGxZJNv/d0T7MnuTYe6nmaVcIW0dxkMOh4mpLQSLpTawyvcovBjbKD1VyrelHX8sMJ cldqneSe7OsfUkvF+xZAj1ocDW+Zojr7rXrtkpuzBv4Gtw+PibXz1QjouRw7xsd8i/MU PCWBDoyAa+KlyIkiPjt0JRypLIPLFhsw80Gw7WeLXp3/YNs2ECF6hMlIhM1QfjW2xOM7 zDsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=trh7jnvsE712CCU5tCSy2x0aSPfo7TsPZ6sqOSf7pt0=; b=YX1C7uFQCFMyunXN47zr1p13WvMcjDRdKgF30RllIcEcoJssvijjCQDP3rmtg7HL2J BWZsDFXnFjqfYHx8SewUcLjGLUGR2Zryj2cZBHC1IOTA7sKFVU31fl4r17UlTICo/1Jw 90DhOe73iWk5hVyFtaqCxhjXXYZUD7mI8Qdqa+q22ZUnYU2xzUZ9vCSSta111o4fgdzH 1LbqYJzYUWg+GpNFmWtVtVAWZ4RNAZLTQxCnxsBCEL7+PW1q6phJqxfPC1LLNOudmjZY s+YM74VIaSp8k+ZrsXArXAbnVQeqw1m+q9Rb374AsGBFAwkYNCv/aRDag9UE9XU+dRZi GZWA== X-Gm-Message-State: AKaTC00Fw4awZD6pQqNRAZXsvMx5FlwN7286KxJ+q2etG03AID8NXsuCQ53RaD27D77O5djCqg6UTuLUm4hdMA== X-Received: by 10.129.81.78 with SMTP id f75mr89471875ywb.149.1481548402221; Mon, 12 Dec 2016 05:13:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Mon, 12 Dec 2016 05:12:41 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 12 Dec 2016 03:12:41 -1000 Message-ID: To: "Grehl Felix (ETAS-PSC/ECE1)" Content-Type: multipart/alternative; boundary=001a114564043bb9bd054375decf Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] DTLS: Multiple application records in a datagram X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Dec 2016 13:13:25 -0000 --001a114564043bb9bd054375decf Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Generally, the spec doesn't prescribe API behavior, but #2 seems like the right one because otherwise an attacker could coalesce/split such records. -Ekr On Sun, Dec 11, 2016 at 10:53 PM, Grehl Felix (ETAS-PSC/ECE1) < felix.grehl@escrypt.com> wrote: > Hi, > > > > I have a question regarding records in DTLS 1.2. RFC6347 says: =E2=80=9CM= ultiple > DTLS records may be placed in a single datagram. They are simply encoded > consecutively=E2=80=9D. > > However, what happens if one UDP datagram contains multiple records of > type application? Which way should an implementation handle this case? > > > > 1) Both records are merged such that the application layer gets them > as a single message (message =3D UDP datagram), or > > 2) Each record is passed as a separate message to the application > layer (message =3D DTLS record) > > > > Best regards, > > Felix > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114564043bb9bd054375decf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Generally, the spec doesn't prescribe API behavio= r, but #2 seems like the right one because otherwise an attacker could coal= esce/split such records.

-Ekr


On Sun, Dec 11, 2016 at= 10:53 PM, Grehl Felix (ETAS-PSC/ECE1) <felix.grehl@escrypt.com&= gt; wrote:

Hi,=

=C2=A0

I have= a question regarding records in DTLS 1.2. RFC6347 says: =E2=80=9CMultiple = DTLS records may be placed in a single datagram. They are simply encoded co= nsecutively=E2=80=9D.

Howeve= r, what happens if one UDP datagram contains multiple records of type appli= cation? Which way should an implementation handle this case?<= /span>

=C2=A0

1)=C2=A0=C2=A0=C2=A0=C2=A0 Both records are merged su= ch that the application layer gets them as a single message (message =3D UD= P datagram), or

2)=C2=A0=C2=A0=C2=A0=C2=A0 Each record is passed as a= separate message to the application layer (message =3D DTLS record)=

=C2=A0

Best r= egards,

Felix

=C2=A0


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


--001a114564043bb9bd054375decf-- From nobody Mon Dec 12 17:10:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68F86129FF5 for ; Mon, 12 Dec 2016 17:10: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 allXeD8CxSXl for ; Mon, 12 Dec 2016 17:10:04 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC11129FF4 for ; Mon, 12 Dec 2016 17:10:03 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id v132so7398140yba.0 for ; Mon, 12 Dec 2016 17:10:03 -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=fPL2h7dyt7vfJAXfXlVKaWQsNPQgAzLiV1cehTDCIaQ=; b=W3fijh1NsbERLny/DWbOsLaULRzxRmfc6by2ga6/fTBtBrZpagHMLL7nIUc3XaS7kB xtCpXouS/ma5fdwsQwn4ll5/lElf9BDSWy3pnGV8cE0nZEXQZl48zbPvi/aPnU1K4e+0 mMDYo5zDHH3sJAkcFfZFTVm7M4j+PndGS31qJ0zLtXGodrjHVauQtzzCyrTnONeM9X3a DGGsJIyjQATw1+rJ3Ow0XATwbseRPI2VJWqspCS1mek3TGi4yHf/8kO6UeMTxGIhJOIg 9aXYLJUT+L05c2X/baIXz9TtXFB4y8CZnv0QlbaE8Q3IOMEm1jhJ/YVRtGIPH1QxshIA m+6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=fPL2h7dyt7vfJAXfXlVKaWQsNPQgAzLiV1cehTDCIaQ=; b=AwIikCg1SAt2iOIOlOgqAm5+R5mPGbumTDmNLG9DaLPYBOFi9xbJUIFoICRWUvWYM+ YuY3Gs3ohIhzVskIxPbuaGFLxeeYBF/TvFRmumcwp3+6tkq+jhgWp65bjvicQ+s5c9X8 lEpZiRmBjf/lav9iDt5jOsgnpwexC0k9kcfu+fqiVRKsNIONOKP0NPYw0GPLMgaCLcSx SFui+zuo6edNwqwgjVe1cvcelYdQHzKWf1EqTS7lTxPV1g9DTMgbyPJdlVsvVsi671ry 0IYuEWuHpUuD2wlVuOsN9x3hhYehYzTKzI06zVf+OGqrBknt7DyI3m1AdcHSdf76MNaL dZLw== X-Gm-Message-State: AKaTC02uJeQWrIuHGvb6tdpLEtWRC3hgUHIwfGXIk5Xjv2LKh0htLnSwuwpGpbgHhSaqBxr8ArICyagrlICwXw== X-Received: by 10.37.65.9 with SMTP id o9mr10765678yba.65.1481591403056; Mon, 12 Dec 2016 17:10:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Mon, 12 Dec 2016 17:09:22 -0800 (PST) From: Eric Rescorla Date: Mon, 12 Dec 2016 17:09:22 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c0007c4841b105437fe12a Archived-At: Subject: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:10:06 -0000 --001a11c0007c4841b105437fe12a Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/812 David Benjamin pointed out to me that end_of_early_data is the only place where we transition keys on an alert and this would be cleaner if it was a handshake message. This PR does that. It's encrypted under the same keys, so this is largely an aesthetic issue, but I think a good one. Target merge date: Thursday. -Ekr --001a11c0007c4841b105437fe12a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

David Benjamin pointed out to me that end_of_early_data is the only = place
where we transition keys on an alert and this would be clea= ner if it was a
handshake message. This PR does that. It's en= crypted under the same
keys, so this is largely an aesthetic issu= e, but I think a good one.

Target merge date: Thur= sday.

-Ekr

--001a11c0007c4841b105437fe12a-- From nobody Mon Dec 12 17:10:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8253C129FF6 for ; Mon, 12 Dec 2016 17:10:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sMBo40_LUmpU for ; Mon, 12 Dec 2016 17:10:46 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 42D8712A000 for ; Mon, 12 Dec 2016 17:10:44 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BC4C8433423; Tue, 13 Dec 2016 01:10:43 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id A636E43341B; Tue, 13 Dec 2016 01:10:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1481591443; bh=2K9thyUCt28hg6Dr2+nAZy1r38fyrjb8gf6pTQaDalk=; l=1045; h=To:References:From:Date:In-Reply-To:From; b=P5JwXtCgpkOkJBHNpqsCuFmjn6hEOpr/MoJXMB8r+/lkAl0pVEI2uXaDzTjKTkbYp 0mYd7nF56+dZR42fRQ/3mwpeUWRFkwBhG6JU+CJ9wGenFdSbGIbjGN30e+hAri2GJ/ lDqKBB3ztfJKXvgjl9ZDx6Ega2tOCV5SmTDI/7LI= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 789E61FC88; Tue, 13 Dec 2016 01:10:43 +0000 (GMT) To: Eric Rescorla , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <9f744a27-687f-3d4d-c675-e87eb9c9d5ff@akamai.com> Date: Mon, 12 Dec 2016 19:10:43 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5A27394194A44E182C0EFF46" Archived-At: Subject: Re: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:10:48 -0000 This is a multi-part message in MIME format. --------------5A27394194A44E182C0EFF46 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/12/2016 07:09 PM, Eric Rescorla wrote: > It's encrypted under the same > keys, so this is largely an aesthetic issue, but I think a good one. Agreed on both counts. -Ben --------------5A27394194A44E182C0EFF46 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/12/2016 07:09 PM, Eric Rescorla wrote:
It's encrypted under the same
keys, so this is largely an aesthetic issue, but I think a good one.

Agreed on both counts.

-Ben
--------------5A27394194A44E182C0EFF46-- From nobody Mon Dec 12 17:23:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B27129431 for ; Mon, 12 Dec 2016 17:23:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 YygaDqKcXHHp for ; Mon, 12 Dec 2016 17:23:21 -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 BB20012A001 for ; Mon, 12 Dec 2016 17:23:20 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id c47so93715833qtc.2 for ; Mon, 12 Dec 2016 17:23:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lmFiiiyqfgiYl1d5Hr1Vc6MIb4FhNWKd/87FJXlB9KM=; b=XBQevUq8kBPcuLWDmF2MYmuT1Df4wDws0mAROjb7jzdZq3bAuJnWEPHFcudhJ1FOGD toOnNEZeYphopABjZgx/b66XHLVyGMoeyAUYXjk0hmc4vl8j3bc4j89poyEgVZNmlDLz 67JF66fAealyhyzv29TIXafRPHy2A9SYjhI+KS5aMHrTMeJWnoq1/LuDdCMOxqP3fWrn CHbDNyUOCHmhx+zBP0UhYvvQLK16MiuBO24o9aL4aYgustvCjs6HF9YI51irpOezEEXQ CzrGBh4377uArfTP2836566tpuSRiure/dZ1hkHL1hHxpjEiGhTHlSuFlcTlYrUxDyeS VIgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lmFiiiyqfgiYl1d5Hr1Vc6MIb4FhNWKd/87FJXlB9KM=; b=TIH6VNHofannMhqdcjRyQ/8USLApC1FO800MgAFlkVN3pEQpTvp0ShZWdegWQ+3VOt ykxxOG5CXovCIHislr82zxH4rXWmbKyXVLFigHg1cSVlOlEiozEJIv3PepQq99Dnsv9U JJ2R5cUKcqIIyKJd+kmTdPAQlbi3Wq3Ml8b/26gVZTkY9NuEmLpAFPPOuhnSoj7VfgU7 F1X0PSoKSpmWr1cxrf/4tnP0NSkYNQNHguqwGjdvY7cCiFWqaaHNb2j3CUiPbTYEanTr Ygoc1aJ70KtZkjNWuUvY1bJftHWAI47gmRbiGKrgVOEKhRtRwzZumjCKwk0sbzw/yR9P MZXQ== X-Gm-Message-State: AKaTC00uA7jEtL4N9JHlhcWxxcql585r6aGrgbNBmE9L37BIGfZm5SkNf/tNy2EoAdPE4fmJ9Pjb0CFk7XD51Q== X-Received: by 10.200.44.27 with SMTP id d27mr92299065qta.278.1481592199935; Mon, 12 Dec 2016 17:23:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Mon, 12 Dec 2016 17:23:19 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 13 Dec 2016 12:23:19 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:23:22 -0000 On 13 December 2016 at 12:09, Eric Rescorla wrote: > David Benjamin pointed out to me that end_of_early_data is the only place > where we transition keys on an alert and this would be cleaner if it was a > handshake message. This PR does that. It's encrypted under the same > keys, so this is largely an aesthetic issue, but I think a good one. The major change in this PR isn't that obvious. And that is this: if the server has accepted early data, an EndOfEarlyData message will be sent to indicate [a] key change. This makes the end of early data signal conditional: a client that learns that its 0-RTT data has been rejected MUST NOT send the EndOfEarlyData message. The reason for this is that the EndOfEarlyData is a handshake message and therefore part of the handshake transcript. Presumably it appears after Finished (I'm going to send a PR that expands the ellipsis in the draft at least once, so that people can see the full canonical order). FWIW, I think that this is the right change, but some implementations will need to change in some non-obvious ways. I'm not aware of anyone who is rejecting 0-RTT and then decrypting the data so they can avoid a bunch of failed decryptions, but that approach won't work any more. From nobody Mon Dec 12 17:33:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2925112A016 for ; Mon, 12 Dec 2016 17:33:43 -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] 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 towyAb1z-6sK for ; Mon, 12 Dec 2016 17:33:41 -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 5D8BF12A008 for ; Mon, 12 Dec 2016 17:33:41 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id a10so75508945ywa.3 for ; Mon, 12 Dec 2016 17:33:41 -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=ij/ETnZ4+CgoffRxLORI0a0hieAkI+dsEmquMC/z59o=; b=Mill73L1aWjfFGNugxI6vIhK8hhvgGGUajv4Y/aAtLTUEOqP3sz+zVz/xb9EL7S9hV O8O9hMQ8y23al8Y5gHeeYbZo0NeXJJ/2s7OQNQNjAEjxjow6MqHfyCutDce4Pmfid+j4 Drab2zqAkNzN+7KH6Rkpxgc0X76XZhUNvXhWoc/sh6aFDLUphnwDaDZed+W0yIoFMAfK ZXwQO0A3MDjIb1GThajxxWCtdLIGhQSZcrVWKfO/XkD4bSjeqvIHvzkTZnoqUdAc/PWF mKfpjxcd32qK85kFQ8LJJjoOUY3vVNHyaxZxdEOHV73JdxKmVuTiUyZmjWVEEkzgY0BF Xxww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ij/ETnZ4+CgoffRxLORI0a0hieAkI+dsEmquMC/z59o=; b=UR9AynRsqHcJswyb4Pikg0BNeP0+t1uhADPVId2BYrBhrIgLUCp2IQ7XcQ8/r3Hn/O cchk+mkZ5rh/y1w26RyuC5RFZrA4X78Mx48yVcG3A86NMjKs1jKTUkAp/x1FbPOCGRSg 1ah3xrvbYzNSWDlZz8VXtCeBMRYUZdZNdAiZwX5qApaQtf4AjiFwDA+8D7D9cs6ULtEo Qrou5B+gl0Gigj9hDYS4uZI4TZvOqSF4mBXjFDE7ucN08tIpAgnd0NlIazgX3n9l6g0b DptFrfNFwjjtK+eDEOzpExjq93dlS35Z/iKVn3kPH9FsJsBc2Fl7MakEpTJrvKJP9r25 JUdw== X-Gm-Message-State: AKaTC00exiMN4oOXfbVnqIEPJ+/BcuxjRhn091/lX3nbLDX7v4BWdqUL+6PLpxa31o5dAWfPlm65BBNd/mqDFg== X-Received: by 10.129.108.216 with SMTP id h207mr93755014ywc.52.1481592820633; Mon, 12 Dec 2016 17:33:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Mon, 12 Dec 2016 17:32:59 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 12 Dec 2016 17:32:59 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114dd36ec6d410054380358d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:33:43 -0000 --001a114dd36ec6d410054380358d Content-Type: text/plain; charset=UTF-8 On Mon, Dec 12, 2016 at 5:23 PM, Martin Thomson wrote: > On 13 December 2016 at 12:09, Eric Rescorla wrote: > > David Benjamin pointed out to me that end_of_early_data is the only place > > where we transition keys on an alert and this would be cleaner if it was > a > > handshake message. This PR does that. It's encrypted under the same > > keys, so this is largely an aesthetic issue, but I think a good one. > > The major change in this PR isn't that obvious. And that is this: > > if the server has accepted early data, an EndOfEarlyData > message will be sent to indicate [a] key change. > > This makes the end of early data signal conditional: a client that > learns that its 0-RTT data has been rejected MUST NOT send the > EndOfEarlyData message. > > The reason for this is that the EndOfEarlyData is a handshake message > and therefore part of the handshake transcript. Presumably it appears > after Finished (I'm going to send a PR that expands the ellipsis in > the draft at least once, so that people can see the full canonical > order). > > FWIW, I think that this is the right change, but some implementations > will need to change in some non-obvious ways. > Thanks for pointing this out. I agree with this assessment. We could of course exclude it from the transcript but that seems silly. I'm not aware of anyone who is rejecting 0-RTT and then decrypting the > data so they can avoid a bunch of failed decryptions, but that > approach won't work any more. > Actually you could, just discard EOED in that mode. -Ekr --001a114dd36ec6d410054380358d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 12, 2016 at 5:23 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 13 December 2016 at 12:09, Eric Rescorla <ekr@rtfm.com> wrote:
> David Benjamin pointed out to me that end_of_early_data is the only pl= ace
> where we transition keys on an alert and this would be cleaner if it w= as a
> handshake message. This PR does that. It's encrypted under the sam= e
> keys, so this is largely an aesthetic issue, but I think a good one.
The major change in this PR isn't that obvious.=C2=A0 And that i= s this:

=C2=A0 =C2=A0if the server has accepted early data, an EndOfEarlyData
=C2=A0 =C2=A0message will be sent to indicate [a] key change.

This makes the end of early data signal conditional: a client that
learns that its 0-RTT data has been rejected MUST NOT send the
EndOfEarlyData message.

The reason for this is that the EndOfEarlyData is a handshake message
and therefore part of the handshake transcript.=C2=A0 Presumably it appears=
after Finished (I'm going to send a PR that expands the ellipsis in
the draft at least once, so that people can see the full canonical
order).

FWIW, I think that this is the right change, but some implementations
will need to change in some non-obvious ways.

Thanks for pointing this out. I agree with this assessment. We could= of course
exclude it from the transcript but that seems silly.


I'm not aware of anyone who is rejecting 0-RTT and then decrypting the<= br> data so they can avoid a bunch of failed decryptions, but that
approach won't work any more.

Actua= lly you could, just discard EOED in that mode.

-Ek= r


=C2=A0

--001a114dd36ec6d410054380358d-- From nobody Mon Dec 12 17:43:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D66129EE3 for ; Mon, 12 Dec 2016 17:43:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, 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 ZPNCPL7UaqkN for ; Mon, 12 Dec 2016 17:43:41 -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 4CD81129854 for ; Mon, 12 Dec 2016 17:43:41 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id n21so102503595qka.3 for ; Mon, 12 Dec 2016 17:43:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=utaMCUUufb9GfqvjNwKH4lfhc2eyDQXfosrfE7yUBao=; b=HW7SkrjyZi71EWz/WJmS0vYu/pM0zf9i+a2he5XBXr/GA88dBXqPfd1bwHnYAGVUOf ecATn1Mnww06Qe6aXTIH9NJBxUfKqI8/8I6p5Dbk86sxI4DMSgjDCyI6ag+GR5MQbZnV h+WcdzeO1ZQ/86yX1uhFa94t7LRPmxItk2pLBS9ZPu1tTgDqSp1X6G6wjbv5ip1Njolb 2Z6U1KUFyt9q6+QSqd/eSgvPw6BKIzDmMi6RkO3Lb0tQ9JccD5X/U/oGuLqW0Jg9ZIyM hXJxY7D8qiR3i0E8DOMLC1w4ql1LN6+iJjsnidU+hC6XyFBmCf8eF17SvDPeM6POw2rh 5/2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=utaMCUUufb9GfqvjNwKH4lfhc2eyDQXfosrfE7yUBao=; b=Ffsduk/E1dDtSYDaCSDsyeRhW08z/xQIOBEmcLLPO1GvVlPuZ6rV6YQ1oyKAl2LrjH PmxguEHtcAuU96P2f5FV17elpoijNeKmojs6qCk8kKQece/oRnRuUVZ4QzZAYTfhgPWd pki/Cqjp5QdtMwnsMQMrEVa5NRH4XZtu8HVXpL/0CdS57y5XPhkBlhSucXBC/6kYXmwr lvvIDRRIqFXKF7aKUX74eX71FDkD5brN8hF7UajHmKUwj+Bc0Ca7Yrk1yZubmapdnNEz fhN3wUrPRfZ3JHW6JW5nXsdMCo+rf9Qs4pNJhSM9fbgRElqr5xW0yPdnc4cC2bBXhnLD OgKA== X-Gm-Message-State: AKaTC00ePq0E5rw2wKhdI/nJZHDUHG5SfiNxga8rMgcpEvcsHqHpGcbO1lWc0TqDthgzxQomg5rLQCu/nJLu7a79 X-Received: by 10.55.105.4 with SMTP id e4mr26466552qkc.273.1481593420232; Mon, 12 Dec 2016 17:43:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.17.52 with HTTP; Mon, 12 Dec 2016 17:43:19 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Mon, 12 Dec 2016 17:43:19 -0800 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114ff2c2840e610543805967 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:43:44 -0000 --001a114ff2c2840e610543805967 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 12, 2016 at 5:32 PM, Eric Rescorla wrote: > > > On Mon, Dec 12, 2016 at 5:23 PM, Martin Thomson > wrote: > >> On 13 December 2016 at 12:09, Eric Rescorla wrote: >> > David Benjamin pointed out to me that end_of_early_data is the only >> place >> > where we transition keys on an alert and this would be cleaner if it >> was a >> > handshake message. This PR does that. It's encrypted under the same >> > keys, so this is largely an aesthetic issue, but I think a good one. >> >> The major change in this PR isn't that obvious. And that is this: >> >> if the server has accepted early data, an EndOfEarlyData >> message will be sent to indicate [a] key change. >> >> This makes the end of early data signal conditional: a client that >> learns that its 0-RTT data has been rejected MUST NOT send the >> EndOfEarlyData message. >> >> The reason for this is that the EndOfEarlyData is a handshake message >> and therefore part of the handshake transcript. Presumably it appears >> after Finished (I'm going to send a PR that expands the ellipsis in >> the draft at least once, so that people can see the full canonical >> order). >> >> FWIW, I think that this is the right change, but some implementations >> will need to change in some non-obvious ways. >> > > Thanks for pointing this out. I agree with this assessment. We could of > course > exclude it from the transcript but that seems silly. > Right now, I believe it's legal for a client to send ClientHello, early data, and end_of_early_data alert without reading any messages from the server. This change would require a client to wait for the ServerHello before sending (or not) EndOfEarlyData, but that seems quite reasonable. > > > I'm not aware of anyone who is rejecting 0-RTT and then decrypting the >> data so they can avoid a bunch of failed decryptions, but that >> approach won't work any more. >> > > Actually you could, just discard EOED in that mode. > > -Ekr > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114ff2c2840e610543805967 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 12, 2016 at 5:32 PM, Eric Rescorla <ekr@rtfm.com>= wrote:


On Mon, Dec 12, 2016 at 5:23 PM, Martin Thomson <marti= n.thomson@gmail.com> wrote:
On 13 December 2016 at 12:09, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote= :
> David Benjamin pointed out to me that end_of_early_data is the only pl= ace
> where we transition keys on an alert and this would be cleaner if it w= as a
> handshake message. This PR does that. It's encrypted under the sam= e
> keys, so this is largely an aesthetic issue, but I think a good one.
The major change in this PR isn't that obvious.=C2=A0 And that i= s this:

=C2=A0 =C2=A0if the server has accepted early data, an EndOfEarlyData
=C2=A0 =C2=A0message will be sent to indicate [a] key change.

This makes the end of early data signal conditional: a client that
learns that its 0-RTT data has been rejected MUST NOT send the
EndOfEarlyData message.

The reason for this is that the EndOfEarlyData is a handshake message
and therefore part of the handshake transcript.=C2=A0 Presumably it appears=
after Finished (I'm going to send a PR that expands the ellipsis in
the draft at least once, so that people can see the full canonical
order).

FWIW, I think that this is the right change, but some implementations
will need to change in some non-obvious ways.

Thanks for pointing this out. I agree with this assessment. W= e could of course
exclude it from the transcript but that seems s= illy.

Right now, I = believe it's legal for a client to send ClientHello, early data, and en= d_of_early_data alert without reading any messages from the server. This ch= ange would require a client to wait for the ServerHello before sending (or = not) EndOfEarlyData, but that seems quite reasonable.

I'm not aware of anyone who is rejecting 0-RTT and then decrypting the<= br> data so they can avoid a bunch of failed decryptions, but that
approach won't work any more.

Actually you could, just discard EOED in that mode.

<= div>-Ekr


=C2=A0


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


--001a114ff2c2840e610543805967-- From nobody Mon Dec 12 17:45:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6993212A020 for ; Mon, 12 Dec 2016 17:45:34 -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 hVmMvy8dfFRy for ; Mon, 12 Dec 2016 17:45:32 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F601129EA3 for ; Mon, 12 Dec 2016 17:45:32 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id n6so94208380qtd.1 for ; Mon, 12 Dec 2016 17:45:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LAIk17gGK6GgUKyiEqwKdnoH8GMw7tdZxwbr3oOrB/c=; b=jLQlkrKhhCDXCscNwOFzG78hyznJaYKZBtpmr11jk7AHwYUOZvmuILEoDaVdiZhEkU UXzZCuCM9h5QWMFwpNFnjV5gcUMgJuGm3XVnvP0LRzvASerJD7pvsIf0YjYme6up23dI cIHBHS5qoI6EYMXBlwTPGiCkq4Y++8Gw2T2WUPrR8DxCyH7iTdf4qM0pYxotykv6YUaq mB6mtwI4JR/nayzXShwaTsMzeQLF1LHc/5AFdeZuULHiMX8xs46nIqmq6brA72CxG88+ X4dB8YVYP6nNEnEAVI7N0greMB7hVqcSudFByQEsJLBglkJE+X4xjk+GsQfngXF4np5S Gqhg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LAIk17gGK6GgUKyiEqwKdnoH8GMw7tdZxwbr3oOrB/c=; b=QicOZJInQa2yvqmODDFjRIPrCwB4FxlRGHAYJK55A4IF2ajLOTQgscIUWWNpfAyfB3 mUmYxLhA6uD2MsQkgNZ7z2VUKLRQnAnReb5n8/+6HxtiA0h/DfIKkGEHYzVb3urbsbxc EuLkbVbdPBQHq2OoVm2GcyEHMFk5iUHiTji8u2DRVA7c/OIv/EQtGd3Bwew1vsVLaoDt HLwvOYWnUlMJSSijXSstoniLDpvgE+ZMl8THA1pnyk3UkzDtTygaHO1DsZ8EEMfeJP7D e/Bty9yxotBQDaNFAB0BHP3l8y6RJQujQJnpqqM+FD0PFGwfEGOwH6N3Mn4cd7hBFpqD uw6A== X-Gm-Message-State: AKaTC02YqoJd6x8QCF2uZHdICtENRWJ7cxfAXh0JRNxU/eha/hdQf66vNkmF9FHGNaGGueFgNZWsPwtqa/209g== X-Received: by 10.200.44.27 with SMTP id d27mr92341220qta.278.1481593531843; Mon, 12 Dec 2016 17:45:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Mon, 12 Dec 2016 17:45:31 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 13 Dec 2016 12:45:31 +1100 Message-ID: To: Nick Harper Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:45:34 -0000 On 13 December 2016 at 12:43, Nick Harper wrote: > Right now, I believe it's legal for a client to send ClientHello, early > data, and end_of_early_data alert without reading any messages from the > server. This change would require a client to wait for the ServerHello > before sending (or not) EndOfEarlyData, but that seems quite reasonable. It's legal to send EndOfEarlyData at any time as long as it follows the (first) ClientHello, but you are right in observing that it would be difficult to send it at a different time than when you are entering it into the transcript. p.s., It's the Server Finished that you have to wait for, not just ServerHello. From nobody Mon Dec 12 17:51:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 480BF1294CD for ; Mon, 12 Dec 2016 17:51:21 -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 6mgwesYFCKyF for ; Mon, 12 Dec 2016 17:51:18 -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 5AB9112A034 for ; Mon, 12 Dec 2016 17:51:18 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id a10so75693302ywa.3 for ; Mon, 12 Dec 2016 17:51:18 -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=w/SmphGa5oBMXVuHBDUEZ/jgX3HoYNFOaoa/s/X1F7I=; b=ayQ1oA4KOjO72/C/UJ3l/ivD1m9HD7k6NWBR8eajsmlPaIag3pA2zGDIuiPBuxyupq m15frb7aclUrjdG0KuLMA2286tUmIH1siOyfOLGnEq8Da0NkSnWeCmWd613eT9oN/Y4S vA4WjT2dCnQ7exoW+HvcfkeEnNwdkk0JD5BXS9hGogPgXKr7dDcc8/34I90M5q2mirV0 hOjuiJSP6lg0Wd6Hlpn0i49TfVDqhJpV7hTAT1CPMYFOon82mEHzfkho8rmuOiatl3vd vhcjnimXrcWjLblAue3WpBowbIG4pE/rYgGyQec3ZyIWAe6QHEp1ppHrd/RTHIm4R2UP K+AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w/SmphGa5oBMXVuHBDUEZ/jgX3HoYNFOaoa/s/X1F7I=; b=QJhIHgOX1cxCjV4sRjcUYJhcVGRekWA04VJc/qrF2o3IwEH9gqlvqiMZmeQzswPqYU XosLC2eI28EnWzYUkUkws0wO9ED4DM4F35ffB84+SC/E+MupqqwAEMS46BdqVP2e0sRq R5vU7voFWTBItTsfEUVzFB/OX4d7GhKlAPCivtC3WfrEDjdrVzZr9mt4xkDK9zf/VoI8 iHt5ufRlchFvu/J28pIPXiy9cnzB/dQ843UyZXxnCc7lSehMAzCiZvkFaWLT8L/lyKov 7QLdYzBrNtuK9ctDoxSQ055PtJW1iOEQAa3GLMh3KFX9LjipnLcCXSFNK0RTGoAaZX6j on5g== X-Gm-Message-State: AKaTC03ziJ5u7y0fw3OoNlownM5Q+75+mfqpjIx6z/alYDsUNpixwzJ+8TWgAMBQd9BQo8a63LSQV82Aigxd6g== X-Received: by 10.129.125.215 with SMTP id y206mr90375480ywc.234.1481593877684; Mon, 12 Dec 2016 17:51:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Mon, 12 Dec 2016 17:50:37 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 12 Dec 2016 17:50:37 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11492dfac8245405438074a1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:51:21 -0000 --001a11492dfac8245405438074a1 Content-Type: text/plain; charset=UTF-8 On Mon, Dec 12, 2016 at 5:45 PM, Martin Thomson wrote: > On 13 December 2016 at 12:43, Nick Harper wrote: > > Right now, I believe it's legal for a client to send ClientHello, early > > data, and end_of_early_data alert without reading any messages from the > > server. This change would require a client to wait for the ServerHello > > before sending (or not) EndOfEarlyData, but that seems quite reasonable. > > It's legal to send EndOfEarlyData at any time as long as it follows > the (first) ClientHello, but you are right in observing that it would > be difficult to send it at a different time than when you are entering > it into the transcript. > The good news here is that it's empty, so you can just remember it if you need to. -Ekr > > p.s., It's the Server Finished that you have to wait for, not just > ServerHello. > --001a11492dfac8245405438074a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 12, 2016 at 5:45 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 13 December 2016 at 12:43, Nick Harper <nharper@google.com> wrote:
> Right now, I believe it's legal for a client to send ClientHello, = early
> data, and end_of_early_data alert without reading any messages from th= e
> server. This change would require a client to wait for the ServerHello=
> before sending (or not) EndOfEarlyData, but that seems quite reasonabl= e.

It's legal to send EndOfEarlyData at any time as long as it foll= ows
the (first) ClientHello, but you are right in observing that it would
be difficult to send it at a different time than when you are entering
it into the transcript.

The good news h= ere is that it's empty, so you can just remember it if you need to.

-Ekr
=C2=A0

p.s., It's the Server Finished that you have to wait for, not just Serv= erHello.

--001a11492dfac8245405438074a1-- From nobody Mon Dec 12 17:52:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D2112A039 for ; Mon, 12 Dec 2016 17:52:06 -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 q23VvQYV8Xtg for ; Mon, 12 Dec 2016 17:52:04 -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 69330129854 for ; Mon, 12 Dec 2016 17:52:02 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id q130so102601324qke.1 for ; Mon, 12 Dec 2016 17:52:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XSdh72h5jLMzWndDHkgIr9401yJI++Ss1CnGEdDheoo=; b=ZBJV5fBNGaZ/bcDdkDvWikvOSyljKtSl0GZeufdKZ75Hn6X713/pa2Fte9SKfG8cK/ mm+BN/pyvQZuA8B5xCFarLOiNTPzKgKtMmEb5TfS3ODWK6RPL6Hk6fqW5WuOUAQuL+vD ETfLNXZDa5ML0f9dmN2JaLTHq3pO9Y7TRdG0LSx6MXWN/9gbwkRtIQn4Z4cnsbBnxlNn 9xJB7qj1ruqB5WN5mNuHWseWFKYq0nHj8qB1uML7xjmoAEQx0qSlzT8L87wdv7UO36SW Re372YO/NdtyxRSbFYpL63OrDmEGExzjtqvJu0Zt5HzlzgV6p3KaBagNmsNM9p7n11Ad Ktzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XSdh72h5jLMzWndDHkgIr9401yJI++Ss1CnGEdDheoo=; b=i3fHZy2tnoemvUds3yhxP9KSHyWGOA+zuaAAnz4pexHAscuZD1eepCzf+gtWZ3Frvm Kq9N0/Q1X/145NKkxkTL45nCCEpQq/PH5Wp26EwKjrM9jOWDB4djwm7RwCx6P73O6MvS zdeW4n0WxYfM9x+jAJNFnqfTsnn6Fj2Ys5gYoX8P7wQE2NJYna+RoNfAh4HNg8VYf4E8 quKcnTeGGYVjQoZTFwAhA975Ld1g+j6DcpEIVoLuhajPyEvSYJJu2+D/Zx4anON7ujf3 6UoCg5azFGPITitCxWR16qHx53rpJ4YXi9CUwMLJdxWRsGY/08sG/6OlecnfqEMTDmPg 3gEA== X-Gm-Message-State: AKaTC021Hm9E+wX2hfLheUnII13EtqYNhr5ws59hgO2k4CUf6EQmf0bxX7K0lTYyQIgMBCP8kswA6gItASLU0w== X-Received: by 10.55.69.67 with SMTP id s64mr22227162qka.102.1481593921620; Mon, 12 Dec 2016 17:52:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.84.177 with HTTP; Mon, 12 Dec 2016 17:52:01 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Tue, 13 Dec 2016 10:52:01 +0900 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:52:06 -0000 2016-12-13 10:45 GMT+09:00 Martin Thomson : > On 13 December 2016 at 12:43, Nick Harper wrote: >> Right now, I believe it's legal for a client to send ClientHello, early >> data, and end_of_early_data alert without reading any messages from the >> server. This change would require a client to wait for the ServerHello >> before sending (or not) EndOfEarlyData, but that seems quite reasonable. > > It's legal to send EndOfEarlyData at any time as long as it follows > the (first) ClientHello, My understanding is that such action has been banned recently in https://github.com/tlswg/tls13-spec/pull/806. Picotls has been doing this (and therefore I would need to change the code). But nevertheless I support this change and the changes discussed in this thread, since it would simplify the state transition on the server side. > but you are right in observing that it would > be difficult to send it at a different time than when you are entering > it into the transcript. > > p.s., It's the Server Finished that you have to wait for, not just ServerHello. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku From nobody Mon Dec 12 17:55:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF29C1294CD for ; Mon, 12 Dec 2016 17:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, 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 tzgaXofyIpZR for ; Mon, 12 Dec 2016 17:55:01 -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 90C3D12A042 for ; Mon, 12 Dec 2016 17:55:01 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id x190so102815870qkb.0 for ; Mon, 12 Dec 2016 17:55:01 -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=wQucMXfCOKeG43FSIe7i8fPKk/GVGzpE1Rz7ICFxclI=; b=hgy7x7PBQR04G2ggzg7jfUEamZFGfUB0dEO1yXmv4JVX2ode6rRqRYSayJQCRkxymB aA2SdiyujzDBOIJbRAa9j42W02gHC5jv0o1bKIAHKEP+UfNS6ZmnlaX0Z9XgObVAJcsM AvLRbJcFPN3RmqgDe5GRAzsj6IG741W9h/aNU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wQucMXfCOKeG43FSIe7i8fPKk/GVGzpE1Rz7ICFxclI=; b=CsT4oWAIm5C/R1FwBlmRHK/zl/UYrBUGWoOnw4iI42AMIIfcJ5jA04QOr1wG/tcAzq FNCgrDODufFNYtDi3exVH8d5cv1TTNw2uQvO+fMv4+wCuxaOCpze3DBd/gZqWpXn/ay8 dhoEPj8VK93YglRkHijuXgqI1kH9HK/4BTovHh/qqZnGf01i3c+s+K610ChwQEe2OZlt 1rgPw3T18j2iqy+WNp8QuiYFLMGQ3RogJV2M9Sb3/wkzhp2CdTtYqaS58gRS4RqhXemc a12My0JbNrNCgEakkC5EiJpZtS2B32b4My2+RfTWqrjNGo1Q3kQ1ggDfl+Pt2hIj7tTr ueqw== X-Gm-Message-State: AKaTC03ygUhwALw1n8YDdhlMDzUMD2SU/avfHJcawsnNPkmnNTTboReSaUVaoXs+1/FwNXN8ySKnFHmWyMCSQaqR X-Received: by 10.55.17.143 with SMTP id 15mr94030363qkr.297.1481594100579; Mon, 12 Dec 2016 17:55:00 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Tue, 13 Dec 2016 01:54:50 +0000 Message-ID: To: Martin Thomson , Nick Harper Content-Type: multipart/alternative; boundary=001a113aca3411654c05438082cc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:55:04 -0000 --001a113aca3411654c05438082cc Content-Type: text/plain; charset=UTF-8 On Mon, Dec 12, 2016 at 8:45 PM Martin Thomson wrote: > On 13 December 2016 at 12:43, Nick Harper wrote: > > Right now, I believe it's legal for a client to send ClientHello, early > > data, and end_of_early_data alert without reading any messages from the > > server. This change would require a client to wait for the ServerHello > > before sending (or not) EndOfEarlyData, but that seems quite reasonable. > > It's legal to send EndOfEarlyData at any time as long as it follows > the (first) ClientHello, but you are right in observing that it would > be difficult to send it at a different time than when you are entering > it into the transcript. > > p.s., It's the Server Finished that you have to wait for, not just > ServerHello. > I think sending EndOfEarlyData/end_of_early_data late is desirable anyway, even if you know you won't be sending more 0-RTT data. That forces servers to get the processing order right: https://tlswg.github.io/tls13-spec/#rfc.section.4.2.8.1 If by including it in the transcript, we make it more likely that clients will send in a way that forces correct server behavior, that sounds like a good thing for the ecosystem. It also shouldn't be any more complexity for the client to send it later because the client must already have logic to change keys and send a Finished message after receiving ServerHello..Finished. The EndOfEarlyData just tacks before that (as I expect most clients would have implemented the alert version anyway). To add to the motivations: EKR mentioned end_of_early_data is the only place where we transition keys on an alert. Conversely, it's also the only alert that does not terminate the connection. (The document even currently claims end_of_early_data is a "closure alert" and signals "that the connection is ending". This is false.) David --001a113aca3411654c05438082cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Dec 12= , 2016 at 8:45 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 13 December 2016 at 12:43, Nick Harper <nharper@google.co= m> wrote:
> Right now, I believe it's legal for a client to send ClientHello, = early
> data, and end_of_early_data alert without reading any messages from th= e
> server. This change would require a client to wait for the ServerHello=
> before sending (or not) EndOfEarlyData, but that seems quite reasonabl= e.

It's legal to send EndOfEarlyData at any time as long as it follows
the (first) ClientHello, but you are right in observing that it would
be difficult to send it at a different time than when you are entering
it into the transcript.

p.s., It's the Server Finished that you have to wait for, not just Serv= erHello.

I think se= nding EndOfEarlyData/end_of_early_data late is desirable anyway, even if yo= u know you won't be sending more 0-RTT data. That forces servers to get= the processing order right:

If by including it in the transcr= ipt, we make it more likely that clients will send in a way that forces cor= rect server behavior, that sounds like a good thing for the ecosystem.

It also shouldn't be any more complexity for the c= lient to send it later because the client must already have logic to change= keys and send a Finished message after receiving ServerHello..Finished. Th= e EndOfEarlyData just tacks before that (as I expect most clients would hav= e implemented the alert version anyway).

To add to= the motivations: EKR mentioned end_of_early_data is the only place where w= e transition keys on an alert. Conversely, it's also the only alert tha= t does not terminate the connection. (The document even currently claims en= d_of_early_data is a "closure alert" and signals "that the c= onnection is ending". This is false.)

David
=C2=A0
--001a113aca3411654c05438082cc-- From nobody Mon Dec 12 17:57:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37AB0129509 for ; Mon, 12 Dec 2016 17:57: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 QMzHBv1_ulTy for ; Mon, 12 Dec 2016 17:57:38 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6D5129522 for ; Mon, 12 Dec 2016 17:57:37 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id t125so75740710ywc.1 for ; Mon, 12 Dec 2016 17:57: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=MOxLVlfaOvqJS1v6ziP4+aDDhEWUO6fA9Yx2ccYSWkk=; b=Dz6CmQl1jqRbIR7gb1pafDMYsMUW0jq8hHO5eCGWEuQxEDrV8oBhm9XLTQVSkGOKK4 FH24IPHK7H7E7xSrXNTDB3eeB79wW0WNrnb5fCRdbM1jzseIU5UXVNwh63sOWkLpPkFV MjCTGm49In3cvfCLgLGol2O8hjWNG0iwXocMTbCsI46nHO1wsHVrWLAisy9iH1ZalHn9 lxzoSy7hbEbVu/Rnyd2s73l+JW1cARcCYbYyF7j6R6xsgQlejfmFi4pn7Csn+JKpkSOB 7I4JsjvtRET6BFWFPW6e98PndrWeGm3pvtMxxjj85tff55w+qAJcScELPnPzOMI8IiKe BNfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MOxLVlfaOvqJS1v6ziP4+aDDhEWUO6fA9Yx2ccYSWkk=; b=FfOZoqoRfvl5b93x4g4bu1PnbC9HRYeGOGmb7xFQlnUSSXM8+IQ+U+yuTwtdKkLpNN egfEDvHyVxZP3z3lD8nf10jKXNoZJfXxma/rcKwLoFkFeb4dslegFgQHFfdv9qcVSUtL 9cqd8LvlYh3RtqCP/fRaz3rDZdHiuNawmYxZeJvpGgm1CVpttMdjXyO9+rzOKQyJCbn0 3+z0xgYYngVS7MKuNJAJReHfQ5bHG99pLEzGCtCnumDkrwQaWsFV5UxjXcMVBfNI8oT8 UNuCeOvXHRgv2q5jOjFL9jy0Vv/kzsrww54XiIlHhaWFMr/2uhE81nW0E1FZ2CHVKo7B S87g== X-Gm-Message-State: AKaTC018CbCRZhM6+6VVR9Ah6krnMHGpohvyIK+FbkgTqKv6yrxJouwcnV6Maptr9rzonXMxOUOgeZns/x4abg== X-Received: by 10.129.108.216 with SMTP id h207mr93825276ywc.52.1481594257055; Mon, 12 Dec 2016 17:57:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Mon, 12 Dec 2016 17:56:56 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 12 Dec 2016 17:56:56 -0800 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a114dd36e64c5ce0543808bdc Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#812: End Of Early Data as handshake X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 01:57:40 -0000 --001a114dd36e64c5ce0543808bdc Content-Type: text/plain; charset=UTF-8 On Mon, Dec 12, 2016 at 5:54 PM, David Benjamin wrote: > On Mon, Dec 12, 2016 at 8:45 PM Martin Thomson > wrote: > >> On 13 December 2016 at 12:43, Nick Harper wrote: >> > Right now, I believe it's legal for a client to send ClientHello, early >> > data, and end_of_early_data alert without reading any messages from the >> > server. This change would require a client to wait for the ServerHello >> > before sending (or not) EndOfEarlyData, but that seems quite reasonable. >> >> It's legal to send EndOfEarlyData at any time as long as it follows >> the (first) ClientHello, but you are right in observing that it would >> be difficult to send it at a different time than when you are entering >> it into the transcript. >> >> p.s., It's the Server Finished that you have to wait for, not just >> ServerHello. >> > > I think sending EndOfEarlyData/end_of_early_data late is desirable > anyway, even if you know you won't be sending more 0-RTT data. That forces > servers to get the processing order right: > https://tlswg.github.io/tls13-spec/#rfc.section.4.2.8.1 > > If by including it in the transcript, we make it more likely that clients > will send in a way that forces correct server behavior, that sounds like a > good thing for the ecosystem. > > It also shouldn't be any more complexity for the client to send it later > because the client must already have logic to change keys and send a > Finished message after receiving ServerHello..Finished. The EndOfEarlyData > just tacks before that (as I expect most clients would have implemented the > alert version anyway). > FWIW, this is how NSS behaves. -Ekr > > To add to the motivations: EKR mentioned end_of_early_data is the only > place where we transition keys on an alert. Conversely, it's also the only > alert that does not terminate the connection. (The document even currently > claims end_of_early_data is a "closure alert" and signals "that the > connection is ending". This is false.) > > David > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114dd36e64c5ce0543808bdc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Dec 12, 2016 at 5:54 PM, David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
On Mo= n, Dec 12, 2016 at 8:45 PM Martin Thomson <martin.thomson@gmail.com> wrote:
On 13 December 2016 at 12:43, Nick Ha= rper <nharper@google.com> wrote:
> Right now, I believe it's legal for a client to send ClientHello, = early
> data, and end_of_early_data alert without reading any messages from th= e
> server. This change would require a client to wait for the ServerHello=
> before sending (or not) EndOfEarlyData, but that seems quite reasonabl= e.

It's legal to send EndOfEarlyData at any time as long as it follows
the (first) ClientHello, but you are right in observing that it would
be difficult to send it at a different time than when you are entering
it into the transcript.

p.s., It's the Server Finished that you have to wait for, not just Serv= erHello.

=
I think sending EndOfEarlyData/end_of_early_dat= a late is desirable anyway, even if you know you won't be sending more = 0-RTT data. That forces servers to get the processing order right:
https://tlswg.github.io/tls13-spec/#rfc.section.4.2.8.1


FWIW, this is how NSS behaves.


--001a114dd36e64c5ce0543808bdc-- From nobody Tue Dec 13 03:47:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE1031295D2 for ; Tue, 13 Dec 2016 03:47:34 -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 kv8bEz_1cQI1 for ; Tue, 13 Dec 2016 03:47:33 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C58091295D0 for ; Tue, 13 Dec 2016 03:47:32 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id f82so116307854wmf.1 for ; Tue, 13 Dec 2016 03:47:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=FGV618wRPKSLOm1kuxokocIAx5tuWH+BZCYyvyr50TA=; b=tvGwJjiitGnZ3jplKiC6amxBKJBHIWKBzsbcoocCBJ4nEGk3QTHqwFyknc8EXxAOSI ssahR9HAXBLpIZ5JVOx41gpSIcfdUcYNZfSjZIMci+nK5P1IIiN2buYPSeHse54D3VRi BGR4sKzMFDnQ6GasgYllK8fPThALu6FAmSlIRIknLaiGpP1PbOxC2iBY0VVC/RDTxbGl h/kLA0waqs27c9e5i9LsGzIwjMGoYyhlyLh8W8yevCrxB87VI0H7x4BDIjTraEV1QewK zSKDeTsp75vz2PzDfWSpqAb1xxtLLTFPLgQgHGfeiT556NC2Bu5anOosFRiQbYrdWn5+ 6ZHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=FGV618wRPKSLOm1kuxokocIAx5tuWH+BZCYyvyr50TA=; b=jSI//Jm/106K58KLIx++3wOl97nv3j0ImvpFKQIUZKVfdO28ToinKoWyeyNwuWxWMc 2Meor+iQHpGblH89HNM52MUY/SXJ8DlhCOxr5JaG4mLRAZFycugePG0xCJsLeNjgCQht QG/GNh79w/4dfYhWTLiRuRhDzbSKMaG76JDNFgs0rB8Z/Y6b2dqe9vq8AhZg3WwBg79O 99CQzlvjxAdEC2OocwuAKN+DhzBVMdtqSux/7baMpzG1ZrwiY6q9QX6Qc6JMmQSo6KHJ k+TBE+rlfsWjyG1ZwMcG8Y5+acRs16IxVs0ni9XUneWx3kN2tAoFFYqGGHYmWjwCEVhr MwQw== X-Gm-Message-State: AKaTC01jXaj2VZdjAhXXB6bNDPrC/qgBvcunVpGl0ooqVr9l3ZOupHIjd5NnB7TF8R9z0Q== X-Received: by 10.28.225.138 with SMTP id y132mr2223977wmg.52.1481629650970; Tue, 13 Dec 2016 03:47:30 -0800 (PST) Received: from [172.24.248.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 197sm2214299wmy.16.2016.12.13.03.47.29 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 03:47:30 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Tue, 13 Dec 2016 13:47:28 +0200 To: "" X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [TLS] Harmonizing 4492bis with TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 11:47:35 -0000 Hi One issue that came up during WGLC for 4492bis is the way EdDSA = signatures are mentioned in SignatureAndHashAlgorithm and in In TLS 1.2 and 4492bis we have a SignatureAndHashAlgorithm struct with = one byte for hash algorithm and another for signature algorithm.. The = HashAlgorithm can be None(0), sha1(2), and a few more going up to = sha512(6). The SignatureAlgorithm can be anon(0), rsa(1), dsa(2), and = ecdsa(3). 4492bis adds a new value to SignatureAlgorithm for EdDSA = (TBD5). Additionally, 4492bis requests two new NamedCurve values for ed25519 and = ed448. 4492bis requires to use the None(0) HashAlgorithm with EdDSA. So to = declare support for both curves of EdDSA, you=E2=80=99re expected to = have (0x00,TBD5) in signature_algorithms and both new curves in = elliptic_curves. TLS 1.3 replaces the signature_algorithms internal structure with a = simple list of 16-bit values, but the old values are kept. So RSA with = SHA1 is now 0x0201 instead of (0x02,0x01). However, for EdDSA the draft = assigns two values: 0x0807 for Ed25519 and 0x0808 for Ed448. Bringing = that back to the TLS 1.2 structure, it would mean that 0x08 is a new = hash algorithm (that doesn=E2=80=99t really do anything) and 0x07 and = 0x08 are two distinct signature algorithms (rather than the same = algorithm, but with different curves). So four options here: 1. Leave it as its current inconsistent state 2. Change 4492bis:=20 a. no new curves for ed25519 and ed448. b. Two new signature algorithms, and request values 7 and 8 for = them. c. new hash algorithm 0x08 and call it something like = =E2=80=9Cintrinsic=E2=80=9D=20 3. Change TLS 1.3, by using 0x0007 for both EdDSA signature_algorithms = and add two values to supported_groups. 4. A hybrid of 2 & 3:=20 a. No new curves for 4492bis b. Two new signature algorithms with values 0x07 and 0x08 c. TLS 1.3 will modify the values to 0x0007 and 0x0008 There may be more options possible What do people think? Yoav From nobody Tue Dec 13 03:54:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C0FE1295D7 for ; Tue, 13 Dec 2016 03:54:43 -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 1_8vOFiGzpwa for ; Tue, 13 Dec 2016 03:54:41 -0800 (PST) Received: from mail-wj0-x22f.google.com (mail-wj0-x22f.google.com [IPv6:2a00:1450:400c:c01::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 D2DC31295EC for ; Tue, 13 Dec 2016 03:54:36 -0800 (PST) Received: by mail-wj0-x22f.google.com with SMTP id tg4so98353127wjb.1 for ; Tue, 13 Dec 2016 03:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:mime-version:subject:message-id:date:to; bh=Qcp+CiCXRoIe/OaNgX6r76byfpOSVCFVMpEZ8IeCuCg=; b=t8qGb/QxyAkMuX3+VxU775GMQl5Mn6dl5ddaA3Vp9gQTF+vw97H+g2VvY7kJqGr7B1 0snl/Ae4aUeb6XApoJHrPeREkdkTOCM1q9B1D4+nAzm6KZDK0fX752Q4vooCOPszqrnI CjTYQ1gbZ1SmnEv+cFFZGZv/Imlk5eWAIuiuhptAY4SVN1l8rLQoxE7MSfN8jYM9bAj+ oWGYjtSu+ZRyd7o6bTldlDoNTK9fWzDZMIro/n2bS/g1QwFsv/gqrkKFCbaVGCsZEaLz Oxjttq8A9fLUyqDcQlVruq8Z+Q5rpWeSBjkrNqjUZZcKDUTVwwbCsbklEex6txiO+4JG QaIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=Qcp+CiCXRoIe/OaNgX6r76byfpOSVCFVMpEZ8IeCuCg=; b=Tz/iGcCnrOhsrXt/U+AO6b1Os+MYQ93nm+Cq1PtMdIvcIY+3s6L06bBueaiHtng8Bn e8J/caUhgIevbNY8JNlNnBewutuUxiDGKZ1EBwdCvIRe+sl2YPqHm57S9T9UvJCe7o75 AVjDZO1XlehSNU/1Y4e0LD/dLmC/5N9E4IcGm46OLaoflh74Sj9/RzfjA+sGzNmXWtU9 7UcaEOol/nVgkpVt8owv3Y54NQpYE5m5Y4vB94gZG5xDrmWfIKdVLJlXrWnffzoBkRBP JmkqWWIPJbCSdiAETn6aFKlB5XkoF81RKZ9NsImYtJxWPfC4LcYDQELeJv+n2/kEf6bk 167A== X-Gm-Message-State: AKaTC03SBVimXIZQXrgxlVpujinWLp3PT1C4G4RgTQS71QMNvsWZSJibfwCg/XC7/3QbsQ== X-Received: by 10.194.114.10 with SMTP id jc10mr54136977wjb.157.1481630075135; Tue, 13 Dec 2016 03:54:35 -0800 (PST) Received: from [172.24.248.177] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id vr9sm61834703wjc.35.2016.12.13.03.54.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 03:54:34 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_88EF2B01-DFE4-45BB-AC3F-CD199BA4DBF5" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: <99775313-61C4-4F91-A97D-095381E552AB@gmail.com> Date: Tue, 13 Dec 2016 13:54:32 +0200 To: "" X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [TLS] Pull Request #26 for RFC4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 11:54:43 -0000 --Apple-Mail=_88EF2B01-DFE4-45BB-AC3F-CD199BA4DBF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 As Sean suggested, this PR removes two paragraphs from the Introduction = section. They=E2=80=99re no longer needed in our opinion. https://github.com/tlswg/rfc4492bis/pull/26 = If no objections are heard, I will merge this over the weekend. Yoav --Apple-Mail=_88EF2B01-DFE4-45BB-AC3F-CD199BA4DBF5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 As Sean suggested, this PR removes two paragraphs from the = Introduction section. They=E2=80=99re no longer needed in our = opinion.

https://github.com/tlswg/rfc4492bis/pull/26

If no objections are = heard, I will merge this over the weekend.

Yoav

= --Apple-Mail=_88EF2B01-DFE4-45BB-AC3F-CD199BA4DBF5-- From nobody Tue Dec 13 04:15:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A1F129632 for ; Tue, 13 Dec 2016 04:15:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.796 X-Spam-Level: X-Spam-Status: No, score=-4.796 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-2.896] 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 6IhsteIKhniM for ; Tue, 13 Dec 2016 04:15:03 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 1B935129607 for ; Tue, 13 Dec 2016 04:15:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 166F114C92; Tue, 13 Dec 2016 14:15:02 +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 JCkEEXTnAOzU; Tue, 13 Dec 2016 14:15:01 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id C67202315; Tue, 13 Dec 2016 14:15:01 +0200 (EET) Date: Tue, 13 Dec 2016 14:14:53 +0200 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20161213121453.GB7405@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] Harmonizing 4492bis with TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 12:15:09 -0000 On Tue, Dec 13, 2016 at 01:47:28PM +0200, Yoav Nir wrote: > Hi > > 1. Leave it as its current inconsistent state > 2. Change 4492bis: > a. no new curves for ed25519 and ed448. > b. Two new signature algorithms, and request values 7 and 8 for them. > c. new hash algorithm 0x08 and call it something like “intrinsic†> 3. Change TLS 1.3, by using 0x0007 for both EdDSA signature_algorithms and add two values to supported_groups. > 4. A hybrid of 2 & 3: > a. No new curves for 4492bis > b. Two new signature algorithms with values 0x07 and 0x08 > c. TLS 1.3 will modify the values to 0x0007 and 0x0008 > > There may be more options possible > > What do people think? I would prefer backporting TLS 1.3 methods, i.e. option 2. In fact, that is what TLS library (btls) I have written does (it recognizes 0807 and 0808 even in TLS 1.2 and attempts to verify the signature). -Ilari From nobody Tue Dec 13 04:45:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7B73129677 for ; Tue, 13 Dec 2016 04:45:03 -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 wFghXN1Fn3_E for ; Tue, 13 Dec 2016 04:45:02 -0800 (PST) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 165E0129674 for ; Tue, 13 Dec 2016 04:45:02 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id v132so13189273yba.0 for ; Tue, 13 Dec 2016 04:45:02 -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=IVGzXp60VMVeamq8USXeiMllF6v3JMJ5dY05GpL0SQA=; b=Fa1bNQ2Cs4fcr5vPRr2V1vwcoFOALqYLQs614z2vJN46kNPuze0nGMFdc4zce2enaL K1Rs/SGuaHCIr4KADqulNAbwsUTwfb9p9vFSOB5IaZfwOyonpUHRniWqWMql6Kv35Uvv ac7lENag6yrLw97cP/Ge1GSzD3KvH5AJx3bMfWWdydZQF0a7C79GTKgQBS8iIsMF1rhb LJ/SPdRT2Grbu92lvtzU/JYA2ryxOQs9jf41oKImRSyIrYpufKp+ijhOuuLnrUFqiBoi J5+RB8dgMKNmOPSPP5h2AC617j2tGRcZoLFj68FoiofSWzH6oTBt8ENyM6OM/4HSSiis 7aFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IVGzXp60VMVeamq8USXeiMllF6v3JMJ5dY05GpL0SQA=; b=Z/aP1lP8hJQWjs8v//vrKFMuio+zo5UKEdBtLe4o3LzRuiOVCv88NrQEoNmpysr8EP pAo2d/txVRixUAdShaF+8HdFEUiHW/Hh8KaDvPrUHZbIV7R6jEos7fb2Gcxb1BkqbZl6 XAEuoSqQ1oK85MFDp6L5Ce2DnAjKovLmNpZ9SpBsiNme76ApvvS5XetUQWH+7jVYApzt zBdAbC0Kx51Zm7aVkjn6Prhu3lXcjnAbLMAN8CdArO4NNhHQA6ZDbTveffG8HyjGVNfS 1jHMjAJqAr4P6KJrj4qm+JZsyOmwZMzC+Lb4epZXkI+AFBeOJCvvsrk8Umt/8HAKZGDD 6Ftg== X-Gm-Message-State: AKaTC02e42Y8HypO4N7gJ0zWM/uOplkPvJ7obSXiVAElpwMWCJ52dkPJqjh0UmNOTyGkz6RmEJNEv4n0R8b4vw== X-Received: by 10.129.125.215 with SMTP id y206mr92032763ywc.234.1481633101166; Tue, 13 Dec 2016 04:45:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Tue, 13 Dec 2016 04:44:20 -0800 (PST) From: Eric Rescorla Date: Tue, 13 Dec 2016 04:44:20 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11492dfaaee8fc05438996a3 Archived-At: Subject: [TLS] PR#818: Consolidate "early_data" and "ticket_early_data_info" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 12:45:03 -0000 --001a11492dfaaee8fc05438996a3 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/818 Steven Valdez and David Benjamin pointed out that now that we had one code point space we only needed one code point. Target merge date: Thursday -Ekr --001a11492dfaaee8fc05438996a3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
h= ttps://github.com/tlswg/tls13-spec/pull/818

Steven V= aldez and David Benjamin pointed out that now that we had one code point
space we only needed one code point.

Targe= t merge date: Thursday

-Ekr

--001a11492dfaaee8fc05438996a3-- From nobody Tue Dec 13 05:44:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C33B1296CB for ; Tue, 13 Dec 2016 05:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.098 X-Spam-Level: X-Spam-Status: No, score=-107.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 mx0NsQqBfzLh for ; Tue, 13 Dec 2016 05:44:55 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D58E128824 for ; Tue, 13 Dec 2016 05:44:55 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id F10CEB80241; Tue, 13 Dec 2016 05:44:54 -0800 (PST) To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, sean+ietf@sn3rd.com, joe@salowey.net X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161213134454.F10CEB80241@rfc-editor.org> Date: Tue, 13 Dec 2016 05:44:54 -0800 (PST) Archived-At: Cc: wy@fajrrd.com, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Editorial Errata Reported] RFC5246 (4885) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 13:44:56 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4885 -------------------------------------- Type: Editorial Reported by: Wail Yahyaoui Section: 6.1. Original Text ------------- server random A 32-byte value provided by the server. These parameters are defined in the presentation language as: enum { server, client } ConnectionEnd; Corrected Text -------------- server random A 32-byte value provided by the server. These parameters are defined in the presentation language as: enum { server, client } ConnectionEnd; Notes ----- The line "These parameters are ..." after the list of parameters is at the same indentation level as the list of parameters, instead of coming back left by one level. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Dec 13 06:54:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D26AE129B40 for ; Tue, 13 Dec 2016 06:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.296 X-Spam-Level: X-Spam-Status: No, score=-4.296 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.896] 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 gZgbfIuGbBuF for ; Tue, 13 Dec 2016 06:54:36 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 17586129ABB for ; Tue, 13 Dec 2016 06:54:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 2C2491A50B; Tue, 13 Dec 2016 16:54:35 +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 A1JOkdt4ImUP; Tue, 13 Dec 2016 16:54:34 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id A2A9921C; Tue, 13 Dec 2016 16:54:34 +0200 (EET) Date: Tue, 13 Dec 2016 16:54:26 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161213145426.GC7405@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#818: Consolidate "early_data" and "ticket_early_data_info" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 14:54:39 -0000 On Tue, Dec 13, 2016 at 04:44:20AM -0800, Eric Rescorla wrote: > https://github.com/tlswg/tls13-spec/pull/818 > > Steven Valdez and David Benjamin pointed out that now that we had one code > point > space we only needed one code point. > > Target merge date: Thursday > The structure definition has a case for hello_retry_request. Shouldn't that be encrypted_extensions? -Ilari From nobody Tue Dec 13 07:09:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A4F129B72 for ; Tue, 13 Dec 2016 07:09:52 -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 NMLa_vT1gEhY for ; Tue, 13 Dec 2016 07:09:50 -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 3DA50129B74 for ; Tue, 13 Dec 2016 07:09:37 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id v132so16535903yba.0 for ; Tue, 13 Dec 2016 07:09: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=oYeAOdCCBV1bV5E1Dow5Vo04tiv+B4yR/UmARR8KS6E=; b=FVUlmYhBAMjP1oVgYolyTFDeaxgpLPxclQLa+AtYFvz4DhoQemEMYuco3vjexST6KA y1W8afquCyLLKXti1lhKWIJAGYnhrv7Hf9s65qohc8HMOyBgvNnIYEtHQH73msuGUzZf 4S1FNsG/eOT4Yzn/Ot48/035qE7AsQiFnRpwDLviE9SmgbcZlkHExhbAfQX98gvFE+oG i7zv3rBj/witgzSePJzL3SVqqLnyymKFpRa2Jr8mepGdFfWOErUuiZnwp+Isl8PSX+qv Nqrh9/DeDin8bRNf8lXYtoM6QcCgoCk5JFvPijSY/IqDaIx+77FNum8VykcpCpMXNGc+ a4cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oYeAOdCCBV1bV5E1Dow5Vo04tiv+B4yR/UmARR8KS6E=; b=iSbQX+8iViIwnuUCf67nrcBzNtN26GDAgkwgU3hL5NCiwIlIWvj8wCd9iiTSTfVKRJ 7Z2uorWLDm805/rltUebKkK3C9mkk5UovFyq7hw1acTzIJ6N5D5y/Xou4YVUbHfzDIPi jDFoR6EEgWu/ulHXfs3FLZ1t+tkor2avYUpP4vXZgkNOhZAjOFbeOAPd+hKEvBrS1U3H Lhl1AOsrWQGCml/grQ0vzsvxJjwzpRE1jb6OTcQllGh4pf2hDvA/aO8a/82Oipmix1+T nR2e/YUBPJClI/M3/LjBio1b9UXSnhvnEWk+MaYk0IjIttza22bAaKiADeCV8CjfG239 KJBg== X-Gm-Message-State: AKaTC03hkCg7xbcEjpKWQOqhmjPx1ElG06suUCXOmLrfMltu0okkTkxTgNfd0/1ybOABlL289qdlC8ZvBw65TQ== X-Received: by 10.129.78.71 with SMTP id c68mr94307377ywb.21.1481641776442; Tue, 13 Dec 2016 07:09:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Tue, 13 Dec 2016 07:08:55 -0800 (PST) In-Reply-To: <20161213145426.GC7405@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161213145426.GC7405@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 13 Dec 2016 07:08:55 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114dac9cc54f8005438b9b5b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PR#818: Consolidate "early_data" and "ticket_early_data_info" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 15:09:52 -0000 --001a114dac9cc54f8005438b9b5b Content-Type: text/plain; charset=UTF-8 Yes. From now on I will try to drink coffee before posting PRs. On Tue, Dec 13, 2016 at 6:54 AM, Ilari Liusvaara wrote: > On Tue, Dec 13, 2016 at 04:44:20AM -0800, Eric Rescorla wrote: > > https://github.com/tlswg/tls13-spec/pull/818 > > > > Steven Valdez and David Benjamin pointed out that now that we had one > code > > point > > space we only needed one code point. > > > > Target merge date: Thursday > > > > The structure definition has a case for hello_retry_request. Shouldn't > that be encrypted_extensions? > > > -Ilari > --001a114dac9cc54f8005438b9b5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yes. From now on I will try to drink coffee before posting= PRs.

On Tue= , Dec 13, 2016 at 6:54 AM, Ilari Liusvaara <ilariliusvaara@welho.co= m> wrote:
= On Tue, Dec 13, 2016 at 04:44:20AM -0800, Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/pull/818
>
> Steven Valdez and David Benjamin pointed out that now that we had one = code
> point
> space we only needed one code point.
>
> Target merge date: Thursday
>

The structure definition has a case for hello_retry_request. Shouldn= 't
that be encrypted_extensions?


-Ilari

--001a114dac9cc54f8005438b9b5b-- From nobody Tue Dec 13 13:37:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788A3129B5D for ; Tue, 13 Dec 2016 13:37:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibjmKjQGKySF for ; Tue, 13 Dec 2016 13:37:43 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 9585B129978 for ; Tue, 13 Dec 2016 13:37:34 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 27CCE43341C for ; Tue, 13 Dec 2016 21:37:34 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 117C6433401 for ; Tue, 13 Dec 2016 21:37:34 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1481665054; bh=7uaXT5wk/MMsw4kbs14FGEH0/nQcSVIWxBHg5aQrZok=; l=2342; h=To:From:Date:From; b=KzwGOD786sqphjxOc7eEBKNX+qCJWRU3rPde172fc+2eLpxhwcYKSXpoRLf29ntBG 8XBP7nzB0Ca4r/a+/6+2u5lLMiptF3AL2vK7mYMVrE34l6XU/OvCsYJwVTL9/FwdPq A4/3gPveRKHeI8LlGDk2/pYz3RZzQPlzh4uQTOK0= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id E76491FC92 for ; Tue, 13 Dec 2016 21:37:33 +0000 (GMT) To: "" From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <3878b60e-5ddd-f668-5ff8-5042bc7d9118@akamai.com> Date: Tue, 13 Dec 2016 15:37:33 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------3E3972A0A5FAE614255ECE49" Archived-At: Subject: [TLS] post-handshake auth: multiple CertificateRequests, fewer replies? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 21:37:44 -0000 This is a multi-part message in MIME format. --------------3E3972A0A5FAE614255ECE49 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit 4.5.2 Post-Handshake Authentication notes that if a client receives multiple CertificateRequests, it can reply to them in a different order than they were received. By my reading of the text, the client is still "obligated" to respond to all of them (but the server has to be able to receive an arbitrary number of messages before it gets back the response, so it's kind-of a weak obligation). Would we want to weaken the restriction so that the client is only obligated to reply to at least one, similarly to how a peer can coalesce multiple KeyUpdate requests? I understand that the setup is somewhat different, since the CertificateRequest comes with a context and could correspond to different application-level needs, but it seemed worth mentioning, since as we have discussed before generating the Finished message comes with some burden of handshake buffering/hash forking/etc. -Ben --------------3E3972A0A5FAE614255ECE49 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 4.5.2 Post-Handshake Authentication notes that if a client receives multiple CertificateRequests, it can reply to them in a different order than they were received.  By my reading of the text, the client is still "obligated" to respond to all of them (but the server has to be able to receive an arbitrary number of messages before it gets back the response, so it's kind-of a weak obligation).  Would we want to weaken the restriction so that the client is only obligated to reply to at least one, similarly to how a peer can coalesce multiple KeyUpdate requests?  I understand that the setup is somewhat different, since the CertificateRequest comes with a context and could correspond to different application-level needs, but it seemed worth mentioning, since as we have discussed before generating the Finished message comes with some burden of handshake buffering/hash forking/etc.

-Ben
 --------------3E3972A0A5FAE614255ECE49-- From nobody Tue Dec 13 14:37:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5423A129BD2 for ; Tue, 13 Dec 2016 14:37:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.595 X-Spam-Level: X-Spam-Status: No, score=-5.595 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, 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 ZryzQdLJq0Sw for ; Tue, 13 Dec 2016 14:37:18 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30862129C25 for ; Tue, 13 Dec 2016 14:37:16 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id n204so1492725qke.2 for ; Tue, 13 Dec 2016 14:37:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=dgFS8c0hT5K6rtw//wpJHsK52hnHNklu+iTdVzoBuj8=; b=RMbvNDB8QNfYPzFunnZCzyxqWXjQ6WHu5BZjtCT3Ta6GD7OCSeP2ykKp2HdnzMTUPa ObhLzHlYjhiaIhz2bl1yE836J4Rr6kVTROo/sKz9/XBxIbzRUP8mDkav6cLH2G7XTsV7 NCdMwPqLk8tg4hfbkHolX8R4qP7yv62uv/tnQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=dgFS8c0hT5K6rtw//wpJHsK52hnHNklu+iTdVzoBuj8=; b=VjJlJO48ZTj2SoY9cgABo/0U3GfvHeWkBBhsDDlA2dj4hTMwnx01QDvQTzmUxdOrTI qVugucetbzLYUC+4kdrxnVT8D3iOoq8XnQ0ppuyQnfgyEHkGDaQqidvPUduYi+Iu9Lip MqKJ1gfZe88e30K0FvV4BFe5cO80E5PUfidLG+Cx7Vdk9elgeiJMnBhCFEqN404YgY6G qAimRphcMsNOMnPP9T9J6lQdK3kXZCB2xMMu/8xgRyIeXP8rnCTOFnx6s5qdtWqg8fiY qI7UWNLubT7DZTna6odEPz+5K8wZvZabbkcweBKkzunQSOiti2c6YEODeP/t7N/PVpyp eOyw== X-Gm-Message-State: AKaTC00LvIvJeZSGRshKtp17LcyZKvX27qccWiMaAV1VyZ4bqyXcMMAEWIJkMeDJoSvXyiQr8bS95DT+tYbaUbDk X-Received: by 10.55.17.143 with SMTP id 15mr97903585qkr.297.1481668635108; Tue, 13 Dec 2016 14:37:15 -0800 (PST) MIME-Version: 1.0 References: <3878b60e-5ddd-f668-5ff8-5042bc7d9118@akamai.com> In-Reply-To: <3878b60e-5ddd-f668-5ff8-5042bc7d9118@akamai.com> From: David Benjamin Date: Tue, 13 Dec 2016 22:37:04 +0000 Message-ID: To: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary=001a113aca34ac2102054391dc37 Archived-At: Subject: Re: [TLS] post-handshake auth: multiple CertificateRequests, fewer replies? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Dec 2016 22:37:21 -0000 --001a113aca34ac2102054391dc37 Content-Type: text/plain; charset=UTF-8 Our implementation considers all post-handshake CertificateRequests to be a fatal error to avoid this. We would do the same even with this proposal; it's an unnecessary complexity (which translates to security risk). If the protocol is such that the client will always bulk-disavow a burst of unexpected CertificateRequests, the server shouldn't have sent them. This was the motivation for wanting it controlled by application profile ( https://github.com/tlswg/tls13-spec/pull/680) and also our general dislike of this feature. It's the sort of thing where semantics are very application-specific and thus belongs in the application protocol, not TLS. Alas, since HTTP/1.1 lacks a nice place to inject this, post-handshake auth is needed to match the legacy renegotiation hack. But, with an application protocol, we can make nice protocol-specific simplifying assumptions and cut out all the pointless cases full generality forces a receiver to tolerate. For instance, in (unpipelined) HTTP/1.1: 1. A client first writes its entire HTTP request, then it tries to read the HTTP response. 2. The server reads the HTTP request. If it decides it needs client auth, it buffers the entire request and sends CertificateRequest. It then tries to read the client Certificate..Finished before sending any part of the HTTP response. 3. The client reads a CertificateRequest and considers it in response to this HTTP request. 4. The client picks a client certificate and sends Certificate..Finished. It goes back to reading the HTTP response. 5. The server reads this, checks it, and, if satisfied, sends the HTTP response. 6. Any deviation from this exact flow is an unexpected post-handshake message thus a protocol error. This includes: * Server sending CertificateRequest mid-response body. * Server sending 1,000 CertificateRequests when there's no HTTP request on the pipe. [Although this'll just read as being in response to the next HTTP request.] * Client sending application data sent between the HTTP request and Certificate..Finished. * Client sending application data between Certificate and CertificateVerify. * Client sending Certificate..Finished mid POST body. The key here is "unexpected" is an application-specific idea. For most applications, everything is unexpected and thus should be the default. For applications that use this, "unexpected" is more complex. In other words, you should think of post-handshake auth not as a thing the TLS stack processes, but as an extra dimension of complexity in the TLS <-> application substrate. Just as application data record HTTP/1.1 syntax error is protocol error, so should a CertificateRequest with HTTP/1.1 post-handshake-auth "syntax error". David On Tue, Dec 13, 2016 at 4:37 PM Benjamin Kaduk wrote: > 4.5.2 Post-Handshake Authentication notes that if a client receives > multiple CertificateRequests, it can reply to them in a different order > than they were received. By my reading of the text, the client is still > "obligated" to respond to all of them (but the server has to be able to > receive an arbitrary number of messages before it gets back the response, > so it's kind-of a weak obligation). Would we want to weaken the > restriction so that the client is only obligated to reply to at least one, > similarly to how a peer can coalesce multiple KeyUpdate requests? I > understand that the setup is somewhat different, since the > CertificateRequest comes with a context and could correspond to different > application-level needs, but it seemed worth mentioning, since as we have > discussed before generating the Finished message comes with some burden of > handshake buffering/hash forking/etc. > > -Ben > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113aca34ac2102054391dc37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Our implementation considers all post-handshake Certi= ficateRequests to be a fatal error to avoid this. We would do the same even= with this proposal; it's an unnecessary complexity (which translates t= o security risk). If the protocol is such that the client will always bulk-= disavow a burst of unexpected CertificateRequests, the server shouldn't= have sent them.

This was the motivation for wanting it= controlled by application profile (https://github.com/tlswg/tls13-spec/pull/680) and als= o our general dislike of this feature. It's the sort of thing where sem= antics are very application-specific and thus belongs in the application pr= otocol, not TLS.

Alas, since HTTP/1.1 lacks a nice place= to inject this, post-handshake auth is needed to match the legacy renegoti= ation hack. But, with an application protocol, we can make nice protocol-sp= ecific simplifying assumptions and cut out all the pointless cases full gen= erality forces a receiver to tolerate.

For instanc= e, in (unpipelined) HTTP/1.1:

1. A client first wri= tes its entire HTTP request, then it tries to read the HTTP response.
=
2. The server reads the HTTP request. If it decides it needs client au= th, it buffers the entire request and sends CertificateRequest. It then tri= es to read the client Certificate..Finished before sending any part of the = HTTP response.
3. The client reads a CertificateRequest and consi= ders it in response to this HTTP request.
4. The client picks a c= lient certificate and sends Certificate..Finished. It goes back to reading = the HTTP response.
5. The server reads this, checks it, and, if s= atisfied, sends the HTTP response.
6. Any deviation from thi= s exact flow is an unexpected post-handshake message thus a protocol error.= This includes:
=C2=A0 * Server sending CertificateRequest mid-re= sponse body.
=C2=A0 * Server sending 1,000 CertificateRequests wh= en there's no HTTP request on the pipe. [Although this'll just read= as being in response to the next HTTP request.]
=C2=A0 * Client = sending application data sent between the HTTP request and Certificate..Fin= ished.
=C2=A0 * Client sending application data between Certifica= te and CertificateVerify.
=C2=A0 * Client sending Certificate..Fi= nished mid POST body.

The key here is "= unexpected" is an application-specific idea. For most applications, ev= erything is unexpected and thus should be the default. For applications=C2= =A0that use this, "unexpected" is more complex.

In other words, you should think of post-handshake auth not as a th= ing the TLS stack processes, but as an extra dimension of complexity in the= TLS <-> application substrate. Just as application data record HTTP/= 1.1 syntax error is protocol error, so should a CertificateRequest with HTT= P/1.1 post-handshake-auth "syntax error".

David

= On Tue, Dec 13, 2016 at 4:37 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20
4.5.2 Post-Handshake Authentication notes that = if a client receives multiple CertificateRequests, it can reply to them in a different order than they were received.=C2=A0 By my reading of the text, the client is still "obligated" to respond to all of = them (but the server has to be able to receive an arbitrary number of messages before it gets back the response, so it's kind-of a weak obligation).=C2=A0 Would we want to weaken the restriction so that th= e client is only obligated to reply to at least one, similarly to how a peer can coalesce multiple KeyUpdate requests?=C2=A0 I understa= nd that the setup is somewhat different, since the CertificateRequest comes with a context and could correspond to different application-level needs, but it seemed worth mentioning, since as we have discussed before generating the Finished message comes with some burden of handshake buffering/hash forking/etc.

-Ben
_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a113aca34ac2102054391dc37-- From nobody Tue Dec 13 16:24:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A79D129736 for ; Tue, 13 Dec 2016 16:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ksWg43krdRW for ; Tue, 13 Dec 2016 16:24:04 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE2BE129530 for ; Tue, 13 Dec 2016 16:24:04 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id d9so13673995ioe.0 for ; Tue, 13 Dec 2016 16:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bPkszwsX9T3bY98Nbhd2nAR6mGNvdW6xFgLPa/v4TvY=; b=GKXkMEpFoc15b5M6iS1oOdb0T5Qn58m8uc1YcK5DB1epdCV8wCQA4ySPUllssvyYVl tgGrJny7WJv+PieDsI/o67Qeb/AnG05Qtckk4NjsD6/9fz0jctmVUXWqm2n91Y3o50vE AMS1x/BHDTiCm3JFOb5M+ZMTExAq/Rum3Oswn+8pKCkDzt0+WKur4Mrd/p1FEqTEcWaE 7K5Z2NNikpq6fWC7gisgs2E11hCDEp7JvVnPNLr8rB6XkVjGmtldEn5ibHPQlBnTY0sT KOSttATRRfZFzTAPzVUgrWP+rHlOvvzAneZqp7YKkptEadGYL+I4K8ZmqutkJF/xQDGS 28Ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bPkszwsX9T3bY98Nbhd2nAR6mGNvdW6xFgLPa/v4TvY=; b=CSLKOL+J3sn7B1X/YAKs488fN1GHNCT8KrEf1rDX78HqAkvCz1NIlekL9xUQ7cRxM9 uIRx3HqAsEpBvSiwMLQUvEb5DAbzI3e/NaPnr6d6dfp4zJfOzJp6W/qG89eIs/ATJX2N jyX0a9SPljrgD7f33mCXVxEvygtNmv8esawN4Zyt4Q5nb2Po6eMsah4SvCV56XtaC4sC 6kyB6TKmyuY5kbPVb5hzrqWeKdHRng99+9Xn8dF48UcMjeNOtNyjG5ZDjvYhxB2SQcT5 0b84T0Xdlol+8RKoHhU4ln3f9vosAEScw/2C/KTotnh7iSJ0h28NKVeZFPbQvev5uGa5 1g/Q== X-Gm-Message-State: AKaTC03drUkWi73e6YVURv7g6+Ep1Vvt0RACLqTF2mCOK3QHvNItPpeVVwxxqLWwJBIQd9q9cN2bZUJDhqh4Wg== X-Received: by 10.36.219.196 with SMTP id c187mr4985959itg.23.1481675043956; Tue, 13 Dec 2016 16:24:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.35.224 with HTTP; Tue, 13 Dec 2016 16:23:43 -0800 (PST) In-Reply-To: References: From: Joseph Salowey Date: Tue, 13 Dec 2016 16:23:43 -0800 Message-ID: To: "" Content-Type: multipart/alternative; boundary=94eb2c05f1d8ab23650543935a87 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 00:24:07 -0000 --94eb2c05f1d8ab23650543935a87 Content-Type: text/plain; charset=UTF-8 Thanks to all those that participated in the list discussion, it was a very popular topic. On the list and in the meeting, TLS 1.3 had more support than any other option so we believe there is rough consensus to leave the name of the protocol as TLS 1.3. Thanks, J&S On Sat, Dec 3, 2016 at 10:15 PM, Mohan Sekar wrote: > +1 on Tony comment > > > > - Keep this version TLS 1.3 > > - For the next version of TLS, drop the 1.x and call it TLS 4 > > > > Mohan Sekar > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Tony Arcieri > *Sent:* Saturday, December 3, 2016 9:04 AM > *To:* Sean Turner > *Cc:* > *Subject:* Re: [TLS] Confirming consensus: TLS1.3->TLS* > > > > On Thu, Nov 17, 2016 at 6:12 PM, Sean Turner wrote: > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. > > > > I guess we're at the deadline, but I have a compromise I think makes sense: > > > > - Keep this version TLS 1.3 > > - For the next version of TLS, drop the 1.x and call it TLS 4 > > > > -- > > Tony Arcieri > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c05f1d8ab23650543935a87 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks to all those that participated in the list discus= sion, it was a very popular topic.=C2=A0 On the list and in the meeting, TL= S 1.3 had more support than any other option so we believe there is=C2=A0rough consensus to leave the name of = the protocol as TLS 1.3.
Thanks,

J&S

On Sat, Dec 3, 2016 at 10:15 PM, Moh= an Sekar <mohan.sekar@edgeverve.com> wrote:

+1 on Tony comment

=C2=A0

- Keep this version TLS 1.3

- For the next version of TLS, drop the 1.x and call= it TLS 4=C2=A0

=C2=A0

Mohan Sekar

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Tony Arcieri
Sent: Saturday, December 3, 2016 9:04 AM
To: Sean Turner <sean@sn3rd.com>
Cc: <tls@ietf.o= rg> <tls@ietf.o= rg>
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

=C2=A0

On Thu, Nov 17, 2016 at 6:12 PM, Sean Turner <sean@sn3rd.com> wro= te:

The consensus in the room was to leave it as is, i.e= ., TLS1.3, and to not rebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need= to confirm this decision on the list so please let the list know your top = choice between:

- Leave it TLS 1.3
- Rebrand TLS 2.0
- Rebrand TLS 2
- Rebrand TLS 4

by 2 December 2016.

=C2=A0

I guess we're at the deadline, but I have a comp= romise I think makes sense:

=C2=A0

- Keep this version TLS 1.3

- For the next version of TLS, drop the 1.x and call= it TLS 4=C2=A0

=C2=A0

--

Tony Arcieri


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


--94eb2c05f1d8ab23650543935a87-- From nobody Tue Dec 13 17:33:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89D61297EE for ; Tue, 13 Dec 2016 17:33:48 -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 WBXbGwXxA9-I for ; Tue, 13 Dec 2016 17:33:47 -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 57A2C129696 for ; Tue, 13 Dec 2016 17:33:47 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id c47so4588383qtc.2 for ; Tue, 13 Dec 2016 17:33:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=LZCg/V/O4s3TcUfl661DxBZqrde6aFO+l7nCd75B0wU=; b=ReXyncrDbZPMCwnYiEu3Za9yodxHP/DQzFQ6fqRNriJWmRkkvRv7bwHVDGJY7x25Qt oAmcXKnFisN1zUiF6KsSh2czp84tnbsD7vxHSJ+cMA8iCvkh343cc4hpu2ncASi91s/A 9hfW+QPHqwGvS7OZcmX94h4OYL00CKvZQJxdEjLZwoH+yyWm8m3ubd/btiMbNhhdDDKS 0oMoLZEeZXfTwprZKQyW0BOv/a0ltPy5xKkPk/9Zs+t38si4ylzwvb4dDm33KS3343EW tRZS/vlrl7neLLklEq384+05o9RmFeIwrzOs0oHOgPwnQouG00Q90XFQ/1KS8Ei30Qlk KCNg== 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=LZCg/V/O4s3TcUfl661DxBZqrde6aFO+l7nCd75B0wU=; b=PFFvXsKBRq1XZVnqgBHy9fJLjbF4kEizFPy9FJBgYvS+EjexAPi1xywJsKq8ywO3YK atXRcfHF7RHfScmKElbxlynpj8obt1v498qM6Unbr7+Xm0h/3nboU5UWtRzA2LLGoaRu kvaW98byMHBx6oCMxUuHvPf1QciyMFJtjreNjOeI7tAL8wheqb649r0iQ4fD7pG7rzVH q/bCp4BLM1RpvjlUhlV1E+PDswAmpw8QQmix+ESuE9eev1DiWXMGGeoGFygSXM8EAJOO u2/rMTSXGsnsxP+MJEDqHI2PfoW9t76lFkM7c9Ew4hOq0Q3kyeMSfvscIQbx046V96ZU GsYQ== X-Gm-Message-State: AKaTC02vqCTHgLOed+OTqbIAdBmE+v1prIWxiPZT2zaNEZdIvQpo+s2vPUXyZHcpDle/zZwbIp9WzsSwGfGZFw== X-Received: by 10.200.35.14 with SMTP id a14mr85670507qta.159.1481679226298; Tue, 13 Dec 2016 17:33:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 13 Dec 2016 17:33:45 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 14 Dec 2016 12:33:45 +1100 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] Harmonizing 4492bis with TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 01:33:49 -0000 On 13 December 2016 at 22:47, Yoav Nir wrote: > 2. Change 4492bis: > a. no new curves for ed25519 and ed448. > b. Two new signature algorithms, and request values 7 and 8 for them= . > c. new hash algorithm 0x08 and call it something like =E2=80=9Cintri= nsic=E2=80=9D This, but with a small tweak: don't treat these values as requiring special reservation (as we have done for existing hash/signature values). Rather than blocking out all 0x08 hashes, which might be the consequence of this change, we can say that a hash of 0x08 AND either 0x07 or 0x08 identify these signature schemes. We need to be able to allocate 0x0809 at some point later. Maybe also include a reference to TLS 1.3 (informative only) and mention that this is compatible with the change from SignatureAndHash to SignatureScheme in TLS 1.3. Like Ilari, I have backported the TLS 1.3 change to TLS 1.2 and it works fine. It actually fixed some old bugs (such being unable to sign with P-521 and SHA-256, but trying anyway). From nobody Tue Dec 13 21:50:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A65B12984F for ; Tue, 13 Dec 2016 21:50:51 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 35QgHfdY512r for ; Tue, 13 Dec 2016 21:50:50 -0800 (PST) Received: from mail-wj0-x22e.google.com (mail-wj0-x22e.google.com [IPv6:2a00:1450:400c:c01::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 375C412943C for ; Tue, 13 Dec 2016 21:43:00 -0800 (PST) Received: by mail-wj0-x22e.google.com with SMTP id tk12so13889037wjb.3 for ; Tue, 13 Dec 2016 21:43:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OtYmTQy8l2lJRfryhzc9qHG8mcRInt+kqEhItZFNtsw=; b=Fs3bC7QFfCzf8xp/ZCTLFG+BLyXazIue10zpDQY3YZNGY+Dp2OX8nQZArJFk5j3mJL Bgq3CJ6nQJjFLeABjqEx1dFoPyiEEzs/hGKPD5Pw03K9LE8k/Sw0JEcgIICbmQJvhf7e +YreoE/10Df+bTYvxSO5AsIXdoTvYj2l2hoUGjq0chIE3iTfPMD5qAIGW0/CH3BqGMZZ PN7nkDY/JdZHU3YBadZxq0PaFy4x6x7/0hQBm1KaqCCBZLfj2Svou4Y43lBzwVY6DKHX S3XlzzCOi27qXVvixam8T6T2KpkBX4FbWi0s/wpS8KyDBxl5VlzzsXv9i+YiLTgw9Aom 3g9Q== 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=OtYmTQy8l2lJRfryhzc9qHG8mcRInt+kqEhItZFNtsw=; b=fCzZGfZT4M2Lggy4ziDteyWJQ3DGD8z4UeUzVD7lQ0Ur2zP8rs5g6+wNSFDKMOOqUU RVPWM/1ILeiYA0krfCl25j1rDOOTeadAbE/ax+kNtFCkw8fAfw4mjlzp1bW/OMzGuzxB 6V9VQnx9zL0dz77oTtCrWWX0vGLpyjg8NhJy/YgK5NeFlRXh9ZZdPqimTADayXJ0k3ZB 94xEXh3Z2HBZexemZ+b7i27LZ/WlcItnYXmITMNh+jzSOJ2TpH3mOzBzw7HJZnSIzMlH 9OHNMaxlBR/ysU3jiDvvBeVItKGypjmCp0fJxK/VA/D/ZewIXmexX/wmuT4VuK4TRZS4 /ZTQ== X-Gm-Message-State: AKaTC02gLDnLu59ul0xsd2aJN9Iiy5LkJ+JvjUpYfIT0ONd7tRvWKDXgqZvoerELMTWJSg== X-Received: by 10.28.20.139 with SMTP id 133mr5642618wmu.9.1481694178651; Tue, 13 Dec 2016 21:42:58 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id c81sm5749582wmf.22.2016.12.13.21.42.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 13 Dec 2016 21:42:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Yoav Nir In-Reply-To: Date: Wed, 14 Dec 2016 07:42:55 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3259) Archived-At: Cc: "" Subject: Re: [TLS] Harmonizing 4492bis with TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 05:50:51 -0000 > On 14 Dec 2016, at 3:33, Martin Thomson = wrote: >=20 > On 13 December 2016 at 22:47, Yoav Nir wrote: >> 2. Change 4492bis: >> a. no new curves for ed25519 and ed448. >> b. Two new signature algorithms, and request values 7 and 8 for = them. >> c. new hash algorithm 0x08 and call it something like = =E2=80=9Cintrinsic=E2=80=9D >=20 > This, but with a small tweak: don't treat these values as requiring > special reservation (as we have done for existing hash/signature > values). >=20 > Rather than blocking out all 0x08 hashes, which might be the > consequence of this change, we can say that a hash of 0x08 AND either > 0x07 or 0x08 identify these signature schemes. We need to be able to > allocate 0x0809 at some point later. Aren=E2=80=99t we going to have separate registries for 1.2 and 1.3? We = don=E2=80=99t want to force anyone to make the changes you had made (as = part of 1.3) just to get EdDSA..And I need to request things from IANA = based on 1.2 registries. > Maybe also include a reference to TLS 1.3 (informative only) and > mention that this is compatible with the change from SignatureAndHash > to SignatureScheme in TLS 1.3. Already got a reference to 1.3. Might as well add this. > Like Ilari, I have backported the TLS 1.3 change to TLS 1.2 and it > works fine. It actually fixed some old bugs (such being unable to > sign with P-521 and SHA-256, but trying anyway). The hashed input to P-521 is treated as a number. Why doesn=E2=80=99t it = work if the number is smaller? Note that even SHA-512 is 9 bits =E2=80=9Ct= oo small=E2=80=9D. It=E2=80=99s the other way around that is = challenging. But even that is well-defined. Yoav From nobody Tue Dec 13 21:56:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66ADF12985A for ; Tue, 13 Dec 2016 21:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 6v49tdUT_-IR for ; Tue, 13 Dec 2016 21:56:12 -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 98C1812984F for ; Tue, 13 Dec 2016 21:56:12 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id x190so9322397qkb.0 for ; Tue, 13 Dec 2016 21:56:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=GAv5PIE3mb6//vD/sCwpIh7hwDGiCbuLHICJeFNU8ns=; b=Y4fGG2esn4XooAo7kHCwIYUpzFKthBN0MY9PEDBDuSIbWlnwdJLUdI4QcMRXKWufBF MmAFNxwXTEexvhrcDBegrADg60wdMXApiFLx683SV7PcwI7z0sLCBQhXh9VEKQpbg2Nx YMKYE27r2jofCADQOKnM/VaCSB/jcFLuc/mQtuWSJZzlzDJaDGMruDLNAvRE9YStIiVi 0rAALnUnx87aR+/KESZADd+DtJtBF6oWJuPKBJJoQ6wJrKVYliNj31nxmdNpAAedbLhB yyLtvt+UjYyE6DsMB1QfdBfFJ4D5r67rot0PXozuzgpu48z1gZ8pSVxjgBPfNl7EXjBR Z6CQ== 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=GAv5PIE3mb6//vD/sCwpIh7hwDGiCbuLHICJeFNU8ns=; b=NBSESF+2UzIMIR81NL95JDmuoGJLE43Rf7sVzKj/vwmEDXNFNKYVMGVA8k7hwJ+cmD t5x2QCC9HJiqNB5nkX31P/tcOIsnTVEi5GHoR/OQ6EqWnQDPqKoD7Mxcm9hCbU+J6b1I prAYOQZL9T1UiKH0Uwpiobpj+3NwXwdwIwM6f3ZYYmEqbfJoxXcD4l1XKR8dDa2jtY+6 jgb0P8K5qHYkH1gRLtnQzINwzXcOUfKzmwg5t5Gn9MBv3igJhppGbdPOEPNVHxT8EbO2 eDjU6Ykzhff74150CpJMf1MKB5Ig9/9HjKdb4HmhzUoMvc71Pm+LnVLxbjdhNTMdl14D Ih/w== X-Gm-Message-State: AKaTC03NYiGKIBCjw8cZNlG+czr/4U095VI96kn4LeP6gg+AMbe/EB5BQgmJPFtordqwUmF0VR7EUDmePn494w== X-Received: by 10.55.12.2 with SMTP id 2mr85536983qkm.68.1481694971825; Tue, 13 Dec 2016 21:56:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 13 Dec 2016 21:56:11 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 14 Dec 2016 16:56:11 +1100 Message-ID: To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "" Subject: Re: [TLS] Harmonizing 4492bis with TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 05:56:15 -0000 On 14 December 2016 at 16:42, Yoav Nir wrote: > Aren=E2=80=99t we going to have separate registries for 1.2 and 1.3? We = don=E2=80=99t want to force anyone to make the changes you had made (as par= t of 1.3) just to get EdDSA..And I need to request things from IANA based o= n 1.2 registries. Yes, but I was thinking that there might be an expectation about 1.2 values and the way they propagate into the 1.3 registry. We don't want that here. From nobody Wed Dec 14 14:37:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 710DE129B78; Wed, 14 Dec 2016 14:37:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.098 X-Spam-Level: X-Spam-Status: No, score=-107.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 7iMdr44kW49D; Wed, 14 Dec 2016 14:37:37 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C262E129B2B; Wed, 14 Dec 2016 14:37:27 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id B2FF8B808C3; Wed, 14 Dec 2016 14:37:27 -0800 (PST) To: wy@fajrrd.com, tim@dierks.org, ekr@rtfm.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161214223727.B2FF8B808C3@rfc-editor.org> Date: Wed, 14 Dec 2016 14:37:27 -0800 (PST) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Held for Document Update] RFC5246 (4885) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 22:37:39 -0000 The following errata report has been held for document update for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4885 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Wail Yahyaoui Date Reported: 2016-12-13 Held by: Stephen Farrell (IESG) Section: 6.1. Original Text ------------- server random A 32-byte value provided by the server. These parameters are defined in the presentation language as: enum { server, client } ConnectionEnd; Corrected Text -------------- server random A 32-byte value provided by the server. These parameters are defined in the presentation language as: enum { server, client } ConnectionEnd; Notes ----- The line "These parameters are ..." after the list of parameters is at the same indentation level as the list of parameters, instead of coming back left by one level. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Wed Dec 14 14:39:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26E7C129998 for ; Wed, 14 Dec 2016 14:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnClzvqTuFVL for ; Wed, 14 Dec 2016 14:39:17 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A9F129B7B for ; Wed, 14 Dec 2016 14:38:41 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id f82so17824569wmf.1 for ; Wed, 14 Dec 2016 14:38:41 -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=+Dp+Wv6uPEWHV8XjQTCAH3MVI4XQTN3AJi4bP6T3s5Q=; b=lgvljJoliaGLs9w2QVbwCaw3t9e0CiZFnhGA+7AtCiCIqco1fueG86uQv2j+U6Ef8k FEq05DX/qah2o4ef8bodq33AiJ2XZWLngK1XkzFMvbhrRgdIAN7q9eXKtxxNUVDWsWWZ NdR7nzxXg/Kq46TyTevpFGkRKNEnD3ikSovO3HksTgMIQkOPSlVd43W07a+Hel0hLLfv LsY2PtXUqfE+RHsU3vbFr95P6c+otp/WkcE/zQjn6/0j/9rIwlBTZte3Gn65sq87EbI1 r5FYl3XTKvpQdMeeMvwrLlKJ6rYEtUg4WsfeDg5fh1FR3D3DO39kuC4r++kJ+ynz2Fl/ J4zA== 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=+Dp+Wv6uPEWHV8XjQTCAH3MVI4XQTN3AJi4bP6T3s5Q=; b=Ttw1+XRvJ8zLsmhzQFKXoZ1Xi66+VSYQeg8X/IHq3bNqXTcv2GSe/J6xqRGYshtajs yoG2WUmLCRxvJe2mhuoMWN0LV4eR4Fgjs4ao2ntNSspItRhCVbL/rGLyOACutmGyYgaa zdxV1Qrct8YFdIfz1CInMa1OmeIeIJgVYhpI+L45KVWT9TCVvOpUoCYDVaRKK5uEDDHU S2oQJP2+dOTkx9jgULb5Pua9whGChBjt43DqvZOgZ8tFke95rrAmHerBLqlRKdPbEVeu YHDdH8MGoC0v9MRwO4EGVHr7ate2qGujFLNxzp7HCGxlxr0vnOLhDKAtsiLWezkced5P g6bA== X-Gm-Message-State: AKaTC02Tq3qHb+IXPDp7PZFqo62S3q0/9T3IqzGckzKyPCYfQtL3R1+V7EQJx/Dt/Y7PD+OFtMRv9odoPYFtcg== X-Received: by 10.28.164.196 with SMTP id n187mr9416982wme.44.1481755119416; Wed, 14 Dec 2016 14:38:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.112.170 with HTTP; Wed, 14 Dec 2016 14:38:39 -0800 (PST) From: David Wong Date: Wed, 14 Dec 2016 16:38:39 -0600 Message-ID: To: "" Content-Type: multipart/alternative; boundary=94eb2c074e46897d0c0543a5ffad Archived-At: Subject: [TLS] Some feedback on draft 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 22:39:20 -0000 --94eb2c074e46897d0c0543a5ffad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello! I read the current specification and I have some feedback on it. I hope this can be useful. Sorry for the length or if I point to obvious things. Here is a link as well for readability: https://gist.github.com/mimoo/b6c64a133cd85da53f2f744dcdb39839 1. *1-Byte Length of Vectors*: One edge-case that is implied and not discussed in the Presentation Language section is: "do I need to write the length of a vector<0...255>?". It seems logical that i= t will always be 1 byte and that it might be an implicit length. It would = be nice to have this edge case mentioned or say something along the lines "there are no exceptions when encoding the length of variable-length vectors". 2. *Lack of repetition*: The intro diagram tells you what messages are encrypted with what key. But after that, no reminders are present. For example, look at the Finished message. How do you know that this has to be encrypted with the handshake key? It is not written in the Finished message section, it is not written in the authentication messages parent section and it is not written in the handshake protocol parent-parent section either. Only in the overview section. 3. *How to define application data in an application data message*: It is not clear how "real" application data should appear in an application da= ta message. Encrypted handshakes and alerts are clearly defined, but it tak= es some time to understand that "real" application data is written -- witho= ut structure or metadata -- into the content field of a TLSInnerPlaintext message. The current definition is "content: The cleartext of TLSPlaintext.fragment". I think a better one would be "content: the byte encoding of a handshake or alert message, or the raw bytes of the application's data to send". 4. *Unencrypted Application Data*: Does it say somewhere in the specification that real application data should never appear in a TLSPlaintext message? At the moment the application_data content type is present in the declaration of a TLSPlaintext structure, see the record layer section 5. *What alert to use*: Sometimes it is not mentioned what level of alert should be used. For example: "Because TLS 1.3 forbids renegotiation, if = a server receives a ClientHello at any other time, it MUST terminate the connection". I'm guessing it should be a fatal alert, but this is open t= o interpretation. 6. *Why force the signature algorithm extension*: If the client does not send a signature algorithm extension, why would the server abort the handshake? It would make more sense to continue with the server's prefer= ed certificate. Especially since currently, most webservers only possess on= e kind of certificate anyway. 7. *Resumption_secret*: The Key Schedule section mentions a resumption_secret but nowhere in the spec does this keyword re-appear. It should be mentioned somewhere that this is the secret to be used as P= SK in a future resumption handshake. 8. *Auth_modes*: there is a single mention of "auth_modes" in the Pre-Share= d Key Extension section. No definition of this variable is to be found. 9. *Computing Finished keys*: The section on how to compute Finished keys should be in the cryptographic computation section in my opinion. It should probably be added to the key schedule diagram a= s well. 10. *Computation of the Binders*: From the relevant section : "*Each entry in the binders list is computed as an HMAC over the portion of the ClientHello = up to and including the PreSharedKeyExtension.identities field. That is, it includes all of the ClientHello but not the binder list itself. The leng= th fields for the message (including the overall length, the length of the extensions block, and the length of the =E2=80=9Cpre_shared_key=E2=80=9D= extension) are all set as if the binder were present*". There are several things that are unclear to me and I think they should be mentioned here: the fake binder should be of size hash.size, it should also say that the HMAC is computed over the handshake message containing the client hello, not onl= y the client hello structure. 11. *What binder key to use*: It is not clear which binder are to be used when doing a session resumption. The previous handshake one or the new handshake one? The confusion comes from the fact that the old handshake'= s resumption_secret/PSK is to be used in the new handshake, it could be thought that the old handshake's binder key should be the one used in the new handshake as well. I think it would help if this resumption_secret is called something like next_handshake.resumption_secret. Or make it clearer from which key schedule the binder key comes from. 12. *PSK and Cipher Suite*: I think the following fact should be emphasized in more places: the client needs to advertise the single cipher suite th= ey previously used when doing session resumption. It could be added to the cipher_suite definition of the client hello section as well as in the overview of session resumption . 13. *Implicit Lengths in The Presentation Language*: nested structures + implicit lengths =3D trouble. It's easy to forget parsing/writing all th= e different "sizes" when they are not clearly stated in the spec. Why not just having a length field in front of these variable-length vectors? It would add a bit of overhead but would make things clearer in my opinion. 14. *No Help For The Implementer*: If you look at the Noise Protocol Framework , you can clearly see that the specifications were written with implementers in mind: several states, and objects are defined. For example, one way of implementing TL= S is to have some sort of complex state that will remember what state you = are in the handshake, what is the cryptographic context, etc... here the implementer has to decide everything for himself. 15. *Whitelist Of State Transitions*: There is nothing about whitelisting state transitions. In my opinion there should be a list of allowed state transitions that the implementer could use. I made one here, I suspect it is still missing some states . 16. *How to parse extensions*: I think that IANA's consideration section's table would be useful to have in the earlier Extension section (probably only the extensions included in the RFC should be listed). Another useful pragrap= h: how to parse these extensions, making sure that different messages come with their own whitelist of extensions. 17. *Language <-> Bytes Translation*: There are no real introduction/no clear section about this. I understand that everything is in the Presentation Language section but for someone who discovers the specification it takes some ti= me to find out that this section is about both the presentation language an= d its byte encoding. A better introduction in this section as well as an emphasis on the byte representation in each of the subsections of this section would in my opinion benefit the whole document. 18. *Asymmetrical MUSTs*: some "MUST" keywords are not symmetrical. What is the point of them? For example, the spec says that as a client, you MUST use a unique 0x0303 value in the legacy_version field of the client hell= o . But if you do not, there are no problems from the server side in the specification and the client hello will still be well received. (Is this maybe for forward compatibility?) And finally, here are some minor nitpicks: 1. *PSK extension*: *debatable*, but I would rather have the PSK section at the very end of the Extensions section as it MUST be the final extension of a client hello. 2. *No Indication Of Encryption*: This is *debatable*, but I find it inelegant that there are no indication in a record that it is encrypted. The implementation is supposed to keep track of it. 3. *What PSK mode does a server support*: I think the server should indicate what mode (psk_dh_ke or psk_ke) it supports in a server_hello.psk_mode extension or in the new_session_ticket message. Like that the client would know if it has to send a key_share or not in the resumption. Right now, the only indication of a psk_dh_ke is that the server will send a key_share even when presented with a PSK. *this is debatable*. 4. *The Key Derivation*: The key derivation section is the least clear section in this specification. The diagrams kind of help, but are limite= d by the RFC format... I have nothing else to say here, the whole section = is confusing to say the least. No solution offered :o) --94eb2c074e46897d0c0543a5ffad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hello! I read the current specification and I have some feedback on it. I hope this can be useful. Sorry for the length or if I point to obvious=20 things. Here is a link as well for readability: https://gist.github.com/mim= oo/b6c64a133cd85da53f2f744dcdb39839

  1. 1-Byte Length of Vectors: One edge-case that is= implied and not discussed in the Presentation Language section is: "do I need to write the length of a vector<0...255>?".= It=20 seems logical that it will always be 1 byte and that it might be an=20 implicit length. It would be nice to have this edge case mentioned or=20 say something along the lines "there are no exceptions when encoding t= he length of variable-length vectors".

  2. Lack of re= petition: The intro diagram tells you what messages are encrypted with what key. But after that, no reminders are present. For example, look at the Finished message. How=20 do you know that this has to be encrypted with the handshake key? It is=20 not written in the Finished message section, it is not written in the authentication messag= es parent section and it is not written in the handshake protocol parent-parent = section either. Only in the overview section.

  3. How to= define application data in an application data message: It is not clear how "real" application data should appear in an= =20 application data message. Encrypted handshakes and alerts are clearly=20 defined, but it takes some time to understand that "real" applica= tion=20 data is written -- without structure or metadata -- into the content<= /code> field of a TLSInnerPlaintext message. The current definition is "content: The cleartext of=20 TLSPlaintext.fragment". I think a better one would be "content: t= he byte encoding of a handshake or alert message, or the raw bytes of the=20 application's data to send".

  4. Unencrypted Ap= plication Data: Does it say somewhere in the specification that re= al application data should never appear in a TLSPlaintext mess= age? At the moment the application_data content type is presen= t in the declaration of a TLSPlaintext structure, see the record layer sect= ion

  5. What alert to use: Sometimes it is = not mentioned what level of alert should be used. For example: "Because TLS 1.3=20 forbids renegotiation, if a server receives a ClientHello at any other=20 time, it MUST terminate the connection". I'm guessing it should be= a=20 fatal alert, but this is open to interpretation.

  6. Why= force the signature algorithm extension: If=20 the client does not send a signature algorithm extension, why would the=20 server abort the handshake? It would make more sense to continue with=20 the server's prefered certificate. Especially since currently, most=20 webservers only possess one kind of certificate anyway.

  7. Resumption_secret: The Key Schedule section mentions a resumpti= on_secret but nowhere in the spec does this keyword re-appear. It should be=20 mentioned somewhere that this is the secret to be used as PSK in a=20 future resumption handshake.

  8. Auth_modes: th= ere is a single mention of "auth_modes" in the Pre-Shared Key Exten= sion section. No definition of this variable is to be found.

    9. Computing Finished keys: The section on how to compute Finishe= d keys should be in the cryptographic computation section in my opi= nion. It should probably be added to the key schedule diagram as well.

    <= /li>

  9. Computation of the Binders: From the relevant section: &quo= t;Each entry in the binders list is computed as an HMAC over the portion of=20 the ClientHello up to and including the PreSharedKeyExtension.identities field. That is, it includes all of the ClientHello but not the binder=20 list itself. The length fields for the message (including the overall=20 length, the length of the extensions block, and the length of the=20 =E2=80=9Cpre_shared_key=E2=80=9D extension) are all set as if the binder we= re present". There are several things that are unclear to me and = I think they should be mentioned here: the fake binder should be of size hash.size, it should also say that the HMAC is computed over the handshake message containing the client hello, not only the client hello structure.

    10. =

  10. What binder key to use: It is not clear which=20 binder are to be used when doing a session resumption. The previous=20 handshake one or the new handshake one? The confusion comes from the=20 fact that the old handshake's resumption_secret/PSK is to = be used in the new handshake, it could be thought that the old handshake= 9;s binder key should be the one used in the new handshake as = well. I think it would help if this resumption_secret is calle= d something like next_handshake.resumption_secret. Or make it = clearer from which key schedule the binder key comes from.

    =

  11. PSK and Cipher Suite: I think the following fa= ct should be emphasized in more places: the client needs to advertise the=20 single cipher suite they previously used when doing session resumption.=20 It could be added to the cipher_suite definition of the client hello section= as well as in the overview of session resumption.

  12. I= mplicit Lengths in The Presentation Language: nested structu= res + implicit lengths =3D trouble. It's easy to forget parsing/writing all the different "sizes"= ; when they are not clearly stated in the spec. Why not just having a length field=20 in front of these variable-length vectors? It would add a bit of=20 overhead but would make things clearer in my opinion.

  13. No Help For The Implementer: If you look at the Noise Protocol Framework, you can clearly see that the specifications were written with=20 implementers in mind: several states, and objects are defined. For=20 example, one way of implementing TLS is to have some sort of complex=20 state that will remember what state you are in the handshake, what is=20 the cryptographic context, etc... here the implementer has to decide=20 everything for himself.

  14. Whitelist Of State Transitio= ns: There is nothing about whitelisting state transitions. In my opinion there should be a=20 list of allowed state transitions that the implementer could use. I made = one here, I suspect it is still missing some states.

  15. How to parse extensions: I think that IANA's consideration s= ection's table would be useful to have in the earlier Extension section (probably only the extensions included in the RFC should be listed).=20 Another useful pragraph: how to parse these extensions, making sure that different messages come with their own whitelist of extensions.

    16. Language <-> Bytes Translation: There are no re= al introduction/no clear section about this. I understand that everything i= s in the Presentation Language section but for someone who discovers the specification it takes some=20 time to find out that this section is about both the presentation=20 language and its byte encoding. A better introduction in this section as well as an emphasis on the byte representation in each of the=20 subsections of this section would in my opinion benefit the whole=20 document.

  16. Asymmetrical MUSTs: some "MU= ST" keywords are not symmetrical. What is the point of them? For example, the spec says that as a client, you MUST use a unique 0x0303 value in the = legacy_version field of the client hello. But if you do not, there are no problems from the server side in the=20 specification and the client hello will still be well received. (Is this maybe for forward compatibility?)

And finally, here are some minor nitpicks:

  1. PSK extension: debatable, but = I would rather have the PSK section at the very end of the Extensions section as it M= UST be the final extension of a client hello.

  2. No In= dication Of Encryption: This is debatable, but I find it inelegant that there are no indication in a record that=20 it is encrypted. The implementation is supposed to keep track of it.

  3. What PSK mode does a server support: I think the = server should indicate what mode (psk_dh_ke or psk_ke) it supports in a server_hello.psk_mode extension or in t= he new_session_ticket message. Like that the client would know= if it has to send a key_share or not in the resumption. Right= now, the only indication of a psk_dh_ke is that the server wi= ll send a key_share even when presented with a PSK. th= is is debatable.

  4. The Key Derivation: The key derivation section=20 is the least clear section in this specification. The diagrams kind of=20 help, but are limited by the RFC format... I have nothing else to say=20 here, the whole section is confusing to say the least. No solution=20 offered :o)

--94eb2c074e46897d0c0543a5ffad-- From nobody Wed Dec 14 15:18:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5FFA129C06 for ; Wed, 14 Dec 2016 15:18:29 -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 i2ZKwIAk1EmF for ; Wed, 14 Dec 2016 15:18:26 -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 B7978129BEF for ; Wed, 14 Dec 2016 15:18:25 -0800 (PST) Received: by mail-yb0-x231.google.com with SMTP id d128so24736850ybh.2 for ; Wed, 14 Dec 2016 15:18:25 -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=mioeIQBsx1YXiDcmC2dLvx1NwFn+r3l3zbmpSFyq5O0=; b=bdsXI03OJzG2I+ZwyOaaMXP8CxNFiLVvkbx6Et5uXgi67TLfOeCmhSJVWM1SfNfYat Rf5IOd/yUbYgqm+5UEIOzBJmdObfdeiaCBXsUx2Cd4xNm5e7Pi633ZUtmLCdMLqjFnJ0 63V+inE2Wv3+m9xzV9mFOFqbVyLH79rWO0yR6x/rQ73158mweZ7mCb2/giI/Im75dddy xT5epDCeB6xzY4zM5nUzRG1kKoL8p2ZCXj6SdvKYqFMll+81TgcOifW4latYFZbhIxqJ VQAnMMKSdgz226ZGLRMLY5Q/l0kOj/1jwQ1zvxCM7AtEOdU8dU4YmR7SaPtBIXCdpOUV Gd5A== 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=mioeIQBsx1YXiDcmC2dLvx1NwFn+r3l3zbmpSFyq5O0=; b=m5uaioiJxqexZHjTyS44E7Bt40afx9lsYAcPRPFelY2e4MX9GHsJKHh3ck19tJHmkF 7G6K6KaWyhmUwNI9L6DnEj4orXoTYVRJ943TDRfTgJgyrTvAEKdMwKmy4wsEkAn84T8J tRUV77NU9lg12jmDJSG/hJxUzutQtE81775+Pxe5v5gKb58dh61kFQhOqblvp85pVUtR b9um+j5bTYXKci2WuGPEIR48yKj8sXHhi5LemdvOxKvHyzunLuRVPccKRb0ByPtlC+4u DH9DP0NWZdXhR9KIYRDLCR6hFIxPzDAOJrrACKbsQRp80x8medLgf4LT/44B+8Tb1Wqx dHOg== X-Gm-Message-State: AKaTC018Wl3hDd6qCQfeqLnfdnrv5yPX74Zkk7XuSbUxq9RHuetuK5UbYS4la8E33cLeGQ9v31cITzp/f7xe/Q== X-Received: by 10.37.78.138 with SMTP id c132mr54577540ybb.180.1481757504816; Wed, 14 Dec 2016 15:18:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Wed, 14 Dec 2016 15:17:44 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 14 Dec 2016 16:17:44 -0700 Message-ID: To: David Wong Content-Type: multipart/alternative; boundary=001a113e7afcb815420543a68d26 Archived-At: Cc: "" Subject: Re: [TLS] Some feedback on draft 18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Dec 2016 23:18:30 -0000 --001a113e7afcb815420543a68d26 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi David, Thanks for taking the time to read this. Some responses below. > 1-Byte Length of Vectors: One edge-case that is implied and not > discussed in the Presentation Language section is: "do I need to write > the length of a vector<0...255>?". It seems logical that it will > always be 1 byte and that it might be an implicit length. It would be > nice to have this edge case mentioned or say something along the lines > "there are no exceptions when encoding the length of variable-length > vectors". I'm not sure I understand your point here about why this is an edge case. In order for the encoding to be unambiguous, every variable length vectory must always be prefixed by the length, even if in a particular message it is zero length. This section seems pretty clear to me. Note that unconditional statement about encoding followed by the last sentence about empty vectors. Variable-length vectors are defined by specifying a subrange of legal lengths, inclusively, using the notation . When these are encoded, the actual length precedes the vector's contents in the byte stream. The length will be in the form of a number consuming as many bytes as required to hold the vector's specified maximum (ceiling) length. A variable-length vector with an actual length field of zero is referred to as an empty vector. Happy to look at making this clearer, but I'd rather not just add a clarifying sentence. > Lack of repetition: The intro diagram tells you what messages are > encrypted with what key. But after that, no reminders are present. For > example, look at the Finished message. How do you know that this has > to be encrypted with the handshake key? It is not written in the > Finished message section, it is not written in the authentication > messages parent section and it is not written in the handshake > protocol parent-parent section either. Only in the overview section. I'll see what I can do about this. With that said, I'm trying to remove unnecessary duplication, so it's a compromise. > How to define application data in an application data message: It is > not clear how "real" application data should appear in an application > data message. Encrypted handshakes and alerts are clearly defined, but > it takes some time to understand that "real" application data is > written -- without structure or metadata -- into the content field of > a TLSInnerPlaintext message. The current definition is "content: The > cleartext of TLSPlaintext.fragment". I think a better one would be > "content: the byte encoding of a handshake or alert message, or the > raw bytes of the application's data to send". Yeah, this seems like a good change. Feel free to send a PR or I can just do it. > Unencrypted Application Data: Does it say somewhere in the > specification that real application data should never appear in a > TLSPlaintext message? At the moment the application_data content type > is present in the declaration of a TLSPlaintext structure, see the > record layer section I'm not sure I understand what you're saying here. > What alert to use: Sometimes it is not mentioned what level of alert > should be used. For example: "Because TLS 1.3 forbids renegotiation, > if a server receives a ClientHello at any other time, it MUST > terminate the connection". I'm guessing it should be a fatal alert, > but this is open to interpretation. Hmm... I think this is pretty clear in 6.2. Whenever an implementation encounters a fatal error condition, it SHOULD send an appropriate fatal alert and MUST close the connection without sending or receiving any additional data. In the rest of this specification, the phrase "{terminate the connection, abort the handshake}" is used without a specific alert means that the implementation SHOULD send the alert indicated by the descriptions > Why force the signature algorithm extension: If the client does not > send a signature algorithm extension, why would the server abort the > handshake? It would make more sense to continue with the server's > prefered certificate. Especially since currently, most webservers only > possess one kind of certificate anyway. The signature algorithms extension also indicates what to sign with, and that's not completely determined by the certificate (e.g., with RSA). > Resumption_secret: The Key Schedule section mentions a > resumption_secret but nowhere in the spec does this keyword > re-appear. It should be mentioned somewhere that this is the secret to > be used as PSK in a future resumption handshake. Good catch. This is actually called the resumption master secret. I'll clean this up. > Auth_modes: there is a single mention of "auth_modes" in the > Pre-Shared Key Extension section. No definition of this variable is to > be found. Yeah, this is a holdover from when this field exists. I fixed that. > Computing Finished keys: The section on how to compute Finished keys > should be in the cryptographic computation section in my opinion. It > should probably be added to the key schedule diagram as well. This made the key schedule too hard to read (I note you complain about that below) so I'm reluctant to add it. I'd be interested in other people's opinions about whether these computations would be better in this section. > Computation of the Binders: From the relevant section: "Each entry in > the binders list is computed as an HMAC over the portion of the > ClientHello up to and including the PreSharedKeyExtension.identities > field. That is, it includes all of the ClientHello but not the binder > list itself. The length fields for the message (including the overall > length, the length of the extensions block, and the length of the > =E2=80=9Cpre_shared_key=E2=80=9D extension) are all set as if the binder = were > present". There are several things that are unclear to me and I think > they should be mentioned here: the fake binder should be of size > hash.size, it should also say that the HMAC is computed over the > handshake message containing the client hello, not only the client > hello structure. I'll see what I can do here. > What binder key to use: It is not clear which binder are to be used > when doing a session resumption. The previous handshake one or the new > handshake one? The confusion comes from the fact that the old > handshake's resumption_secret/PSK is to be used in the new handshake, > it could be thought that the old handshake's binder key should be the > one used in the new handshake as well. I think it would help if this > resumption_secret is called something like > next_handshake.resumption_secret. Or make it clearer from which key > schedule the binder key comes from. I'm not quite following. It's not possible to compute the RMS at this point in the handshake. The only PSK you could possibly have is the one from the previous handshake. > PSK and Cipher Suite: I think the following fact should be emphasized > in more places: the client needs to advertise the single cipher suite > they previously used when doing session resumption. It could be added > to the cipher_suite definition of the client hello section as well as > in the overview of session resumption. Thanks. I can add something. > Implicit Lengths in The Presentation Language: nested structures + > implicit lengths =3D trouble. It's easy to forget parsing/writing all > the different "sizes" when they are not clearly stated in the > spec. Why not just having a length field in front of these > variable-length vectors? It would add a bit of overhead but would make > things clearer in my opinion. Can you point to the specific structures you are concerned with here? I think in almost every case we do have length fields. Actually, a common complaint is we have too many redundant length fields. > No Help For The Implementer: If you look at the Noise Protocol > Framework, you can clearly see that the specifications were written > with implementers in mind: several states, and objects are > defined. For example, one way of implementing TLS is to have some sort > of complex state that will remember what state you are in the > handshake, what is the cryptographic context, etc... here the > implementer has to decide everything for himself. Most IETF specs leave the choice of how to do things up to the implementor. As someone who has implemented a lot of specs, I actually find it pretty frustrating when the author gets all prescriptive about implementation. If there are points that are unclear, I think it's fine to make them clear, but I'd rather stick to the PDUs. > Whitelist Of State Transitions: There is nothing about whitelisting > state transitions. In my opinion there should be a list of allowed > state transitions that the implementer could use. I made one here, I > suspect it is still missing some states. I'm going to add a state diagram in -19. This link seems like useful input. Thanks. > How to parse extensions: I think that IANA's consideration section's > table would be useful to have in the earlier Extension section > (probably only the extensions included in the RFC should be > listed). Another useful pragraph: how to parse these extensions, > making sure that different messages come with their own whitelist of > extensions. Good point. I'll make this change. > Language <-> Bytes Translation: There are no real introduction/no > clear section about this. I understand that everything is in the > Presentation Language section but for someone who discovers the > specification it takes some time to find out that this section is > about both the presentation language and its byte encoding. A better > introduction in this section as well as an emphasis on the byte > representation in each of the subsections of this section would in my > opinion benefit the whole document. I'm not quite sure I understand what you're looking for here. Can you send a PR? > Asymmetrical MUSTs: some "MUST" keywords are not symmetrical. What is > the point of them? For example, the spec says that as a client, you > MUST use a unique 0x0303 value in the legacy_version field of the > client hello. But if you do not, there are no problems from the server > side in the specification and the client hello will still be well > received. (Is this maybe for forward compatibility?) Amongst other things. MUST do X but must allow X and Y is pretty common in IETF spec. > And finally, here are some minor nitpicks: > > PSK extension: debatable, but I would rather have the PSK section at > the very end of the Extensions section as it MUST be the final > extension of a client hello. Yeah, I can do that. > No Indication Of Encryption: This is debatable, but I find it > inelegant that there are no indication in a record that it is > encrypted. The implementation is supposed to keep track of it. Actually, at present everything with first byte =3D=3D application_data is encrypted and everything else is not. > What PSK mode does a server support: I think the server should > indicate what mode (psk_dh_ke or psk_ke) it supports in a > server_hello.psk_mode extension or in the new_session_ticket > message. Like that the client would know if it has to send a key_share > or not in the resumption. Right now, the only indication of a > psk_dh_ke is that the server will send a key_share even when presented > with a PSK. this is debatable. This was a pretty explicit decision to avoid redundancy, so I think we have WG consensus here. > The Key Derivation: The key derivation section is the least clear > section in this specification. The diagrams kind of help, but are > limited by the RFC format... I have nothing else to say here, the > whole section is confusing to say the least. No solution offered :o) Yeah, not too sure what to do. Thanks, -Ekr On Wed, Dec 14, 2016 at 3:38 PM, David Wong wrote: > Hello! I read the current specification and I have some feedback on it. I > hope this can be useful. Sorry for the length or if I point to obvious > things. Here is a link as well for readability: > https://gist.github.com/mimoo/b6c64a133cd85da53f2f744dcdb39839 > > 1. > > *1-Byte Length of Vectors*: One edge-case that is implied and not > discussed in the Presentation Language section > is: "do I > need to write the length of a vector<0...255>?". It seems logical that= it > will always be 1 byte and that it might be an implicit length. It woul= d be > nice to have this edge case mentioned or say something along the lines > "there are no exceptions when encoding the length of variable-length > vectors". > 2. > > *Lack of repetition*: The intro diagram > tells you what > messages are encrypted with what key. But after that, no reminders are > present. For example, look at the Finished message. How do you know th= at > this has to be encrypted with the handshake key? It is not written in = the Finished > message > section, it is not written in the authentication messages > parent section > and it is not written in the handshake protocol > parent-parent > section either. Only in the overview section. > 3. > > *How to define application data in an application data message*: It is > not clear how "real" application data should appear in an application = data > message. Encrypted handshakes and alerts are clearly defined, but it t= akes > some time to understand that "real" application data is written -- wit= hout > structure or metadata -- into the content field of a TLSInnerPlaintext > message. The current definition is "content: The cleartext of > TLSPlaintext.fragment". I think a better one would be "content: the by= te > encoding of a handshake or alert message, or the raw bytes of the > application's data to send". > 4. > > *Unencrypted Application Data*: Does it say somewhere in the > specification that real application data should never appear in a > TLSPlaintext message? At the moment the application_data content type > is present in the declaration of a TLSPlaintext structure, see the > record layer section > 5. > > *What alert to use*: Sometimes it is not mentioned what level of alert > should be used. For example: "Because TLS 1.3 forbids renegotiation, i= f a > server receives a ClientHello at any other time, it MUST terminate the > connection". I'm guessing it should be a fatal alert, but this is open= to > interpretation. > 6. > > *Why force the signature algorithm extension*: If the client does not > send a signature algorithm extension, why would the server abort the > handshake? It would make more sense to continue with the server's pref= ered > certificate. Especially since currently, most webservers only possess = one > kind of certificate anyway. > 7. > > *Resumption_secret*: The Key Schedule > section mentions > a resumption_secret but nowhere in the spec does this keyword > re-appear. It should be mentioned somewhere that this is the secret to= be > used as PSK in a future resumption handshake. > 8. > > *Auth_modes*: there is a single mention of "auth_modes" in the Pre-Sha= red > Key Extension > > section. No definition of this variable is to be found. > 9. > > *Computing Finished keys*: The section on how to compute Finished keys > should be in > the cryptographic computation > > section in my opinion. It should probably be added to the key schedule > diagram as well. > 10. > > *Computation of the Binders*: From the relevant section > : "*Each entry in the > binders list is computed as an HMAC over the portion of the ClientHell= o up > to and including the PreSharedKeyExtension.identities field. That is, = it > includes all of the ClientHello but not the binder list itself. The le= ngth > fields for the message (including the overall length, the length of th= e > extensions block, and the length of the =E2=80=9Cpre_shared_key=E2=80= =9D extension) are all > set as if the binder were present*". There are several things that are > unclear to me and I think they should be mentioned here: the fake bind= er > should be of size hash.size, it should also say that the HMAC is > computed over the handshake message containing the client hello, not o= nly > the client hello structure. > 11. > > *What binder key to use*: It is not clear which binder are to be used > when doing a session resumption. The previous handshake one or the new > handshake one? The confusion comes from the fact that the old handshak= e's > resumption_secret/PSK is to be used in the new handshake, it could be > thought that the old handshake's binder key should be the one used in > the new handshake as well. I think it would help if this > resumption_secret is called something like next_handshake.resumption_ > secret. Or make it clearer from which key schedule the binder key > comes from. > 12. > > *PSK and Cipher Suite*: I think the following fact should be > emphasized in more places: the client needs to advertise the single ci= pher > suite they previously used when doing session resumption. It could be = added > to the cipher_suite definition of the client hello section > as well as in the o= verview > of session resumption > . > 13. > > *Implicit Lengths in The Presentation Language*: nested structures + > implicit lengths =3D trouble. It's easy to forget parsing/writing all > the different "sizes" when they are not clearly stated in the spec. Wh= y not > just having a length field in front of these variable-length vectors? = It > would add a bit of overhead but would make things clearer in my opinio= n. > 14. > > *No Help For The Implementer*: If you look at the Noise Protocol > Framework , you can clearly > see that the specifications were written with implementers in mind: se= veral > states, and objects are defined. For example, one way of implementing = TLS > is to have some sort of complex state that will remember what state yo= u are > in the handshake, what is the cryptographic context, etc... here the > implementer has to decide everything for himself. > 15. > > *Whitelist Of State Transitions*: There is nothing about whitelisting > state transitions. In my opinion there should be a list of allowed sta= te > transitions that the implementer could use. I made one here, I suspect > it is still missing some states > . > 16. > > *How to parse extensions*: I think that IANA's consideration > section's > table would be useful to have in the earlier Extension section > (probably only the > extensions included in the RFC should be listed). Another useful pragr= aph: > how to parse these extensions, making sure that different messages com= e > with their own whitelist of extensions. > 17. > > *Language <-> Bytes Translation*: There are no real introduction/no > clear section about this. I understand that everything is in the Prese= ntation > Language > section but for someone who discovers the specification it takes some = time > to find out that this section is about both the presentation language = and > its byte encoding. A better introduction in this section as well as an > emphasis on the byte representation in each of the subsections of this > section would in my opinion benefit the whole document. > 18. > > *Asymmetrical MUSTs*: some "MUST" keywords are not symmetrical. What > is the point of them? For example, the spec says that as a client, you= MUST > use a unique 0x0303 value in the legacy_version field of the client > hello . But if you > do not, there are no problems from the server side in the specificatio= n and > the client hello will still be well received. (Is this maybe for forwa= rd > compatibility?) > > And finally, here are some minor nitpicks: > > 1. > > *PSK extension*: *debatable*, but I would rather have the PSK section > at the > very end of the Extensions section > as it MUST be the > final extension of a client hello. > 2. > > *No Indication Of Encryption*: This is *debatable*, but I find it > inelegant that there are no indication in a record that it is encrypte= d. > The implementation is supposed to keep track of it. > 3. > > *What PSK mode does a server support*: I think the server should > indicate what mode (psk_dh_ke or psk_ke) it supports in a > server_hello.psk_mode extension or in the new_session_ticket message. > Like that the client would know if it has to send a key_share or not > in the resumption. Right now, the only indication of a psk_dh_ke is > that the server will send a key_share even when presented with a PSK. = *this > is debatable*. > 4. > > *The Key Derivation*: The key derivation section is the least clear > section in this specification. The diagrams kind of help, but are limi= ted > by the RFC format... I have nothing else to say here, the whole sectio= n is > confusing to say the least. No solution offered :o) > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113e7afcb815420543a68d26 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi David,

Thanks for ta= king the time to read this. Some responses below.

=
> 1-Byte Length of Vectors: One edge-case that is implied= and not
> discussed in the Presentation Language section is: = "do I need to write
> the length of a vector<0...255&g= t;?". It seems logical that it will
> always be 1 byte an= d that it might be an implicit length. It would be
> nice to h= ave this edge case mentioned or say something along the lines
>= ; "there are no exceptions when encoding the length of variable-length=
> vectors".

I'm not sure I = understand your point here about why this is an edge
case. In ord= er for the encoding to be unambiguous, every variable
length vect= ory must always be prefixed by the length, even if in
a particula= r message it is zero length. This section seems pretty
clear to m= e. Note that unconditional statement about encoding
followed by t= he last sentence about empty vectors.

=C2=A0 =C2= =A0Variable-length vectors are defined by specifying a subrange of legal
=C2=A0 =C2=A0lengths, inclusively, using the notation <floor..ce= iling>.=C2=A0 When
=C2=A0 =C2=A0these are encoded, the actual = length precedes the vector's contents
=C2=A0 =C2=A0in the byt= e stream.=C2=A0 The length will be in the form of a number
=C2=A0= =C2=A0consuming as many bytes as required to hold the vector's specifi= ed
=C2=A0 =C2=A0maximum (ceiling) length.=C2=A0 A variable-length= vector with an actual
=C2=A0 =C2=A0length field of zero is refer= red to as an empty vector.

Happy to look at making= this clearer, but I'd rather not just
add a clarifying sente= nce.


> Lack of repetition: The i= ntro diagram tells you what messages are
> encrypted with what= key. But after that, no reminders are present. For
> example,= look at the Finished message. How do you know that this has
>= to be encrypted with the handshake key? It is not written in the
> Finished message section, it is not written in the authentication
> messages parent section and it is not written in the handshake<= /div>
> protocol parent-parent section either. Only in the overview = section.

I'll see what I can do about this. Wi= th that said, I'm trying to remove
unnecessary duplication, s= o it's a compromise.


> How t= o define application data in an application data message: It is
&= gt; not clear how "real" application data should appear in an app= lication
> data message. Encrypted handshakes and alerts are c= learly defined, but
> it takes some time to understand that &q= uot;real" application data is
> written -- without struct= ure or metadata -- into the content field of
> a TLSInnerPlain= text message. The current definition is "content: The
> c= leartext of TLSPlaintext.fragment". I think a better one would be
> "content: the byte encoding of a handshake or alert message= , or the
> raw bytes of the application's data to send&quo= t;.

Yeah, this seems like a good change. Feel free= to send a PR or I can just
do it.


<= /div>
> Unencrypted Application Data: Does it say somewhere in the
> specification that real application data should never appear = in a
> TLSPlaintext message? At the moment the application_dat= a content type
> is present in the declaration of a TLSPlainte= xt structure, see the
> record layer section

I'm not sure I understand what you're saying here.


> What alert to use: Sometimes it is not= mentioned what level of alert
> should be used. For example: = "Because TLS 1.3 forbids renegotiation,
> if a server rec= eives a ClientHello at any other time, it MUST
> terminate the= connection". I'm guessing it should be a fatal alert,
&= gt; but this is open to interpretation.

Hmm... I t= hink this is pretty clear in 6.2.

=C2=A0 =C2=A0Whe= never an implementation encounters a fatal error condition, it
= =C2=A0 =C2=A0SHOULD send an appropriate fatal alert and MUST close the conn= ection
=C2=A0 =C2=A0without sending or receiving any additional d= ata.=C2=A0 In the rest of
=C2=A0 =C2=A0this specification, the ph= rase "{terminate the connection, abort the
=C2=A0 =C2=A0hand= shake}" is used without a specific alert means that the
=C2= =A0 =C2=A0implementation SHOULD send the alert indicated by the description= s


> Why force the signature algo= rithm extension: If the client does not
> send a signature alg= orithm extension, why would the server abort the
> handshake? = It would make more sense to continue with the server's
> p= refered certificate. Especially since currently, most webservers only
=
> possess one kind of certificate anyway.

= The signature algorithms extension also indicates what to sign with,
<= div>and that's not completely determined by the certificate (e.g., with=
RSA).


> Resumption_se= cret: The Key Schedule section mentions a
> resumption_secret = but nowhere in the spec does this keyword
> re-appear. It shou= ld be mentioned somewhere that this is the secret to
> be used= as PSK in a future resumption handshake.

Good cat= ch. This is actually called the resumption master
secret. I'l= l clean this up.


> Auth_modes: t= here is a single mention of "auth_modes" in the
> Pr= e-Shared Key Extension section. No definition of this variable is to
<= div>> be found.

Yeah, this is a holdover from w= hen this field exists. I fixed that.



> Computing Finished keys: The section on how to comput= e Finished keys
> should be in the cryptographic computation s= ection in my opinion. It
> should probably be added to the key= schedule diagram as well.

This made the key sched= ule too hard to read (I note you complain
about that below) so I&= #39;m reluctant to add it. I'd be interested
in other people&= #39;s opinions about whether these computations would
be better i= n this section.


> Computation of= the Binders: From the relevant section: "Each entry in
>= the binders list is computed as an HMAC over the portion of the
= > ClientHello up to and including the PreSharedKeyExtension.identities
> field. That is, it includes all of the ClientHello but not th= e binder
> list itself. The length fields for the message (inc= luding the overall
> length, the length of the extensions bloc= k, and the length of the
> =E2=80=9Cpre_shared_key=E2=80=9D ex= tension) are all set as if the binder were
> present". Th= ere are several things that are unclear to me and I think
> th= ey should be mentioned here: the fake binder should be of size
&g= t; hash.size, it should also say that the HMAC is computed over the
> handshake message containing the client hello, not only the client<= /div>
> hello structure.

I'll see what = I can do here.


> What binder key= to use: It is not clear which binder are to be used
> when do= ing a session resumption. The previous handshake one or the new
&= gt; handshake one? The confusion comes from the fact that the old
> handshake's resumption_secret/PSK is to be used in the new handsh= ake,
> it could be thought that the old handshake's binder= key should be the
> one used in the new handshake as well. I = think it would help if this
> resumption_secret is called some= thing like
> next_handshake.resumption_secret. Or make it clea= rer from which key
> schedule the binder key comes from.
=

I'm not quite following. It's not possible to c= ompute the RMS
at this point in the handshake. The only PSK you c= ould possibly
have is the one from the previous handshake.
<= div>

> PSK and Cipher Suite: I think the fo= llowing fact should be emphasized
> in more places: the client= needs to advertise the single cipher suite
> they previously = used when doing session resumption. It could be added
> to the= cipher_suite definition of the client hello section as well as
&= gt; in the overview of session resumption.

Thanks.= I can add something.


> Implicit= Lengths in The Presentation Language: nested structures +
> i= mplicit lengths =3D trouble. It's easy to forget parsing/writing all
> the different "sizes" when they are not clearly stat= ed in the
> spec. Why not just having a length field in front = of these
> variable-length vectors? It would add a bit of over= head but would make
> things clearer in my opinion.
=
Can you point to the specific structures you are concerned w= ith
here? I think in almost every case we do have length fields. = Actually,
a common complaint is we have too many redundant length= fields.


> No Help For The Imple= menter: If you look at the Noise Protocol
> Framework, you can= clearly see that the specifications were written
> with imple= menters in mind: several states, and objects are
> defined. Fo= r example, one way of implementing TLS is to have some sort
> = of complex state that will remember what state you are in the
>= ; handshake, what is the cryptographic context, etc... here the
&= gt; implementer has to decide everything for himself.

<= div>Most IETF specs leave the choice of how to do things up
to th= e implementor. As someone who has implemented a lot of
specs, I a= ctually find it pretty frustrating when the author
gets all presc= riptive about implementation. If there are
points that are unclea= r, I think it's fine to make them clear,
but I'd rather s= tick to the PDUs.


> Whitelist Of= State Transitions: There is nothing about whitelisting
> stat= e transitions. In my opinion there should be a list of allowed
&g= t; state transitions that the implementer could use. I made one here, I
> suspect it is still missing some states.

I'm going to add a state diagram in -19. This link seems like
<= div>useful input. Thanks.



> How to parse extensions: I think that IANA's consideration s= ection's
> table would be useful to have in the earlier Ex= tension section
> (probably only the extensions included in th= e RFC should be
> listed). Another useful pragraph: how to par= se these extensions,
> making sure that different messages com= e with their own whitelist of
> extensions.

Good point. I'll make this change.


=
> Language <-> Bytes Translation: There are no real int= roduction/no
> clear section about this. I understand that eve= rything is in the
> Presentation Language section but for some= one who discovers the
> specification it takes some time to fi= nd out that this section is
> about both the presentation lang= uage and its byte encoding. A better
> introduction in this se= ction as well as an emphasis on the byte
> representation in e= ach of the subsections of this section would in my
> opinion b= enefit the whole document.

I'm not quite sure = I understand what you're looking for here. Can
you send a PR?=

> Asymmetrical MUSTs: some "MUST" ke= ywords are not symmetrical. What is
> the point of them? For e= xample, the spec says that as a client, you
> MUST use a uniqu= e 0x0303 value in the legacy_version field of the
> client hel= lo. But if you do not, there are no problems from the server
>= side in the specification and the client hello will still be well
> received. (Is this maybe for forward compatibility?)

<= /div>
Amongst other things. MUST do X but must allow X and Y is pretty<= /div>
common in IETF spec.

> And finally, h= ere are some minor nitpicks:
>=C2=A0
> PSK extens= ion: debatable, but I would rather have the PSK section at
> t= he very end of the Extensions section as it MUST be the final
>= ; extension of a client hello.

Yeah, I can do that= .


> No Indication Of Encryption:= This is debatable, but I find it
> inelegant that there are n= o indication in a record that it is
> encrypted. The implement= ation is supposed to keep track of it.

Actually, a= t present everything with first byte =3D=3D application_data
is e= ncrypted and everything else is not.


> What PSK mode does a server support: I think the server should
=
> indicate what mode (psk_dh_ke or psk_ke) it supports in a
> server_hello.psk_mode extension or in the new_session_ticket
<= div>> message. Like that the client would know if it has to send a key_s= hare
> or not in the resumption. Right now, the only indicatio= n of a
> psk_dh_ke is that the server will send a key_share ev= en when presented
> with a PSK. this is debatable.
<= br>
This was a pretty explicit decision to avoid redundancy, so I= think
we have WG consensus here.


> The Key Derivation: The key derivation section is the least c= lear
> section in this specification. The diagrams kind of hel= p, but are
> limited by the RFC format... I have nothing else = to say here, the
> whole section is confusing to say the least= . No solution offered :o)

Yeah, not too sure what = to do.

Thanks,
-Ekr

=

On Wed, Dec= 14, 2016 at 3:38 PM, David Wong <davidwong.crypto@gmail.com&= gt; wrote:

Hello! I read the current specification and I have some feedback on it. I hope this can be useful. Sorry for the length or if I point to obvious=20 things. Here is a link as well for readability: https://g= ist.github.com/mimoo/b6c64a133cd85da53f2f744dcdb39839

  1. 1-Byte Length of Vectors: One edge-case that is= implied and not discussed in the Presentation Language sectio= n is: "do I need to write the length of a vector<0...255>?".= It=20 seems logical that it will always be 1 byte and that it might be an=20 implicit length. It would be nice to have this edge case mentioned or=20 say something along the lines "there are no exceptions when encoding t= he length of variable-length vectors".

  2. Lack of re= petition: The intro diagram tells you what messages are encrypted with what key. But after that, no reminders are present. For example, look at the Finished message. How=20 do you know that this has to be encrypted with the handshake key? It is=20 not written in the Finished message section, it is not written= in the authentication messages parent section and it is not wri= tten in the handshake protocol parent-parent section either. Only = in the overview section.

  3. How to define application d= ata in an application data message: It is not clear how "real" application data should appear in an= =20 application data message. Encrypted handshakes and alerts are clearly=20 defined, but it takes some time to understand that "real" applica= tion=20 data is written -- without structure or metadata -- into the content<= /code> field of a TLSInnerPlaintext message. The current definition is "content: The cleartext of=20 TLSPlaintext.fragment". I think a better one would be "content: t= he byte encoding of a handshake or alert message, or the raw bytes of the=20 application's data to send".

  4. Unencrypted Ap= plication Data: Does it say somewhere in the specification that re= al application data should never appear in a TLSPlaintext mess= age? At the moment the application_data content type is presen= t in the declaration of a TLSPlaintext structure, see the= record layer section

  5. What alert to use= : Sometimes it is not mentioned what level of alert should be used. For example: "Because TLS 1.3=20 forbids renegotiation, if a server receives a ClientHello at any other=20 time, it MUST terminate the connection". I'm guessing it should be= a=20 fatal alert, but this is open to interpretation.

  6. Why= force the signature algorithm extension: If=20 the client does not send a signature algorithm extension, why would the=20 server abort the handshake? It would make more sense to continue with=20 the server's prefered certificate. Especially since currently, most=20 webservers only possess one kind of certificate anyway.

  7. Resumption_secret: The Key Schedule section mention= s a resumption_secret but nowhere in the spec does this keyword re-appear. It should be=20 mentioned somewhere that this is the secret to be used as PSK in a=20 future resumption handshake.

  8. Auth_modes: th= ere is a single mention of "auth_modes" in the Pr= e-Shared Key Extension section. No definition of this variable is to be= found.

  9. Computing Finished keys: T= he section on how to compute Finished keys should be in the cryptographic computation section in my opinion. It should proba= bly be added to the key schedule diagram as well.

  10. Co= mputation of the Binders: From the relevant section: "<= em>Each entry in the binders list is computed as an HMAC over the portion of=20 the ClientHello up to and including the PreSharedKeyExtension.identiti= es field. That is, it includes all of the ClientHello but not the binder=20 list itself. The length fields for the message (including the overall=20 length, the length of the extensions block, and the length of the=20 =E2=80=9Cpre_shared_key=E2=80=9D extension) are all set as if the binder we= re present". There are several things that are unclear to me and = I think they should be mentioned here: the fake binder should be of size hash.size, it should also say that the HMAC is computed over the handshake message containing the client hello, not only the client hello structure.

    11. =

  11. What binder key to use: It is not clear which=20 binder are to be used when doing a session resumption. The previous=20 handshake one or the new handshake one? The confusion comes from the=20 fact that the old handshake's resumption_secret/PSK is to = be used in the new handshake, it could be thought that the old handshake= 9;s binder key should be the one used in the new handshake as = well. I think it would help if this resumption_secret is calle= d something like next_handshake.resumption_secret. Or mak= e it clearer from which key schedule the binder key comes from= .

  12. PSK and Cipher Suite: I think the followi= ng fact should be emphasized in more places: the client needs to advertise the=20 single cipher suite they previously used when doing session resumption.=20 It could be added to the cipher_suite definition of the cl= ient hello section as well as in the overview of session resu= mption.

  13. Implicit Lengths in The Presentation Lan= guage: nested structures + implicit lengths =3D trouble. It's easy to forget parsing/writing all the different "sizes"= ; when they are not clearly stated in the spec. Why not just having a length field=20 in front of these variable-length vectors? It would add a bit of=20 overhead but would make things clearer in my opinion.

  14. No Help For The Implementer: If you look at the Noise Protocol Framew= ork, you can clearly see that the specifications were written with=20 implementers in mind: several states, and objects are defined. For=20 example, one way of implementing TLS is to have some sort of complex=20 state that will remember what state you are in the handshake, what is=20 the cryptographic context, etc... here the implementer has to decide=20 everything for himself.

  15. Whitelist Of State Transitio= ns: There is nothing about whitelisting state transitions. In my opinion there should be a=20 list of allowed state transitions that the implementer could use. I made one here, I suspect it is still missing some states.=

  16. How to parse extensions: I think that IANA's consideration section's table would be useful to = have in the earlier Extension section (probably only the extensions included in the RFC should be listed).=20 Another useful pragraph: how to parse these extensions, making sure that different messages come with their own whitelist of extensions.

    17. Language <-> Bytes Translation: There are no re= al introduction/no clear section about this. I understand that everything i= s in the Presentation Language section but for someone who discovers the specification it takes some=20 time to find out that this section is about both the presentation=20 language and its byte encoding. A better introduction in this section as well as an emphasis on the byte representation in each of the=20 subsections of this section would in my opinion benefit the whole=20 document.

  17. Asymmetrical MUSTs: some "MU= ST" keywords are not symmetrical. What is the point of them? For example, the spec says that as a client, you MUST use a unique 0x0303 value in the = legacy_version field of the client hello. But if you do not, there are no problems from the server side in the=20 specification and the client hello will still be well received. (Is this maybe for forward compatibility?)

And finally, here are some minor nitpicks:

  1. PSK extension: debatable, but = I would rather have the PSK section at the very end of = the Extensions section as it MUST be the final extension of a client = hello.

  2. No Indication Of Encryption: This i= s debatable, but I find it inelegant that there are no indication in a record that=20 it is encrypted. The implementation is supposed to keep track of it.

  3. What PSK mode does a server support: I think the = server should indicate what mode (psk_dh_ke or psk_ke) it supports in a server_hello.psk_mode extension or in t= he new_session_ticket message. Like that the client would know= if it has to send a key_share or not in the resumption. Right= now, the only indication of a psk_dh_ke is that the server wi= ll send a key_share even when presented with a PSK. th= is is debatable.

  4. The Key Derivation: The key derivation section=20 is the least clear section in this specification. The diagrams kind of=20 help, but are limited by the RFC format... I have nothing else to say=20 here, the whole section is confusing to say the least. No solution=20 offered :o)


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


--001a113e7afcb815420543a68d26-- From nobody Thu Dec 15 05:33:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002A8129DF9 for ; Thu, 15 Dec 2016 05:33:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mw6EJNz_OXTc for ; Thu, 15 Dec 2016 05:32:56 -0800 (PST) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27B92129E06 for ; Thu, 15 Dec 2016 05:32:36 -0800 (PST) Received: from vsmta11.fe.internet.bosch.com (unknown [10.4.98.51]) by imta24.fe.bosch.de (Postfix) with ESMTP id ABD4ED8022A for ; Thu, 15 Dec 2016 14:32:33 +0100 (CET) Received: from FE-MBX1028.de.bosch.com (vsgw24.fe.internet.bosch.com [10.4.98.24]) by vsmta11.fe.internet.bosch.com (Postfix) with ESMTP id 984962380AF8 for ; Thu, 15 Dec 2016 14:32:33 +0100 (CET) Received: from SI-MBX1028.de.bosch.com (10.3.230.42) by FE-MBX1028.de.bosch.com (10.3.230.86) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 15 Dec 2016 14:32:33 +0100 Received: from SI-MBX1028.de.bosch.com ([fe80::7007:fad5:927a:8749]) by SI-MBX1028.de.bosch.com ([fe80::7007:fad5:927a:8749%20]) with mapi id 15.00.1236.000; Thu, 15 Dec 2016 14:32:33 +0100 From: "Guballa Jens (ETAS-PSC/ECS)" To: "" Thread-Topic: Comments to draft tls13-18 Thread-Index: AdJW1uIl07QSarVeRrSVWZuaTFLpQA== Date: Thu, 15 Dec 2016 13:32:32 +0000 Message-ID: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.51.202.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22762.006 X-TMASE-MatchedRID: u1Xtt3oEOtztvMVN/9JMysOD5TU1KZy5ndxf4OzpbpUifM7JMNHW64VG SsTJg+GwpjrJZBOf8KWqNKtXzrfKOw6X1bDqRHQvx7fVVD7rJEYk227IvqakhXWXr1sFb6UMnKq rYXAdNPkElX/4Ddnz21N9cI96Auq9e6k6FRH8ATzKUCo1O3wV1TNzwULQwTBP7Qe/arRorfciZ2 mNBMfNjmUwDbZVcebYVXTSNxNaGK8hTepmATUdcGA/V00XWjDtCIFiJP1XZ1KdCqKtxM6bh4wEq dFURqRO5xC/qJe4DOvLwpYQMCaC/gck7cI1BHLXaUe/i9AephPEGBoHKd3a+Zy1Yc8tPkV92l7l NOxDn+9ccPKQhw1TL+z+RVhPYXWB+1u//cLHI3WG/X7YnfJAXJaFO9XLY12UWltirZ/iPP5+e8r YMu+FQQhigAXT8ZTBWUSYx5XXZSyUdUEuMEOuOfp1plqEbuqxOWC3YQn1rYRVLi5P3sIGbaT1Kz wxSYQs8c0FK1vDjSdH70eV7/rWmweK3sUEdcSOJhFEQZiq2ZSX0a4/nZwXLJMxNpDOG+h6Z10wK XUWXnLmx5fd6ZHxSh9Xd2v9YOwBEbjpuHFTtb7h2jIMO0GTgdUEOicf335W9YBezwhBfW6Ebxse jHjmIrZe6oeeaP37hY5WdwGO5jc3KXWd30Ii3f7E6GNqs6cerSFs54Y4wbX6C0ePs7A07SQvY0u eKrc1nZ53LSqEdda6VddR6AEokcAQULEEk+LMH/YyfJCvsw8= Archived-At: Subject: [TLS] Comments to draft tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2016 13:33:00 -0000 Hi all, I had a closer look at the TLS1.3-18-draft, and I would like to provide som= e comments. My overall impression is that too less attention has been put on a clear an= d precise terminology. - Throughout the draft the term "connection" refers to a TLS connection, bu= t in section 1.1 "connection" it is defined as a transport layer connection= . I would prefer a definition similar as provided by RFC 5246. - Use of inconsistent terms for what a handshake produces:=20 At section 1.1: "handshake: An initial negotiation between client and ser= ver that establishes the *parameters of their transactions*." -> Note, the term transaction is not used anywhere else in the draft At page 13 (section 2): "The cryptographic *parameters of the session sta= te* are produced by the TLS handshake protocol, ..." At page 15: "The server processes the ClientHello and determines the appr= opriate cryptographic *parameters for the connection*. It then responds with its own ServerHello, which indicates the negotiated connection parameters." At page 17 (section 2.2): "The client can then use that PSK identity in future handshakes to negotiate use of the PSK. If the server accepts it, then the *security context* of the new connection is tied to the original connection." At page 27 (section 4.1): "The key exchange messages are used to exchange= *security capabilities* between the client and server and to establish the traffic keys used to protect the handshake and data. At page 75 (section 7.1): "The TLS handshake establishes one or more *inp= ut secrets* which are combined to create the actual *working keying material*, as detailed below." - The terms "working keys", "traffic keys" are not clearly defined and used= inconsistently, IMO. "Traffic key" seems to refer to 0-RTT-keys, handshake keys and applicatio= n keys in most parts of the draft, on the other hand on page 78 (section 7.= 2): "Once the handshake is complete, it is possible for either side to update its sending *traffic keys* using the KeyUpdate handshake message defined in Section 4.5.3." -> Here "traffic key" seems to refer to application keys only. I would prefer a clear definition of those key related terms in section 1= .1. - Page 16 (section 2): "CertificateVerify: a signature over the entire handshake using the public key in the Certificate message." IMO, "entire handshake" would include the "Finished" from both sides, whi= ch I believe is not intended. Also, from the text one could think that the public key is used to genera= te the CertificateVerify. Proposal: "...using the public key in the Certificate message at the rece= iving side for the verification of the signature." - Page 17 (section 2.2): "The client can then use that PSK identity in future handshakes to negotiate use of the PSK. If the server accepts it, then the security context of the new connection is tied to the original connection." What does "is *tied* to" mean? - Page 26 (section 4): "Handshake messages are supplied to the TLS record l= ayer, where they are encapsulated within one or more TLSPlaintext or TLSCiphertext structures, which are processed and transmitted as specified by the current active session state." The TLS record layer has no view on the session state, IMO. Therefore I t= hink "as specified by the current active connection state" or "...by the cu= rrent traffic keys" makes more sense. - Page 44 (section 4.2.6): "External tickets SHOULD use an obfuscated_ticket_age of 0; servers MUST ignore this value for external tickets." I would avoid the term "external ticket", I think it is more confusing th= an it helps. Proposal: "For PSKs provisioned out of band, obfuscated_ticket_age SHOULD= be set to 0 by the client; servers MUST ignore this value for those PSKs." - Section 4.4.2. Certificate Verify There is no procedure defined for the receiver, I would expect that the r= eceived MUST verify this message. I would also prefer to have the procedure specified in case the verificat= ion fails (also valid for the Finished message). - Page 108 (appendix C.4): "If an implementation negotiates use of TLS 1.2,= then negotiation of cipher suites also supported by TLS 1.3 SHOULD be preferred, if=09 available." TLS cipher suites for TLS1.3 and TLS1.2 are disjunctive, in my understand= ing. Therefore I think this sentence does not make any sense. Unfortunately the semantic of "cipher suite" has been changed from TLS1.2= to TLS1.3, thus there are different definitions of this term for both TLS = versions. - Page 110 (appendix D.1): I am not quite sure if the term "session key" is= needed at all. IMO, it is just a synonym for "master secret".=20 My proposal is to replace "session key" by "master key" throughout the co= mplete document. - Page 110 (appendix D.1): "Uniqueness of the session key: Any two distinct= handshakes should produce distinct, unrelated session keys." I am not sure what "unrelated" means here. If two session keys are derive= d from the same PSK without (EC)DHE, I would regard them as "related" (but = both are still unique).=20 - Page 111 (appendix D.1): "The PSK and resumption-PSK modes bootstrap from= a long-term shared secret into a unique per-connection short-term session key." I do not understand the intention of this sentence. If a session key (master secret) is regarded as short-term, then conseque= ntly the resumption-PSK mode bootstrap from a short-term shared secret (mas= ter key from another session). =20 - Section 8.1 and 8.2: I would replace "MTI" by "Mandatory to implement".=20 - General: "out-of-band PSKs" vs. "handshake-derived PSKs": An "out-of-band= PSK" (i.e., deployed out of band and a priori trusted) is not the same as = a "handshake-derived PSK" which has been established via authenticated key = agreement. In real-world deployments, these keys might be protected differe= ntly (e.g., an out-of-band PSK might be stored in an HSM, hardware security= module). However, a handshake-derived shared secret might be located in RA= M (i.e., it is not necessarily equally well suited for endpoint authenticat= ion as a long-term key). Best regards, Jens From nobody Thu Dec 15 16:09:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A99D129B4E for ; Thu, 15 Dec 2016 16:09:37 -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 9zQDKGsm6VMD for ; Thu, 15 Dec 2016 16:09:35 -0800 (PST) Received: from mail-qt0-x241.google.com (mail-qt0-x241.google.com [IPv6:2607:f8b0:400d:c0d::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 54249129B1C for ; Thu, 15 Dec 2016 16:09:35 -0800 (PST) Received: by mail-qt0-x241.google.com with SMTP id m48so8929161qta.2 for ; Thu, 15 Dec 2016 16:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=XD0fv+l/JHuhmW+LQmFhTDvrClH/8+y9m1BsQJCWhpk=; b=R8DWaQ20r3C2M0jtV97ySsWfNRTMQIg15UXrEPRWrr354e3SYAsm1Apso58jcGnnZK lwQgZsm/60sS9Xryo3qds7NKAkInm2EVh6jUGbTEdv3m6WTApCMCly+6MjVZNvCm3CsD D3m4YAV+/mML663do/bfxmbm5zixg708eLog3wH3w8WN1WZV/A/AX0T5/ofU63UdCb9I lojeJg0SlTlBDVgnY+2TPyhGJ8d6jVvLukfDorKbMDuORCJHRvFu0GLttSa+mlAuqoLB qhlxkrruUvS2OY7D35BolYx0MhcA5obcDIbuXhHHNZu/VyQl+MFnN+b5X++TrZW0n552 nciA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=XD0fv+l/JHuhmW+LQmFhTDvrClH/8+y9m1BsQJCWhpk=; b=EEF/3ev+u9vddHr68WL89M/7g8DdsRjOH0XWDW1rSdLnC389JwwTh/vAayeff8RclV wzbQNcAHZvsHZ0QKjWe24LA3ArNJSIeMQhHDwomgSHo9+r/gs3ooHqKeSrtXpdulpHiY CJOagQqDOY4HkrLLh5AuROoE3QpvMw9/rkEKaJm85HCqB7HsHi2kCGsOcMeAtysO5MO8 UtuheiS8x3qVqZS6ix2/aKZlFaeC/M2k3jmJIcva5ZdizmFzwGTun7PEFXOPFHtNttD0 jgUtxIqRd3Vm1fJ50fBtyzm/u4AnpbttK6G2xeRQap/K1d3efI4eORiaaiC1qDkLN+6L 4mbA== X-Gm-Message-State: AIkVDXIqCCHxczGWo54qm9QgMZNDnr9Ussqu6gqOEnJc9QY2NRVZJi3WIVqA1tUBuF/Tww== X-Received: by 10.200.56.20 with SMTP id q20mr165588qtb.178.1481846974454; Thu, 15 Dec 2016 16:09:34 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-27-43.phlapa.fios.verizon.net. [71.175.27.43]) by smtp.gmail.com with ESMTPSA id 6sm2384910qke.18.2016.12.15.16.09.33 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 15 Dec 2016 16:09:33 -0800 (PST) From: Dave Garrett To: "Guballa Jens (ETAS-PSC/ECS)" Date: Thu, 15 Dec 2016 19:09:31 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> In-Reply-To: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201612151909.32142.davemgarrett@gmail.com> Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Comments to draft tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 00:09:37 -0000 On Thursday, December 15, 2016 08:32:32 am Guballa Jens (ETAS-PSC/ECS) wrote: > - Page 108 (appendix C.4): "If an implementation negotiates use of TLS 1.2, then negotiation of > cipher suites also supported by TLS 1.3 SHOULD be preferred, if > available." > TLS cipher suites for TLS1.3 and TLS1.2 are disjunctive, in my understanding. Therefore I think this sentence does not make any sense. > Unfortunately the semantic of "cipher suite" has been changed from TLS1.2 to TLS1.3, thus there are different definitions of this term for both TLS versions. I've already updated this sentence for draft 19. https://tlswg.github.io/tls13-spec/#backwards-compatibility-security-restrictions Dave From nobody Fri Dec 16 00:20:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96D4E129861 for ; Fri, 16 Dec 2016 00:20:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8p5QXDoCaW66 for ; Fri, 16 Dec 2016 00:20:38 -0800 (PST) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755CE1294DF for ; Fri, 16 Dec 2016 00:20:38 -0800 (PST) Received: from vsmta11.fe.internet.bosch.com (unknown [10.4.98.51]) by imta24.fe.bosch.de (Postfix) with ESMTP id 2BC12D80226 for ; Fri, 16 Dec 2016 09:20:36 +0100 (CET) Received: from FE-MBX1027.de.bosch.com (vsgw24.fe.internet.bosch.com [10.4.98.24]) by vsmta11.fe.internet.bosch.com (Postfix) with ESMTP id 18C542380DE6 for ; Fri, 16 Dec 2016 09:20:36 +0100 (CET) Received: from SI-MBX1028.de.bosch.com (10.3.230.42) by FE-MBX1027.de.bosch.com (10.3.230.85) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 16 Dec 2016 09:20:35 +0100 Received: from SI-MBX1028.de.bosch.com ([fe80::7007:fad5:927a:8749]) by SI-MBX1028.de.bosch.com ([fe80::7007:fad5:927a:8749%20]) with mapi id 15.00.1236.000; Fri, 16 Dec 2016 09:20:35 +0100 From: "Guballa Jens (ETAS-PSC/ECS)" To: "" Thread-Topic: Comments to draft tls13-18 Thread-Index: AdJW1uIl07QSarVeRrSVWZuaTFLpQAAncWdw Date: Fri, 16 Dec 2016 08:20:35 +0000 Message-ID: References: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> In-Reply-To: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.51.202.94] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00AB_01D2577D.A78CB270" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22762.006 X-TMASE-MatchedRID: UC2IOhNOHTdS/isIEXGDv8pQKjU7fBXV4+ZcrqvCDkEFXFSkfaz0cXFD 0I0jlEDd1hcP/Djs8WMwfhEWn1dVOuzxNaI2BL2hiQy4MG/9Stm063Wh9WVqgnUIH+25YvS8k9Y 5gtIHq9H4XGCabqlxSLI7zVffJqTzmoHr97776Hhq8ZocDaaOZBggslv8KztSigmshCrGnZcWfC lY+mwuOFy99qPmMBnyOpA/QRazfJycftLzbAX/DrEkTPopoUea Archived-At: Subject: Re: [TLS] Comments to draft tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 08:20:41 -0000 ------=_NextPart_000_00AB_01D2577D.A78CB270 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, > - Page 110 (appendix D.1): I am not quite sure if the term "session key" > is needed at all. IMO, it is just a synonym for "master secret". > My proposal is to replace "session key" by "master key" throughout the > complete document. [JG] Sorry, "master key" is wrong. I meant s/session key/master secret/ Thanks, Jens ------=_NextPart_000_00AB_01D2577D.A78CB270 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXKzCCBLcw ggOfoAMCAQICBEMB0LowDQYJKoZIhvcNAQELBQAwUDETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFDASBgNVBAMTC0Jvc2NoLUNBLURFMB4X DTE1MDUxMjA5NDgxMFoXDTI1MDUxMjEwMTgxMFowUTETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKAkjDSX1bM0BhiJa3jlD/DiW+shP849/Bty QKlL7o+Lfdp1GZrW5cHdlg6ks4X8gd3zlpYC+JeWd1clUf2BBHlJKyOHR2caOMnSsNsbDYQ984O8 4dnWS8ex2Jiw+j+wNTtCgL3OhuGTxMIWlWfOhtlzMvz3dqqtMpaYnqzoYb/t+Uzzjg8W0/KdCM60 7M6ic2jpghz1sr5j9N5qYF/ETQWQnNoPdAzohs0bk2W02wVyayVjSVDVK6cPAnBnVzaFv+1NV5ms 53MlmQkgSg7SkRs1xwKsg5MSOsDDL+dn9bi9UU1aYNXFTefUEcHUTsjpk7REV+NQo72O97JfUKOK t18CAwEAAaOCAZYwggGSMIIBGAYDVR0fBIIBDzCCAQswZ6BloGOkYTBfMRMwEQYKCZImiZPyLGQB GRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEUMBIGA1UEAxMLQm9z Y2gtQ0EtREUxDTALBgNVBAMTBENSTDEwgZ+ggZyggZmGVWxkYXA6Ly9ib3NjaC5jb20vY249Qm9z Y2gtQ0EtREUsY249UEtJLGRjPUJvc2NoLGRjPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0 P2Jhc2WGQGh0dHA6Ly90cnVzdGNlbnRlci5ib3NjaC5jb20vQ1JML2Jvc2NoLWNhLWRlX3BraV9j b21fY3JsZmlsZS5jcmwwCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFB6lPyKiCCEbxVgo0R8t8PP4 +RUpMB0GA1UdDgQWBBTeBOLMiQj9dYzYpDAx2BBt5aH0mzAMBgNVHRMEBTADAQH/MBkGCSqGSIb2 fQdBAAQMMAobBFY4LjEDAgCBMA0GCSqGSIb3DQEBCwUAA4IBAQBITOZpOW3DTD72K7WDq5Zh5eHf zeg4FC3xDZ9nj4bs+ObFx+zInsdisYlycj5rlsMjDrS+hNKBCPVsL/JyIgelTb7fHXkl5m2ifsqn wv0YR7Tk509ooHdVXTLmZV4AjyeXUmKXXh+QkK9DiHhU6sLdkPej4gBolemqD0SVrzd7F+ZqHAvg cQtcRMVc+rkADrC2pytD90XpqDl2I5RdnNSfVpo7FsP5zHayNBIBiHBhmVPhgMUCjjxNGuMGTC74 AqqATrAKI3zEADbBoohOlaHmfnurGHHU21IAgXYYz4vngqapYWiTo2dRPuqhaZDNp4tXhBYzqunA YTfXLzo6qbXpMIIE+jCCA+KgAwIBAgIEQwG2sjANBgkqhkiG9w0BAQUFADBQMRMwEQYKCZImiZPy LGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEUMBIGA1UEAxML Qm9zY2gtQ0EtREUwHhcNMDUwODE2MDkxOTQyWhcNMjUwODE2MDk0OTQyWjBQMRMwEQYKCZImiZPy LGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEUMBIGA1UEAxML Qm9zY2gtQ0EtREUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDADDavsLqpxKnP+mAB iNavAOpR8EK4o7E1NxRj//V6gVHdLw9EnRY+CeX6KAf6CjW3X+VRzQMZOMxcj4Hn9T2/hvApgjr4 asLHduTYlNlSPBLH1c0rDBJRj4SllBtkHx4g7eelVWzWT4k2vIgxNtwAR0x+dghgObQBMGnPYGsE RYQ62JU4c3Z3yNVOOCtSh+3J9m+8zMSvPKKpiqK4D5QfhMjJDvOAgJRzkQLnJHTATLhF5Jp0phWU HJGeChwoncbhYX13AnEpqccGrid+ZdKYIFDs/I8t505VTzvQ8O0yMkYc1RLIfXMsDeullW+00lml FylcqXXMStOMhyYii4XXAgMBAAGjggHaMIIB1jARBglghkgBhvhCAQEEBAMCAAcwggEYBgNVHR8E ggEPMIIBCzBnoGWgY6RhMF8xEzARBgoJkiaJk/IsZAEZFgNjb20xFTATBgoJkiaJk/IsZAEZFgVC b3NjaDEMMAoGA1UEAxMDUEtJMRQwEgYDVQQDEwtCb3NjaC1DQS1ERTENMAsGA1UEAxMEQ1JMMTCB n6CBnKCBmYZVbGRhcDovL2Jvc2NoLmNvbS9jbj1Cb3NjaC1DQS1ERSxjbj1QS0ksZGM9Qm9zY2gs ZGM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZYZAaHR0cDovL3RydXN0Y2VudGVy LmJvc2NoLmNvbS9DUkwvYm9zY2gtY2EtZGVfcGtpX2NvbV9jcmxmaWxlLmNybDArBgNVHRAEJDAi gA8yMDA1MDgxNjA5MTk0MlqBDzIwMjUwODE2MDk0OTQyWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgw FoAUHqU/IqIIIRvFWCjRHy3w8/j5FSkwHQYDVR0OBBYEFB6lPyKiCCEbxVgo0R8t8PP4+RUpMAwG A1UdEwQFMAMBAf8wHQYJKoZIhvZ9B0EABBAwDhsIVjcuMTo0LjADAgSQMA0GCSqGSIb3DQEBBQUA A4IBAQBkQ/eOR9L4eenoIddXw7SjnJDnfsgZIaJNsnJ8afxgJjvot/U6AjnmPo7Waa5gyEIS9EEE mAubTwU30NyhHCr8iHjFDWhbSa9Waajb81i6WgklpjM6T1D+RuEO1Ty6sWgPsfx3bZLITQyoXr33 nRokVmKshjwtEU05BKRXgvk7ma9HGCV1lOtwdjHKcK17mE2FHGbFNm/o6P9CkN4P3jdmpWKSb791 5Cz9wdNPOl0IBcSlwH7j3D8YEfbkrDkk2UYPccZUzMkPi6+WhlUmwkc0ea+Fa+pjGBsZ7AEfRCcV Zaz3fjluyBWjuWRa5bY3P86UdjQplcobWrovoIwehkyRMIIGjjCCBXagAwIBAgIEQ2J0ADANBgkq hkiG9w0BAQsFADBRMRMwEQYKCZImiZPyLGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gx DDAKBgNVBAMTA1BLSTEVMBMGA1UEAxMMQm9zY2gtQ0ExLURFMB4XDTE2MTIxMzEzMTIzNVoXDTE5 MTIxMzEzNDIzNVowgYYxEzARBgoJkiaJk/IsZAEZFgNjb20xFTATBgoJkiaJk/IsZAEZFgVib3Nj aDEMMAoGA1UEAxMDcGtpMQ4wDAYDVQQDEwVCT1NDSDELMAkGA1UEAxMCREUxCjAIBgNVBAMTAUox CjAIBgNVBAMTAUUxFTATBgNVBAMTDEplbnMuR3ViYWxsYTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAK59uLjqNeweDpPkjdEsVAGfz5PXTtSskmdMlqgkg5otcrYoj+dYCNmBqmisvYri wqY56jf2QBAm8bkjxMQPgox+k4kYA/SsLuQY131ADyzhhvDbX/3PLIeLeE0TIgOMBDcjrJIJxuYc 3efy1u2cnEZyJ+PHBZstVTc+5+K5Ky4Ql7QkoVzJFJgX5zDeAQyotZzZ6s3b+MoXKugPBkK0dsCz amxFynbVYV8RL6GMfNPFqg/Xo2ee75w3w0P3VJ4NWKT1MVJXFY4Zago+8M4uZxUPsuvg+SNVStDO hWCidmY6L7n3lo2W42/LDw0aJ5wVc9x4VFHLqLtlVWjv4E3Kh98CAwEAAaOCAzYwggMyMAsGA1Ud DwQEAwIFIDAeBgNVHSUEFzAVBggrBgEFBQcDBAYJKwYBBAGVEQUBMIIBRgYDVR0gBIIBPTCCATkw ggE1Bg0rBgEEAalGg30BAgEBMIIBIjAsBggrBgEFBQcCARYgaHR0cDovL3RydXN0Y2VudGVyLmJv c2NoLmNvbS9jcHMwgfEGCCsGAQUFBwICMIHkGoHhVGhlIEJvc2NoIENlcnRpZmljYXRpb24gUHJh Y3RpY2UgU3RhdGVtZW50IChDUFMpIGF2YWlsYWJsZSBhdCBodHRwOi8vdHJ1c3RjZW50ZXIuYm9z Y2guY29tL2NwcyBpcyBoZXJlYnkgaW5jb3Jwb3JhdGVkIGludG8geW91ciB1c2Ugb3IgcmVsaWFu Y2Ugb24gdGhpcyBDZXJ0aWZpY2F0ZS4gVGhpcyBDUFMgY29udGFpbnMgbGltaXRhdGlvbnMgb24g d2FycmFudGllcyBhbmQgbGlhYmlsaXRpZXMuMCAGA1UdEQQZMBeBFUplbnMuR3ViYWxsYUBldGFz LmNvbTCCAS8GA1UdHwSCASYwggEiMGugaaBnpGUwYzETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERTEQ MA4GA1UEAxMHQ1JMMjIyMjCBsqCBr6CBrIZmbGRhcDovL2Jvc2NoLmNvbS9jbj1XaW5Db21iaW5l ZDIsY249Qm9zY2gtQ0ExLURFLGNuPVBLSSxkYz1Cb3NjaCxkYz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlhkJodHRwOi8vdHJ1c3RjZW50ZXIuYm9zY2guY29tL0NSTC9ib3NjaC1j YTEtZGVfcGtpX2NvbV9jcmxmaWxlMi5jcmwwHwYDVR0jBBgwFoAU3gTizIkI/XWM2KQwMdgQbeWh 9JswHQYDVR0OBBYEFPiN5cC6K62XZu/Zu6CSv7hhpSJAMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EA BAwwChsEVjguMQMCBLAwDQYJKoZIhvcNAQELBQADggEBAHDh6aq0mgFY8lXAJoN2NI18OF5i8CWt gTDqrns6isJxDHaLGjqgeEUcZSmY54f365Ho6io8j+Xr9CNBX1hnHOUH1A16VrWqW0BPWXUO1+rk R6t0HRLmFzEM2Jst5C5cTZucR8j3h7zSx+JWDgPOtGNg6H9XrryH43P6PaVejvPoMTByHjEOxMU8 9RN6OOTrD4zyVh+mX6kis+kFwIfp1kJ/GUk4SOpB3kV9DxLkIZfoyNAZhtZ+izLQZk17YPDPAb3E Vtz6w8A+RMef5pTdPhdZLqde2K3CN3cJvTJoEOCWkwOO0Z67y4H4UGR8dwAX6ebha9SXuEtP1RGr XKTYkK4wggbcMIIFxKADAgECAgRDYnY/MA0GCSqGSIb3DQEBCwUAMFExEzARBgoJkiaJk/IsZAEZ FgNjb20xFTATBgoJkiaJk/IsZAEZFgVCb3NjaDEMMAoGA1UEAxMDUEtJMRUwEwYDVQQDEwxCb3Nj aC1DQTEtREUwHhcNMTYxMjE0MTI0MjI4WhcNMTkxMjE0MTMxMjI4WjCBhjETMBEGCgmSJomT8ixk ARkWA2NvbTEVMBMGCgmSJomT8ixkARkWBWJvc2NoMQwwCgYDVQQDEwNwa2kxDjAMBgNVBAMTBUJP U0NIMQswCQYDVQQDEwJERTEKMAgGA1UEAxMBSjEKMAgGA1UEAxMBRTEVMBMGA1UEAxMMSmVucy5H dWJhbGxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnsORNxL2PTGGFOiPkz+PdQqq HnHThJQE13A4haBp369A1J3NXXIsgrrULByynlJNAvEKuO+E79y1pQU2DuPyzmPRnRG4x3qu0Xyf /d+6VFwrrPuhzw38MXroodUMZ0aRBhq49fNUzv+E8El1ZQCNxi52rQHZFn0B0aNcDBaKB2/GYbu+ Q6k1pyVoOc4gBILR84kGiTKdkRchL5JWD6LLoVhvhTH9JYiipjdf0o3K6gDdNMxTeOIUGQEql8BM rWisEE73eYQfTFPEx+4JrgkJD9LRZyN7VT+iFe7727lcvmBFLoguVuRxVH10VJOIhP8Iqv5PN+cM SUqYv1ujyOZJvQIDAQABo4IDhDCCA4AwCwYDVR0PBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDCCAUYGA1UdIASCAT0wggE5MIIBNQYNKwYBBAGpRoN9AQIBATCCASIwLAYIKwYB BQUHAgEWIGh0dHA6Ly90cnVzdGNlbnRlci5ib3NjaC5jb20vY3BzMIHxBggrBgEFBQcCAjCB5BqB 4VRoZSBCb3NjaCBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0YXRlbWVudCAoQ1BTKSBhdmFpbGFi bGUgYXQgaHR0cDovL3RydXN0Y2VudGVyLmJvc2NoLmNvbS9jcHMgaXMgaGVyZWJ5IGluY29ycG9y YXRlZCBpbnRvIHlvdXIgdXNlIG9yIHJlbGlhbmNlIG9uIHRoaXMgQ2VydGlmaWNhdGUuIFRoaXMg Q1BTIGNvbnRhaW5zIGxpbWl0YXRpb25zIG9uIHdhcnJhbnRpZXMgYW5kIGxpYWJpbGl0aWVzLjBC BgNVHREEOzA5gRVKZW5zLkd1YmFsbGFAZXRhcy5jb22gIAYKKwYBBAGCNxQCA6ASDBBnYmo5ZmVA Ym9zY2guY29tMIIBLwYDVR0fBIIBJjCCASIwa6BpoGekZTBjMRMwEQYKCZImiZPyLGQBGRYDY29t MRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEVMBMGA1UEAxMMQm9zY2gtQ0Ex LURFMRAwDgYDVQQDEwdDUkwyMjIyMIGyoIGvoIGshmZsZGFwOi8vYm9zY2guY29tL2NuPVdpbkNv bWJpbmVkMixjbj1Cb3NjaC1DQTEtREUsY249UEtJLGRjPUJvc2NoLGRjPWNvbT9jZXJ0aWZpY2F0 ZVJldm9jYXRpb25MaXN0P2Jhc2WGQmh0dHA6Ly90cnVzdGNlbnRlci5ib3NjaC5jb20vQ1JML2Jv c2NoLWNhMS1kZV9wa2lfY29tX2NybGZpbGUyLmNybDArBgNVHRAEJDAigA8yMDE2MTIxNDEyNDIy OFqBDzIwMTkxMjE0MTMxMjI4WjAfBgNVHSMEGDAWgBTeBOLMiQj9dYzYpDAx2BBt5aH0mzAdBgNV HQ4EFgQU7zHzHbRQfrCZKNIpxXAhm4UNoqAwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRW OC4xAwIEsDANBgkqhkiG9w0BAQsFAAOCAQEAQhXBnRdtUfXuHnZ4/tHaGQh49p/yH1LdfZYcEjtH 0PdLaVCNgpEp5cdIyr/9aQ17OMVTVZk1LeQ1QQ9LYoWTzdXgvbfZWgrL7JhWeFlcyC0vWUwyCYgU ayC2wF+4T4jUvZQQV0uob/n3H+TG/uanRN1R+1lZBBSDU1Qn+B2ECQdxurdjL7S5as1t2ohHG3oW iK0eOJpTzvT/coglaiwa2DPiNoYFyFdyUf3PFSgfzUW1FOTmoXuIbJpJFGnWzKazJFjuHXc+a88m wsWcuhdqfpvHaUtfr5vjT5BqTffwH2hC78PYlMwJV+WSkxTbnKpl03Wb9EzaxS3Q5MuL6ME4CjGC At0wggLZAgEBMFkwUTETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMGCgmSJomT8ixkARkWBUJvc2No MQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERQIEQ2J2PzAJBgUrDgMCGgUAoIIB WTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMTYwODIwMzRa MCMGCSqGSIb3DQEJBDEWBBRLn6i3chgO8qFhPmjiPzCFxz96NDAkBgkqhkiG9w0BCQ8xFzAVMAoG CCqGSIb3DQMHMAcGBSsOAwIaMGgGCSsGAQQBgjcQBDFbMFkwUTETMBEGCgmSJomT8ixkARkWA2Nv bTEVMBMGCgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNB MS1ERQIEQ2J0ADBqBgsqhkiG9w0BCRACCzFboFkwUTETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERQIE Q2J0ADANBgkqhkiG9w0BAQEFAASCAQCDh4gONO34fLMQIoxCuJtfYDaUZxB/FaTP2Ad1YLBMeyzl vag/L19kU4CtIUd7/I51baD0HRSXclTzlKq46vM85z7HcRAUpVmmAG/l4+OGGRQqd+AVMONjANZg VIn71iNoncnpuDzFUgUunSh0/rqBhfZC7/PdgM07YZUZM4Z4msCq9VZ6IsneasKDaRJKu0aYWS1a kU+h3rrY7ZFb7adX4RHBNtNX9Q+XBJ0YaQZDL2hZImgU65iyAPfXuJWiH92TemTU4KVv3AMxMD9x 3/+1LDN6GSOosJA3Fy6oCPWmOenm9PgB1Xe9HY7u1kO4Jwu3El5oC5TVB7xYq4EA7QxTAAAAAAAA ------=_NextPart_000_00AB_01D2577D.A78CB270-- From nobody Fri Dec 16 00:27:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB5E1294F0 for ; Fri, 16 Dec 2016 00:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XoanVsYjVRNY for ; Fri, 16 Dec 2016 00:26:59 -0800 (PST) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0927A126579 for ; Fri, 16 Dec 2016 00:26:59 -0800 (PST) Received: from vsmta12.fe.internet.bosch.com (unknown [10.4.98.52]) by imta24.fe.bosch.de (Postfix) with ESMTP id 86104D80219; Fri, 16 Dec 2016 09:26:57 +0100 (CET) Received: from FE-MBX1027.de.bosch.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta12.fe.internet.bosch.com (Postfix) with ESMTP id 16EAF1B80E18; Fri, 16 Dec 2016 09:26:57 +0100 (CET) Received: from SI-MBX1028.de.bosch.com (10.3.230.42) by FE-MBX1027.de.bosch.com (10.3.230.85) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Fri, 16 Dec 2016 09:26:56 +0100 Received: from SI-MBX1028.de.bosch.com ([fe80::7007:fad5:927a:8749]) by SI-MBX1028.de.bosch.com ([fe80::7007:fad5:927a:8749%20]) with mapi id 15.00.1236.000; Fri, 16 Dec 2016 09:26:56 +0100 From: "Guballa Jens (ETAS-PSC/ECS)" To: Dave Garrett Thread-Topic: [TLS] Comments to draft tls13-18 Thread-Index: AdJW1uIl07QSarVeRrSVWZuaTFLpQAAUWiCAABNgx+A= Date: Fri, 16 Dec 2016 08:26:56 +0000 Message-ID: <52d0201dbf5d46ea84286972b555e240@SI-MBX1028.de.bosch.com> References: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> <201612151909.32142.davemgarrett@gmail.com> In-Reply-To: <201612151909.32142.davemgarrett@gmail.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.51.202.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22762.006 X-TMASE-MatchedRID: Mrekcva/5Pncx97ZZVZcMvHkpkyUphL9uSSRMvdiOIwn8Z1TKUDIT1k/ EVZFlSouU/1Wmmrq/TvDteTaPXH9zZrQgpf6MYzTU+OjsPhIWDiFXSyuOiq3H2FvrBhrTi4d2c5 16rvzqrtbsL+FtURPoUzzk5JWaciPx+CTeBrDwI7mAId+2bAQwqTYf9v9flolmyiLZetSf8l/KM EkOe61SFBIVsvVu9ABIAcCikR3vq8FuLRc+XvdUgrmEcy+rZiPV1uO4Lp/olO1ee9pIbAa/bNLh zuDbDOR Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments to draft tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 08:27:01 -0000 > > - Page 108 (appendix C.4): "If an implementation negotiates use of TLS > 1.2, then negotiation of > > cipher suites also supported by TLS 1.3 SHOULD be preferred, if > > available." > > TLS cipher suites for TLS1.3 and TLS1.2 are disjunctive, in my > understanding. Therefore I think this sentence does not make any sense. > > Unfortunately the semantic of "cipher suite" has been changed from > TLS1.2 to TLS1.3, thus there are different definitions of this term for > both TLS versions. > > I've already updated this sentence for draft 19. > https://tlswg.github.io/tls13-spec/#backwards-compatibility-security- > restrictions > > > Dave [JG] Ah, Ok. This fixes the issue. Thanks, Jens From nobody Fri Dec 16 11:29:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48AAA129B88 for ; Fri, 16 Dec 2016 11:29:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aViP7hBVzNFf for ; Fri, 16 Dec 2016 11:29:22 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 208AE129B87 for ; Fri, 16 Dec 2016 11:29:22 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6FF7C4334A5; Fri, 16 Dec 2016 19:29:21 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 5973B43345A; Fri, 16 Dec 2016 19:29:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1481916561; bh=7kubr8FptrUBOpg2zSFg696BKpZOL94fzoPQs8rO0mQ=; l=1988; h=To:References:From:Date:In-Reply-To:From; b=WrW680GogZoLyT0igud+BZBeQ26UXBgzY5zbhYpfDQO/h2MpXvtRtrDOtdJJeDZ9i hduG+ASlB1v54R0Mr9x+I1cQWrIktL2PrkuvQm2V3CksKveYiQTX+vSAJ0v6sXEWzI 9aHWNUOKWzzglZIJLY5A8fuIkTduLZr7XLsj+L2o= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 288031FC8E; Fri, 16 Dec 2016 19:29:21 +0000 (GMT) To: "Guballa Jens (ETAS-PSC/ECS)" , "" References: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> From: Benjamin Kaduk Message-ID: <4d999633-466e-6f25-e1ef-b0e8c85f5d76@akamai.com> Date: Fri, 16 Dec 2016 13:29:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> Content-Type: multipart/alternative; boundary="------------38DF947153D1209C855D4938" Archived-At: Subject: Re: [TLS] Comments to draft tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 19:29:23 -0000 This is a multi-part message in MIME format. --------------38DF947153D1209C855D4938 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 12/15/2016 07:32 AM, Guballa Jens (ETAS-PSC/ECS) wrote: > Hi all, > > I had a closer look at the TLS1.3-18-draft, and I would like to provide some comments. > > My overall impression is that too less attention has been put on a clear and precise terminology. > Yes, that has not been a focus, and the document has evolved a lot over time. Several of the points you note already have pull requests outstanding that fix them (in addition to the one Dave noted). Someone will need to put the time in to create a patch to resolve the others, but maybe it is more efficient to wait until the other edits land in the main repo, first. -Ben --------------38DF947153D1209C855D4938 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 12/15/2016 07:32 AM, Guballa Jens (ETAS-PSC/ECS) wrote:
Hi all,

I had a closer look at the TLS1.3-18-draft, and I would like to provide some comments.

My overall impression is that too less attention has been put on a clear and precise terminology.

Yes, that has not been a focus, and the document has evolved a lot over time.

Several of the points you note already have pull requests outstanding that fix them (in addition to the one Dave noted).  Someone will need to put the time in to create a patch to resolve the others, but maybe it is more efficient to wait until the other edits land in the main repo, first.

-Ben
--------------38DF947153D1209C855D4938-- From nobody Fri Dec 16 11:38:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B993B129432 for ; Fri, 16 Dec 2016 11:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.596 X-Spam-Level: X-Spam-Status: No, score=-5.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.896, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOaGE_dVfDPd for ; Fri, 16 Dec 2016 11:38:47 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 06D3E129B88 for ; Fri, 16 Dec 2016 11:38:47 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A55D843345A; Fri, 16 Dec 2016 19:38:46 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 8F2284334A8; Fri, 16 Dec 2016 19:38:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1481917126; bh=vq46DXOSuLIoDPyjwk3hvnWdRV5IhUN6U9rG4aK3t8M=; l=2554; h=To:References:Cc:From:Date:In-Reply-To:From; b=BTi4ID2/o7k3p+m7BS+wnbqD3p76HFizbzeTQgdAvEo0pH7gSCTMJ8u+3cvnK0IBe 9Oo0Xq3O2rejiBqv6Quh/66GcqdYqCetfMKuw6iUuaU0vWFLhAtcqGs2gNUkZrVTCL ctEse05L3Cd7WahALC82SC5bULb3l+6s/7eaKqfE= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 50B0A1FC8B; Fri, 16 Dec 2016 19:38:46 +0000 (GMT) To: Martin Thomson , Yoav Nir References: From: Benjamin Kaduk Message-ID: Date: Fri, 16 Dec 2016 13:38:45 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B9431A874E6843268DE2029D" Archived-At: Cc: "" Subject: Re: [TLS] Harmonizing 4492bis with TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 19:38:49 -0000 This is a multi-part message in MIME format. --------------B9431A874E6843268DE2029D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/13/2016 11:56 PM, Martin Thomson wrote: > On 14 December 2016 at 16:42, Yoav Nir wrote: >> Aren’t we going to have separate registries for 1.2 and 1.3? We don’t want to force anyone to make the changes you had made (as part of 1.3) just to get EdDSA..And I need to request things from IANA based on 1.2 registries. > Yes, but I was thinking that there might be an expectation about 1.2 > values and the way they propagate into the 1.3 registry. We don't > want that here. > The current text in the 1.3 spec "obsoletes" the old HashAlgorithm and SignatureAlgorithm registries in favor of a new SignatureScheme registry. (I don't actually know if "obsoletes" is a magic word for IANA, though.) I agree with Ilari and Martin that essentially backporting the 1.3 semantics for use in 1.2 is the best way forward. -Ben --------------B9431A874E6843268DE2029D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 12/13/2016 11:56 PM, Martin Thomson wrote:
On 14 December 2016 at 16:42, Yoav Nir <ynir.ietf@gmail.com> wrote:

Aren’t we going to have separate registries for 1.2 and 1.3?  We don’t want to force anyone to make the changes you had made (as part of 1.3) just to get EdDSA..And I need to request things from IANA based on 1.2 registries.

Yes, but I was thinking that there might be an expectation about 1.2
values and the way they propagate into the 1.3 registry.  We don't
want that here.

The current text in the 1.3 spec "obsoletes" the old HashAlgorithm and SignatureAlgorithm registries in favor of a new SignatureScheme registry.  (I don't actually know if "obsoletes" is a magic word for IANA, though.)

I agree with Ilari and Martin that essentially backporting the 1.3 semantics for use in 1.2 is the best way forward.

-Ben
--------------B9431A874E6843268DE2029D-- From nobody Sat Dec 17 16:04:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 099F31294B1 for ; Sat, 17 Dec 2016 16:04:47 -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 vaEZTkf4hWKT for ; Sat, 17 Dec 2016 16:04:45 -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 B605B126D73 for ; Sat, 17 Dec 2016 16:04:45 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id r204so49583263ywb.0 for ; Sat, 17 Dec 2016 16:04:45 -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=T/WcXQ1n5ABi3BKoL/iqsQwQLYmRPwR78jy2zV5ogUI=; b=QcU1Q3yjfnlraADd5cCIc8ETCMCSzPEL0pqHz9O2lP1NZ4LT1XGXO6zcUN0eRSh4r/ C5fHpa7gPzlWGx500h22SBeyfs8jswd+qSlTLUAoxxGUZln67lYNOe+oK/ey+hxDunPh I+eVSltZeeqsiRoMllcRC26pyhuw20Fa+RpVUwfaDY7WG5BcScpmkW138eY6u1TIW6oK uV5wRZiOxR3BhIkHVP+x5DAbVqYU/g3DyjM41dTcsngUyEVZkGC2fi4jX2DmNMu95oXn 1Q6s2plfPEKc0xDN+R/nctyCCHkXA7dPhwAKL0vRMEQeITiFtKQTjDhSnwcijScldS2X OXeg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T/WcXQ1n5ABi3BKoL/iqsQwQLYmRPwR78jy2zV5ogUI=; b=R0j/1bQ+w1tayecHQIcmGbOuZoylwToIeSf4vV4Zrqh5F0ZN5k0hFRU2jg4oX1ip8V e/ZMJMPkcw840wOh4e4mp0pdPN0CdaYbMfoj/IPFqhMIKyP5cmevNs19whSzQR43L+mo YRErQXaD45bs6MTlT37z5rOJg0xX/cJMiLp6hfVZhSwLX8hEnwiruYNXfihgciS4/AFX /aqdAbHzq56Clr4TJYhCRa9QbCZB1SRiI6+4eP2blct4OUsgowuLc2NgIsJcvWVsZQZ3 9SxKNewWCeCe7DmdXGzM565IO+zS2jP93VRWW0aE5aCk4BtIhOy1j1yyCyr42t6HNpd6 JpAQ== X-Gm-Message-State: AKaTC03YNoAogjGhZZ8VFaay5JimLklFNcWE/8P1K7CJvcLA6P3HC/Ph8+nouLTkLiU992lWfI/LhLCSuNl7IQ== X-Received: by 10.129.121.1 with SMTP id u1mr7599979ywc.146.1482019484978; Sat, 17 Dec 2016 16:04:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Sat, 17 Dec 2016 16:04:04 -0800 (PST) In-Reply-To: <4d999633-466e-6f25-e1ef-b0e8c85f5d76@akamai.com> References: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> <4d999633-466e-6f25-e1ef-b0e8c85f5d76@akamai.com> From: Eric Rescorla Date: Sat, 17 Dec 2016 16:04:04 -0800 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=94eb2c0a8f82f4168b0543e38ce8 Archived-At: Cc: "" Subject: Re: [TLS] Comments to draft tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 00:04:47 -0000 --94eb2c0a8f82f4168b0543e38ce8 Content-Type: text/plain; charset=UTF-8 I've merged all the outstanding editorial PR. Jens, would you like to propose changes via a PR? -Ekr On Fri, Dec 16, 2016 at 11:29 AM, Benjamin Kaduk wrote: > On 12/15/2016 07:32 AM, Guballa Jens (ETAS-PSC/ECS) wrote: > > Hi all, > > I had a closer look at the TLS1.3-18-draft, and I would like to provide some comments. > > My overall impression is that too less attention has been put on a clear and precise terminology. > > > > Yes, that has not been a focus, and the document has evolved a lot over > time. > > Several of the points you note already have pull requests outstanding that > fix them (in addition to the one Dave noted). Someone will need to put the > time in to create a patch to resolve the others, but maybe it is more > efficient to wait until the other edits land in the main repo, first. > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c0a8f82f4168b0543e38ce8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've merged all the outstanding editorial PR. Jens, wo= uld you like to propose changes via a PR?

-Ekr




On Fri, Dec 16, 2016 at 11:29 AM, = Benjamin Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20
On 12/15/2016 07:32 AM, Guballa Jens (ETAS-PSC/ECS) wrote:
Hi all,

I had a closer look at the TLS1.3-18-draft, and I would like to provide som=
e comments.

My overall impression is that too less attention has been put on a clear an=
d precise terminology.

Yes, that has not been a focus, and the document has evolved a lot over time.

Several of the points you note already have pull requests outstanding that fix them (in addition to the one Dave noted).=C2=A0 Someone will need to put the time in to create a patch to resolve the others, but maybe it is more efficient to wait until the other edits land in the main repo, first.

-Ben

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


--94eb2c0a8f82f4168b0543e38ce8-- From nobody Sun Dec 18 13:18:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E537A129422 for ; Sun, 18 Dec 2016 13:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 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_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=usaa.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdAHOreaEcJb for ; Sun, 18 Dec 2016 13:18:46 -0800 (PST) Received: from prodomx102l.usaa.com (prodomx102l.usaa.com [167.24.25.117]) (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 5166E1293DF for ; Sun, 18 Dec 2016 13:18:44 -0800 (PST) Received: from pps.filterd (prodomx102l.usaa.com [127.0.0.1]) by prodomx102l.usaa.com (8.15.0.59/8.15.0.59) with SMTP id uBILH1iV000823 for ; Sun, 18 Dec 2016 15:18:42 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=usaa.com; h=from : to : subject : date : message-id : content-type : mime-version; s=201408; bh=ThMiNnJHZOqaMoaKfbQ68WTyLMXUnaiTHCwJTss+83s=; b=Q/bTjGm2AOrK/a+op/w4DL3oqCSjxxM0CxR8W3fW35YGybgcXhmwMJGiUv6kbgoTK6xE tciTFvizLuT53jsMbUQmWkqSx5ytA6yOxiMjnpGd6oHJS79LS5FKAnyjbF1K5289nPBs 78Ej6dL5+G99TNWoVAtTpqhVGaIIMfJcEenVDr1vBaIXnWSljWyJ2KzH1v+6mtJ+1ddM ylCkiT1WTfT9FL/5Wgy8/vUvPWZ7ZV/9ObZX1z0Pn4DRwikrdjbJ8sqlDkivDuBarQxj ebliBv+yI4eJJb4KPxObvWEcv3Ges1k5RakDZESR2/Az6kqX4+wsA4K83knLWo0ePSYf ZQ== Received: from prodexch04w.eagle.usaa.com (prodexch04w.eagle.usaa.com [10.170.40.30]) by prodomx102l.usaa.com with ESMTP id 27d107afhq-1 for ; Sun, 18 Dec 2016 15:18:42 -0600 Received: from PRODEXMB01W.eagle.usaa.com ([169.254.1.144]) by PRODEXCH04W.eagle.usaa.com ([10.170.40.30]) with mapi id 14.03.0210.002; Sun, 18 Dec 2016 15:18:41 -0600 From: "Mehner, Carl" To: "tls@ietf.org" Thread-Topic: TLS 1.3 Cookie Thread-Index: AdJZcXsxepew1AUaRlOnG7vM4pWIxg== Date: Sun, 18 Dec 2016 21:18:41 +0000 Message-ID: <19075EB00EA7FE49AFF87E5818D673D41F7F8DAB@PRODEXMB01W.eagle.usaa.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-c2processedorg: b8bcc573-fb52-4e08-924e-ca559c360d81 Content-Type: multipart/alternative; boundary="_000_19075EB00EA7FE49AFF87E5818D673D41F7F8DABPRODEXMB01Weagl_" MIME-Version: 1.0 Archived-At: Subject: [TLS] TLS 1.3 Cookie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 21:18:48 -0000 --_000_19075EB00EA7FE49AFF87E5818D673D41F7F8DABPRODEXMB01Weagl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 4.2.2 'Cookie', does not seem quite prescriptive enough for a MTI e= xtension. It is unclear if the original client hello is supposed to be part= of the Handshake Transcript. (It is in the "Incorrect DHE Share" section, = but remains unspecified here). I'm willing to propose some text (either her= e or in a pull request), I just didn't know which way to go as far as the t= ranscript and context. It would also benefit from an example of what to put= in the cookie, similar to RFC 6347. e.g. Cookie =3D HMAC(Secret, Client-IP= , Handshake Transcript). --_000_19075EB00EA7FE49AFF87E5818D673D41F7F8DABPRODEXMB01Weagl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 4.2.2 ‘Cookie’, does not seem qu= ite prescriptive enough for a MTI extension. It is unclear if the original = client hello is supposed to be part of the Handshake Transcript. (It is in = the “Incorrect DHE Share” section, but remains unspecified here). I’m willing to propose some text (either here or = in a pull request), I just didn’t know which way to go as far as the = transcript and context. It would also benefit from an example of what to pu= t in the cookie, similar to RFC 6347. e.g. Cookie =3D HMAC(Secret, Client-IP, Handshake Transcr= ipt).

--_000_19075EB00EA7FE49AFF87E5818D673D41F7F8DABPRODEXMB01Weagl_-- From nobody Sun Dec 18 13:44:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 179AF129406 for ; Sun, 18 Dec 2016 13:44:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 izZN5m6-bGoQ for ; Sun, 18 Dec 2016 13:44:37 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 09D7E1293DF for ; Sun, 18 Dec 2016 13:44:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 0142716D60; Sun, 18 Dec 2016 23:44:35 +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 c2ACjLzG3oXL; Sun, 18 Dec 2016 23:44:34 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id B1ACE21C; Sun, 18 Dec 2016 23:44:34 +0200 (EET) Date: Sun, 18 Dec 2016 23:44:25 +0200 From: Ilari Liusvaara To: "Mehner, Carl" Message-ID: <20161218214425.GA3668@LK-Perkele-V2.elisa-laajakaista.fi> References: <19075EB00EA7FE49AFF87E5818D673D41F7F8DAB@PRODEXMB01W.eagle.usaa.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <19075EB00EA7FE49AFF87E5818D673D41F7F8DAB@PRODEXMB01W.eagle.usaa.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 Cookie X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Dec 2016 21:44:39 -0000 On Sun, Dec 18, 2016 at 09:18:41PM +0000, Mehner, Carl wrote: > It would also benefit from an example of what to put in the cookie, > similar to RFC 6347. e.g. Cookie = HMAC(Secret, Client-IP, Handshake > Transcript). Well, most of the time, you don't want to use cookie field in TLS 1.3, as it is mostly meant for (future) DTLS 1.3. There are some exceptions, but those mostly involve protocols running on top of UDP using TLS 1.3 as internal component. And then that protocol should specify what goes to the cookie. And in DTLS 1.3, one presumably wants to include transcript state (good luck finding SHA-256 implementation that is featureful enough...) either as MAC'd plaintext or as encrypted value in the cookie. -Ilari From nobody Mon Dec 19 03:41:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0332129713 for ; Mon, 19 Dec 2016 03:41:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.321 X-Spam-Level: X-Spam-Status: No, score=-7.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, 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 jAR-_G7AAO_p for ; Mon, 19 Dec 2016 03:41:07 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E946B12940A for ; Mon, 19 Dec 2016 03:41:05 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CXI75218; Mon, 19 Dec 2016 11:41:02 +0000 (GMT) Received: from BLREML406-HUB.china.huawei.com (10.20.4.43) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 19 Dec 2016 11:40:50 +0000 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.90]) by BLREML406-HUB.china.huawei.com ([10.20.4.43]) with mapi id 14.03.0301.000; Mon, 19 Dec 2016 17:10:46 +0530 From: Raja ashok To: David Woodhouse , Nikos Mavrogiannopoulos , "andreas.walz@hs-offenburg.de" Thread-Topic: draft-jay-tls-psk-identity-extension-01 Thread-Index: AQHSELia/WQtXDK+QECTlnp0r3XqMaCAEtmAgAQjBQCAi4EKcA== Date: Mon, 19 Dec 2016 11:40:46 +0000 Message-ID: References: <1474098807.2070.10.camel@gmail.com> <1474270465.144982.206.camel@infradead.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5857C74F.04DD, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.90, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 63d49d5525e67b8e3b254b2be7bc34ad Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-jay-tls-psk-identity-extension-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 11:41:09 -0000 SGkgRGF2aWQgJiBOaWtvcywNCg0KM3JkIHZlcnNpb24gb2YgdGhlIGRyYWZ0LWpheS10bHMtcHNr LWlkZW50aXR5LWV4dGVuc2lvbiBoYXMgYmVlbiBzdWJtaXR0ZWQuIFlvdXIgdmFsdWFibGUgY29t bWVudHMgYXJlIGFsc28gZml4ZWQuDQpQbGVhc2UgZ28gdGhyb3VnaCBvbmNlIGFuZCBwcm92aWRl IG1lIHlvdXIgc3VnZ2VzdGlvbi4NCg0KQEFuZHJlYXMgOiBSZXF1ZXN0aW5nIHlvdSBhbHNvIHRv IGdvIHRocm91Z2ggYW5kIHByb3ZpZGUgeW91ciBzdWdnZXN0aW9uLg0KDQoNClJhamEgQXNob2sg ViBLDQpIdWF3ZWkgVGVjaG5vbG9naWVzDQpCYW5nYWxvcmUsIEluZGlhDQpodHRwOi8vd3d3Lmh1 YXdlaS5jb20gDQoNCuacrOmCruS7tuWPiuWFtumZhOS7tuWQq+acieWNjuS4uuWFrOWPuOeahOS/ neWvhuS/oeaBr++8jOS7hemZkOS6juWPkemAgee7meS4iumdouWcsOWdgOS4reWIl+WHuueahOS4 quS6uuaIlue+pOe7hOOAguemgQ0K5q2i5Lu75L2V5YW25LuW5Lq65Lul5Lu75L2V5b2i5byP5L2/ 55So77yI5YyF5ous5L2G5LiN6ZmQ5LqO5YWo6YOo5oiW6YOo5YiG5Zyw5rOE6Zyy44CB5aSN5Yi2 44CB5oiW5pWj5Y+R77yJ5pys6YKu5Lu25LitDQrnmoTkv6Hmga/jgILlpoLmnpzmgqjplJnmlLbk uobmnKzpgq7ku7bvvIzor7fmgqjnq4vljbPnlLXor53miJbpgq7ku7bpgJrnn6Xlj5Hku7bkurrl ubbliKDpmaTmnKzpgq7ku7bvvIENClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVudHMgY29u dGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIA0KaXMgaW50 ZW5kZWQgb25seSBmb3IgdGhlIHBlcnNvbiBvciBlbnRpdHkgd2hvc2UgYWRkcmVzcyBpcyBsaXN0 ZWQgYWJvdmUuIEFueSB1c2Ugb2YgdGhlIA0KaW5mb3JtYXRpb24gY29udGFpbmVkIGhlcmVpbiBp biBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwgb3IgcGFydGlh bCANCmRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29u cyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCANCnJlY2lwaWVudChzKSBpcyBwcm9oaWJpdGVkLiBJ ZiB5b3UgcmVjZWl2ZSB0aGlzIGUtbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGJ5IA0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUmFqYSBhc2hvayANClNlbnQ6IDIxIFNl cHRlbWJlciAyMDE2IDIzOjE3DQpUbzogJ0RhdmlkIFdvb2Rob3VzZSc7IE5pa29zIE1hdnJvZ2lh bm5vcG91bG9zDQpDYzogJ2pheWFyYWdoYXZlbmRyYW5AZ21haWwuY29tJzsgdGxzQGlldGYub3Jn DQpTdWJqZWN0OiBSRTogZHJhZnQtamF5LXRscy1wc2staWRlbnRpdHktZXh0ZW5zaW9uLTAxDQoN CkhpIERhdmlkICYgTmlrb3MsDQoNCk15IGNvbW1lbnRzIGFyZSBpbmxpbmVkIGluIGJlbG93IG1h aWwsIHBsZWFzZSBjaGVjayBpdC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IERhdmlkIFdvb2Rob3VzZSBbbWFpbHRvOmR3bXcyQGluZnJhZGVhZC5vcmddDQpTZW50OiAxOSBT ZXB0ZW1iZXIgMjAxNiAxMzowNA0KVG86IE5pa29zIE1hdnJvZ2lhbm5vcG91bG9zOyBSYWphIGFz aG9rOyBqYXlhcmFnaGF2ZW5kcmFuLmtAaHVhd2VpLmNvbQ0KU3ViamVjdDogUmU6IGRyYWZ0LWph eS10bHMtcHNrLWlkZW50aXR5LWV4dGVuc2lvbi0wMQ0KDQpPbiBTYXQsIDIwMTYtMDktMTcgYXQg MDk6NTMgKzAyMDAsIE5pa29zIE1hdnJvZ2lhbm5vcG91bG9zIHdyb3RlOg0KPiBIZWxsbywNCj4g wqBXZSB3ZXJlIHdpdGggRGF2aWQgaW1wbGVtZW50aW5nIHRoZcKgZHJhZnQtamF5LXRscy1wc2st aWRlbnRpdHktDQo+IGV4dGVuc2lvbi0wMSBvbiBvcGVuY29ubmVjdCBWUE4sIGhvd2V2ZXIgd2Ug bm90aWNlZCB0aGF0IHRoZSBsYXRlc3QgDQo+IHZlcnNpb24gb2YgVExTIDEuMyBtb2RpZmllZCB0 aGUgaWRlbnRpdHkgZXh0ZW5zaW9uIGluIGFuIGluY29tcGF0aWJsZSANCj4gd2F5LiBJIGFtIG5v dCBzdXJlIGlmIHRoZSBuZXcgZm9ybWF0IGNhbiBiZSB1c2VkIGluIHBsYWNlIG9mIHRoZSBvbGQg DQo+IG9uZS4gRm9yIHRoYXQgd2Ugd291bGQgbGlrZSB0byBhc2sgd2hhdCBpcyB5b3VyIHBsYW4g YWJvdXQgaXQuIFdvdWxkIA0KPiB5b3UgaW5jbHVkZSB0aGUgbmV3IGZvcm1hdCB3aXRoIHNvbWUg Z3VpZGFuY2Ugb24gaG93IHRvIGJlIHVzZWQgdW5kZXIgDQo+IHRscyAxLjIsIG9yIHdvdWxkIHlv dSBzdGljayB0byB0aGUgZXhpc3RpbmcgZm9ybWF0Pw0KDQpbYXNob2tdICA6IFBTSyBJZGVudGl0 eSBleHRlbnNpb24gc3BlY2lmaWVkIGluIG91ciBleHRlbnNpb24gZGlmZmVycyBmcm9tIHRoZSBl eHRlbnNpb24gc3BlY2lmaWVkIGluIFRMUzEuMy4gSW4gVExTMS4zIFBTSyBpZGVudGl0eSBleHRl bnNpb24gdGhleSBhcmUgdHJ5aW5nIHRvIGV4Y2hhbmdlIHdoZXRoZXIgaXRzIERIRSBiYXNlZCBQ U0sgb3Igbm90IGFuZCBhbHNvIGF1dGhlbnRpY2F0aW9uIG1lY2hhbmlzbSAoUFNLIG9yIGNlcnQg YmFzZWQgYXV0aGVudGljYXRpb24pLCBhbGwgdGhlc2UgdGhpbmdzIGZvciBrZXlfc2hhcmUgZXh0 ZW5zaW9uLiBTbyB0aGF0IFRMUzEuMyBoYXMgUHNrS2V5RXhjaGFuZ2VNb2RlcyBhbmQgUHNrQXV0 aGVudGljYXRpb25Nb2Rlcy4gQnV0IEkgaG9wZSB0aGVzZSBhcmUgbm90IHJlcXVpcmVkIGZvciBs b3dlciB2ZXJzaW9ucyAoVExTMS4yLCAxLjEgYW5kIDEuMCkuIFNvIHRoZSBleHRlbnNpb24gcHJv cG9zZWQgaW4gdGhpcyBkcmFmdCBpcyBvbmx5IGZvciB1c2FnZSB3aXRoIFRMUzEuMiwgMS4xIGFu ZCAxLjAuIEFuZCBJIGZlZWwsIHdlIGNhbiBtYWtlIHRoaXMgYXMgYSBzZXBhcmF0ZSBleHRlbnNp b24gdG8gYXZvaWQgY29uZnVzaW9uIHdpdGggVExTMS4zIGV4dGVuc2lvbi4gSWYgd2UgZmVlbCBh bnl0aGluZyBuZWVkcyB0byBiZSBpbmhlcml0ZWQgZnJvbSBUTFMxLjMgZXh0ZW5zaW9uLCB3ZSBj YW4gZG8gaXQuDQoNCkEgY291cGxlIG9mIG90aGVyIGNvbW1lbnRzIG9uIGxvb2tpbmcgaW4gZGV0 YWlsIGF0IHRoZSBkcmFmdC4uLg0KDQpSRkM0Mjc5IMKnNS4xIHNheXMgdGhhdCBQU0sgaWRlbnRp dGllcyBNVVNUIGJlIGEgY2hhcmFjdGVyIHN0cmluZywgZW5jb2RlZCBpbiBVVEYtOC4NCg0KQnV0 IHRoZSBUTFN2MS4zIGRyYWZ0IGRvZXNuJ3Qgc2F5IHRoaXMgYW55d2hlcmUsIGFuZCBpbiBmYWN0 IGluIMKnNC41LjEgaXQgc2VlbXMgdG8gc3VnZ2VzdCB0aGF0IGZvciBzZXNzaW9uIHJlc3VtcHRp b24sIHdlIHVzZSBhIHRpY2tldCBjb25zdHJ1Y3RlZCBhY2NvcmRpbmcgdG8gUkZDNTA3NyBhcyB0 aGUgUFNLIGlkZW50aXR5LiBXaGljaCB3b3VsZCBwcm9iYWJseSBiZSBiaW5hcnkuDQoNCklmIFRM U3YxLjMgaXMgZ29pbmcgdG8gYWxsb3cgbm9uLVVURjggUFNLIGlkZW50aXRpZXMgYW5kIFRMU3Yx LjIgc3RpbGwgZG9lc24ndCwgdGhlbiBpdCB3b3VsZCBiZSB1c2VmdWwgdG8gY2xhcmlmeSBwcmVj aXNlbHkgd2hhdCBpcyBhbGxvd2VkIGluIGRyYWZ0LWpheS10bHMtcHNrLWlkZW50aXR5LWV4dGVu c2lvbi4NCg0KW2FzaG9rXSA6IFBTSyBpZGVudGl0eSBleHRlbnNpb24gc3BlY2lmaWVkIGluIHRo aXMgZHJhZnQgYWxzbyBleHBlY3RzIHRoZSBQU0sgSUQgYXMgY2hhcmFjdGVyIHN0cmluZyBpbiBV VEYgZm9ybWF0LCBzaW1pbGFyIHRvIFJGQyA0Mjc5LiBJIHdpbGwgdXBkYXRlIHRoaXMgcG9pbnQg aW4gb3VyIGRyYWZ0LCB0aGFua3MgZm9yIHJlbWluZGluZyBtZS4NCg0KQW5vdGhlciBkaWZmZXJl bmNlIEkgbm90ZSBiZXR3ZWVuIHlvdXIgZHJhZnQgYW5kIHRoZSBjdXJyZW50IFRMU3YxLjMgZHJh ZnQgaXMgdGhhdCBpbiBUTFN2MS4zLCB0aGUgUHJlU2hhcmVkS2V5RXh0ZW5zaW9uIGRhdGEgcmV0 dXJuZWQgYnkgdGhlIHNlcnZlciBpcyBqdXN0IGFuIGluZGV4IGluIHRoZSBpZGVudGl0aWVzIG9m ZmVyZWQgYnkgdGhlIGNsaWVudDsgbm90IGEgY29weSBvZiB0aGUgaWRlbnRpZmllciBpdHNlbGY6 DQoNCsKgIMKgc3RydWN0IHsNCsKgwqDCoMKgwqDCoMKgc2VsZWN0IChIYW5kc2hha2UubXNnX3R5 cGUpIHsNCsKgwqDCoMKgwqDCoMKgwqDCoMKgwqBjYXNlIGNsaWVudF9oZWxsbzoNCsKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoFBza0lkZW50aXR5IGlkZW50aXRpZXM8Ni4uMl4xNi0xPjsN Cg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoGNhc2Ugc2VydmVyX2hlbGxvOg0KwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgdWludDE2IHNlbGVjdGVkX2lkZW50aXR5Ow0KwqDCoMKgwqDCoMKg wqB9DQrCoMKgwqB9IFByZVNoYXJlZEtleUV4dGVuc2lvbjsNCg0KDQouLi4NCiAgIHNlbGVjdGVk X2lkZW50aXR5ICAgICBUaGUgc2VydmVy4oCZcyBjaG9zZW4gaWRlbnRpdHkgZXhwcmVzc2VkIGFz IGENCiAgICAgICAgICAgICAgICAgICAgICAgICAoMC1iYXNlZCkgaW5kZXggaW50byB0aGUgaWRl bnRpdGllcyBpbiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICBjbGllbnTigJlzIGxpc3Qu DQoNClthc2hva10gOiBJIGZlZWwgc2VuZGluZyB0aGUgc2VsZWN0ZWQgSUQgaXMgYmV0dGVyLCBv dGhlcndpc2Ugd2hpbGUgcHJvY2VzcyAic2VydmVyIGhlbGxvIiBtc2csIGNsaWVudCBoYXMgdG8g bWFpbnRhaW4gdGhlIFBTSyBJRCBsaXN0IGluIHRoZSBzYW1lIG9yZGVyIGluIHdoaWNoIGl0IHNl bnQuIEFscmVhZHkgdGhlcmUgd2FzIGEgZGlzY3Vzc2lvbiBpbiBUTFMxLjMgZ3JvdXAgZm9yIHNl bmRpbmcgc2VsZWN0ZWQgSUQgaW5zdGVhZCBvZiBpbmRleC4gDQoNCkFuZCBhIGZpbmFsIG5pdHBp Y2suLi4gcmVwbGFjZSBldmVyeSBpbnN0YW5jZSBpdCAiaXQncyIgd2l0aCAiaXRzIiA6KQ0KDQpb YXNob2tdIDogSSB3aWxsIGNoZWNrIGFuZCBmaXggaXQuIEkgd2lsbCB1cGxvYWQgYSByZXZpc2Vk IGRyYWZ0LiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMuDQoNCg0KLS0gDQpEYXZpZCBXb29kaG91 c2UgICAgICAgICAgICAgICAgICAgICAgICAgICAgT3BlbiBTb3VyY2UgVGVjaG5vbG9neSBDZW50 cmUNCkRhdmlkLldvb2Rob3VzZUBpbnRlbC5jb20gICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBJbnRlbCBDb3Jwb3JhdGlvbg0KDQoNCg0KDQpSYWphIEFzaG9rDQpIVUFXRUkgVEVDSE5PTE9H SUVTIENPLixMVEQuIA0KDQpFLW1haWw6IHJhamEuYXNob2tAaHVhd2VpLmNvbQ0Kd3d3Lmh1YXdl aS5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgZS1tYWlsIGFuZCBpdHMgYXR0YWNobWVu dHMgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gZnJvbSBIVUFXRUksIHdoaWNoIGlz IGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMg bGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaGVyZWlu IGluIGFueSB3YXkgKGluY2x1ZGluZywgYnV0IG5vdCBsaW1pdGVkIHRvLCB0b3RhbCBvciBwYXJ0 aWFsIGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgb3IgZGlzc2VtaW5hdGlvbikgYnkgcGVyc29u cyBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZA0KcmVjaXBpZW50KHMpIGlzIHByb2hpYml0ZWQuIElm IHlvdSByZWNlaXZlIHRoaXMgZS1tYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYnkgcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCENCg0K From nobody Mon Dec 19 04:27:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89F751299BB for ; Mon, 19 Dec 2016 04:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l7Nn1-cT4x-d for ; Mon, 19 Dec 2016 04:27:30 -0800 (PST) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1801299B7 for ; Mon, 19 Dec 2016 04:27:30 -0800 (PST) Received: from vsmta11.fe.internet.bosch.com (unknown [10.4.98.51]) by imta23.fe.bosch.de (Postfix) with ESMTP id 3BB8715801AC; Mon, 19 Dec 2016 13:27:27 +0100 (CET) Received: from FE-MBX1027.de.bosch.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta11.fe.internet.bosch.com (Postfix) with ESMTP id 342A12380F33; Mon, 19 Dec 2016 13:27:27 +0100 (CET) Received: from SI-MBX1028.de.bosch.com (10.3.230.42) by FE-MBX1027.de.bosch.com (10.3.230.85) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Mon, 19 Dec 2016 13:27:26 +0100 Received: from SI-MBX1028.de.bosch.com ([fe80::c1ec:d83c:fc40:7182]) by SI-MBX1028.de.bosch.com ([fe80::c1ec:d83c:fc40:7182%20]) with mapi id 15.00.1236.000; Mon, 19 Dec 2016 13:27:27 +0100 From: "Guballa Jens (ETAS-PSC/ECS)" To: Eric Rescorla , Benjamin Kaduk Thread-Topic: [TLS] Comments to draft tls13-18 Thread-Index: AdJW1uIl07QSarVeRrSVWZuaTFLpQAA827IAADvi6QAAThHpIA== Date: Mon, 19 Dec 2016 12:27:26 +0000 Message-ID: <81dbc82f02114b9f99cdcf1ef0612e7e@SI-MBX1028.de.bosch.com> References: <29b89640bc0f4f12925154400550c1f5@SI-MBX1028.de.bosch.com> <4d999633-466e-6f25-e1ef-b0e8c85f5d76@akamai.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.51.202.94] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0007_01D259FB.A2E86BD0" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22770.006 X-TMASE-MatchedRID: Ui+BEt6rrXjs8TWiNgS9oUm30iQM6IGOQTFIyHyLzQDh5xw4PvguuVgJ L2zT85Ei7aN+zIeuVBDPokSuQ+4lt0db73gUDwkXQr2qXCJMSV/qvccKLF+4pxziuLhElX/VJZ4 4eKUvRYc/makG0+v97gFk6w4YcqmhSOWjYlTyoLGYcl4BgqVyk8MdI0UcXEHzj2iyfwmt0k9o4t OBMzo2OO/PabHhArwBOLoOGImc4B41gbUlmfmxOiI9MxSOQ6CSLVEjAx3HjK6YI2SdJezB/xKQZ 2ZC35dZZeWOGcHSVtq6H+0z6Sb8PPEnzi0PuMx/iQy4MG/9StlpkajQR5gb3r6qvLNjDYTwm+Ig 5TvcoI4S8tmHsHOFP/A9URTZfNHRI/NGWt0UYPCG4ux8hW/Tb+r2NRPVyHPxNR+yivDE/6CLd4D gBNi2IxT5eR7DbmvA Archived-At: Cc: "" Subject: Re: [TLS] Comments to draft tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2016 12:27:33 -0000 ------=_NextPart_000_0007_01D259FB.A2E86BD0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0008_01D259FB.A2E86BD0" ------=_NextPart_001_0008_01D259FB.A2E86BD0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Yes, I will provide a PR. Jens Von: Eric Rescorla [mailto:ekr@rtfm.com] Gesendet: Sonntag, 18. Dezember 2016 01:04 An: Benjamin Kaduk Cc: Guballa Jens (ETAS-PSC/ECS) ; Betreff: Re: [TLS] Comments to draft tls13-18 I've merged all the outstanding editorial PR. Jens, would you like to propose changes via a PR? -Ekr ------=_NextPart_001_0008_01D259FB.A2E86BD0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Yes, I will provide a PR.

 

Jens

 

Von: = Eric Rescorla [mailto:ekr@rtfm.com]
Gesendet: Sonntag, 18. = Dezember 2016 01:04
An: Benjamin Kaduk = <bkaduk@akamai.com>
Cc: Guballa Jens (ETAS-PSC/ECS) = <Jens.Guballa@etas.com>; <tls@ietf.org> = <tls@ietf.org>
Betreff: Re: [TLS] Comments to draft = tls13-18

 

I've = merged all the outstanding editorial PR. Jens, would you like to propose = changes via a PR?

 

-Ekr

------=_NextPart_001_0008_01D259FB.A2E86BD0-- ------=_NextPart_000_0007_01D259FB.A2E86BD0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXKzCCBLcw ggOfoAMCAQICBEMB0LowDQYJKoZIhvcNAQELBQAwUDETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFDASBgNVBAMTC0Jvc2NoLUNBLURFMB4X DTE1MDUxMjA5NDgxMFoXDTI1MDUxMjEwMTgxMFowUTETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKAkjDSX1bM0BhiJa3jlD/DiW+shP849/Bty QKlL7o+Lfdp1GZrW5cHdlg6ks4X8gd3zlpYC+JeWd1clUf2BBHlJKyOHR2caOMnSsNsbDYQ984O8 4dnWS8ex2Jiw+j+wNTtCgL3OhuGTxMIWlWfOhtlzMvz3dqqtMpaYnqzoYb/t+Uzzjg8W0/KdCM60 7M6ic2jpghz1sr5j9N5qYF/ETQWQnNoPdAzohs0bk2W02wVyayVjSVDVK6cPAnBnVzaFv+1NV5ms 53MlmQkgSg7SkRs1xwKsg5MSOsDDL+dn9bi9UU1aYNXFTefUEcHUTsjpk7REV+NQo72O97JfUKOK t18CAwEAAaOCAZYwggGSMIIBGAYDVR0fBIIBDzCCAQswZ6BloGOkYTBfMRMwEQYKCZImiZPyLGQB GRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEUMBIGA1UEAxMLQm9z Y2gtQ0EtREUxDTALBgNVBAMTBENSTDEwgZ+ggZyggZmGVWxkYXA6Ly9ib3NjaC5jb20vY249Qm9z Y2gtQ0EtREUsY249UEtJLGRjPUJvc2NoLGRjPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0 P2Jhc2WGQGh0dHA6Ly90cnVzdGNlbnRlci5ib3NjaC5jb20vQ1JML2Jvc2NoLWNhLWRlX3BraV9j b21fY3JsZmlsZS5jcmwwCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFB6lPyKiCCEbxVgo0R8t8PP4 +RUpMB0GA1UdDgQWBBTeBOLMiQj9dYzYpDAx2BBt5aH0mzAMBgNVHRMEBTADAQH/MBkGCSqGSIb2 fQdBAAQMMAobBFY4LjEDAgCBMA0GCSqGSIb3DQEBCwUAA4IBAQBITOZpOW3DTD72K7WDq5Zh5eHf zeg4FC3xDZ9nj4bs+ObFx+zInsdisYlycj5rlsMjDrS+hNKBCPVsL/JyIgelTb7fHXkl5m2ifsqn wv0YR7Tk509ooHdVXTLmZV4AjyeXUmKXXh+QkK9DiHhU6sLdkPej4gBolemqD0SVrzd7F+ZqHAvg cQtcRMVc+rkADrC2pytD90XpqDl2I5RdnNSfVpo7FsP5zHayNBIBiHBhmVPhgMUCjjxNGuMGTC74 AqqATrAKI3zEADbBoohOlaHmfnurGHHU21IAgXYYz4vngqapYWiTo2dRPuqhaZDNp4tXhBYzqunA YTfXLzo6qbXpMIIE+jCCA+KgAwIBAgIEQwG2sjANBgkqhkiG9w0BAQUFADBQMRMwEQYKCZImiZPy LGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEUMBIGA1UEAxML Qm9zY2gtQ0EtREUwHhcNMDUwODE2MDkxOTQyWhcNMjUwODE2MDk0OTQyWjBQMRMwEQYKCZImiZPy LGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEUMBIGA1UEAxML Qm9zY2gtQ0EtREUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDADDavsLqpxKnP+mAB iNavAOpR8EK4o7E1NxRj//V6gVHdLw9EnRY+CeX6KAf6CjW3X+VRzQMZOMxcj4Hn9T2/hvApgjr4 asLHduTYlNlSPBLH1c0rDBJRj4SllBtkHx4g7eelVWzWT4k2vIgxNtwAR0x+dghgObQBMGnPYGsE RYQ62JU4c3Z3yNVOOCtSh+3J9m+8zMSvPKKpiqK4D5QfhMjJDvOAgJRzkQLnJHTATLhF5Jp0phWU HJGeChwoncbhYX13AnEpqccGrid+ZdKYIFDs/I8t505VTzvQ8O0yMkYc1RLIfXMsDeullW+00lml FylcqXXMStOMhyYii4XXAgMBAAGjggHaMIIB1jARBglghkgBhvhCAQEEBAMCAAcwggEYBgNVHR8E ggEPMIIBCzBnoGWgY6RhMF8xEzARBgoJkiaJk/IsZAEZFgNjb20xFTATBgoJkiaJk/IsZAEZFgVC b3NjaDEMMAoGA1UEAxMDUEtJMRQwEgYDVQQDEwtCb3NjaC1DQS1ERTENMAsGA1UEAxMEQ1JMMTCB n6CBnKCBmYZVbGRhcDovL2Jvc2NoLmNvbS9jbj1Cb3NjaC1DQS1ERSxjbj1QS0ksZGM9Qm9zY2gs ZGM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZYZAaHR0cDovL3RydXN0Y2VudGVy LmJvc2NoLmNvbS9DUkwvYm9zY2gtY2EtZGVfcGtpX2NvbV9jcmxmaWxlLmNybDArBgNVHRAEJDAi gA8yMDA1MDgxNjA5MTk0MlqBDzIwMjUwODE2MDk0OTQyWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgw FoAUHqU/IqIIIRvFWCjRHy3w8/j5FSkwHQYDVR0OBBYEFB6lPyKiCCEbxVgo0R8t8PP4+RUpMAwG A1UdEwQFMAMBAf8wHQYJKoZIhvZ9B0EABBAwDhsIVjcuMTo0LjADAgSQMA0GCSqGSIb3DQEBBQUA A4IBAQBkQ/eOR9L4eenoIddXw7SjnJDnfsgZIaJNsnJ8afxgJjvot/U6AjnmPo7Waa5gyEIS9EEE mAubTwU30NyhHCr8iHjFDWhbSa9Waajb81i6WgklpjM6T1D+RuEO1Ty6sWgPsfx3bZLITQyoXr33 nRokVmKshjwtEU05BKRXgvk7ma9HGCV1lOtwdjHKcK17mE2FHGbFNm/o6P9CkN4P3jdmpWKSb791 5Cz9wdNPOl0IBcSlwH7j3D8YEfbkrDkk2UYPccZUzMkPi6+WhlUmwkc0ea+Fa+pjGBsZ7AEfRCcV Zaz3fjluyBWjuWRa5bY3P86UdjQplcobWrovoIwehkyRMIIGjjCCBXagAwIBAgIEQ2J0ADANBgkq hkiG9w0BAQsFADBRMRMwEQYKCZImiZPyLGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gx DDAKBgNVBAMTA1BLSTEVMBMGA1UEAxMMQm9zY2gtQ0ExLURFMB4XDTE2MTIxMzEzMTIzNVoXDTE5 MTIxMzEzNDIzNVowgYYxEzARBgoJkiaJk/IsZAEZFgNjb20xFTATBgoJkiaJk/IsZAEZFgVib3Nj aDEMMAoGA1UEAxMDcGtpMQ4wDAYDVQQDEwVCT1NDSDELMAkGA1UEAxMCREUxCjAIBgNVBAMTAUox CjAIBgNVBAMTAUUxFTATBgNVBAMTDEplbnMuR3ViYWxsYTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAK59uLjqNeweDpPkjdEsVAGfz5PXTtSskmdMlqgkg5otcrYoj+dYCNmBqmisvYri wqY56jf2QBAm8bkjxMQPgox+k4kYA/SsLuQY131ADyzhhvDbX/3PLIeLeE0TIgOMBDcjrJIJxuYc 3efy1u2cnEZyJ+PHBZstVTc+5+K5Ky4Ql7QkoVzJFJgX5zDeAQyotZzZ6s3b+MoXKugPBkK0dsCz amxFynbVYV8RL6GMfNPFqg/Xo2ee75w3w0P3VJ4NWKT1MVJXFY4Zago+8M4uZxUPsuvg+SNVStDO hWCidmY6L7n3lo2W42/LDw0aJ5wVc9x4VFHLqLtlVWjv4E3Kh98CAwEAAaOCAzYwggMyMAsGA1Ud DwQEAwIFIDAeBgNVHSUEFzAVBggrBgEFBQcDBAYJKwYBBAGVEQUBMIIBRgYDVR0gBIIBPTCCATkw ggE1Bg0rBgEEAalGg30BAgEBMIIBIjAsBggrBgEFBQcCARYgaHR0cDovL3RydXN0Y2VudGVyLmJv c2NoLmNvbS9jcHMwgfEGCCsGAQUFBwICMIHkGoHhVGhlIEJvc2NoIENlcnRpZmljYXRpb24gUHJh Y3RpY2UgU3RhdGVtZW50IChDUFMpIGF2YWlsYWJsZSBhdCBodHRwOi8vdHJ1c3RjZW50ZXIuYm9z Y2guY29tL2NwcyBpcyBoZXJlYnkgaW5jb3Jwb3JhdGVkIGludG8geW91ciB1c2Ugb3IgcmVsaWFu Y2Ugb24gdGhpcyBDZXJ0aWZpY2F0ZS4gVGhpcyBDUFMgY29udGFpbnMgbGltaXRhdGlvbnMgb24g d2FycmFudGllcyBhbmQgbGlhYmlsaXRpZXMuMCAGA1UdEQQZMBeBFUplbnMuR3ViYWxsYUBldGFz LmNvbTCCAS8GA1UdHwSCASYwggEiMGugaaBnpGUwYzETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERTEQ MA4GA1UEAxMHQ1JMMjIyMjCBsqCBr6CBrIZmbGRhcDovL2Jvc2NoLmNvbS9jbj1XaW5Db21iaW5l ZDIsY249Qm9zY2gtQ0ExLURFLGNuPVBLSSxkYz1Cb3NjaCxkYz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlhkJodHRwOi8vdHJ1c3RjZW50ZXIuYm9zY2guY29tL0NSTC9ib3NjaC1j YTEtZGVfcGtpX2NvbV9jcmxmaWxlMi5jcmwwHwYDVR0jBBgwFoAU3gTizIkI/XWM2KQwMdgQbeWh 9JswHQYDVR0OBBYEFPiN5cC6K62XZu/Zu6CSv7hhpSJAMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EA BAwwChsEVjguMQMCBLAwDQYJKoZIhvcNAQELBQADggEBAHDh6aq0mgFY8lXAJoN2NI18OF5i8CWt gTDqrns6isJxDHaLGjqgeEUcZSmY54f365Ho6io8j+Xr9CNBX1hnHOUH1A16VrWqW0BPWXUO1+rk R6t0HRLmFzEM2Jst5C5cTZucR8j3h7zSx+JWDgPOtGNg6H9XrryH43P6PaVejvPoMTByHjEOxMU8 9RN6OOTrD4zyVh+mX6kis+kFwIfp1kJ/GUk4SOpB3kV9DxLkIZfoyNAZhtZ+izLQZk17YPDPAb3E Vtz6w8A+RMef5pTdPhdZLqde2K3CN3cJvTJoEOCWkwOO0Z67y4H4UGR8dwAX6ebha9SXuEtP1RGr XKTYkK4wggbcMIIFxKADAgECAgRDYnY/MA0GCSqGSIb3DQEBCwUAMFExEzARBgoJkiaJk/IsZAEZ FgNjb20xFTATBgoJkiaJk/IsZAEZFgVCb3NjaDEMMAoGA1UEAxMDUEtJMRUwEwYDVQQDEwxCb3Nj aC1DQTEtREUwHhcNMTYxMjE0MTI0MjI4WhcNMTkxMjE0MTMxMjI4WjCBhjETMBEGCgmSJomT8ixk ARkWA2NvbTEVMBMGCgmSJomT8ixkARkWBWJvc2NoMQwwCgYDVQQDEwNwa2kxDjAMBgNVBAMTBUJP U0NIMQswCQYDVQQDEwJERTEKMAgGA1UEAxMBSjEKMAgGA1UEAxMBRTEVMBMGA1UEAxMMSmVucy5H dWJhbGxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnsORNxL2PTGGFOiPkz+PdQqq HnHThJQE13A4haBp369A1J3NXXIsgrrULByynlJNAvEKuO+E79y1pQU2DuPyzmPRnRG4x3qu0Xyf /d+6VFwrrPuhzw38MXroodUMZ0aRBhq49fNUzv+E8El1ZQCNxi52rQHZFn0B0aNcDBaKB2/GYbu+ Q6k1pyVoOc4gBILR84kGiTKdkRchL5JWD6LLoVhvhTH9JYiipjdf0o3K6gDdNMxTeOIUGQEql8BM rWisEE73eYQfTFPEx+4JrgkJD9LRZyN7VT+iFe7727lcvmBFLoguVuRxVH10VJOIhP8Iqv5PN+cM SUqYv1ujyOZJvQIDAQABo4IDhDCCA4AwCwYDVR0PBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDCCAUYGA1UdIASCAT0wggE5MIIBNQYNKwYBBAGpRoN9AQIBATCCASIwLAYIKwYB BQUHAgEWIGh0dHA6Ly90cnVzdGNlbnRlci5ib3NjaC5jb20vY3BzMIHxBggrBgEFBQcCAjCB5BqB 4VRoZSBCb3NjaCBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0YXRlbWVudCAoQ1BTKSBhdmFpbGFi bGUgYXQgaHR0cDovL3RydXN0Y2VudGVyLmJvc2NoLmNvbS9jcHMgaXMgaGVyZWJ5IGluY29ycG9y YXRlZCBpbnRvIHlvdXIgdXNlIG9yIHJlbGlhbmNlIG9uIHRoaXMgQ2VydGlmaWNhdGUuIFRoaXMg Q1BTIGNvbnRhaW5zIGxpbWl0YXRpb25zIG9uIHdhcnJhbnRpZXMgYW5kIGxpYWJpbGl0aWVzLjBC BgNVHREEOzA5gRVKZW5zLkd1YmFsbGFAZXRhcy5jb22gIAYKKwYBBAGCNxQCA6ASDBBnYmo5ZmVA Ym9zY2guY29tMIIBLwYDVR0fBIIBJjCCASIwa6BpoGekZTBjMRMwEQYKCZImiZPyLGQBGRYDY29t MRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEVMBMGA1UEAxMMQm9zY2gtQ0Ex LURFMRAwDgYDVQQDEwdDUkwyMjIyMIGyoIGvoIGshmZsZGFwOi8vYm9zY2guY29tL2NuPVdpbkNv bWJpbmVkMixjbj1Cb3NjaC1DQTEtREUsY249UEtJLGRjPUJvc2NoLGRjPWNvbT9jZXJ0aWZpY2F0 ZVJldm9jYXRpb25MaXN0P2Jhc2WGQmh0dHA6Ly90cnVzdGNlbnRlci5ib3NjaC5jb20vQ1JML2Jv c2NoLWNhMS1kZV9wa2lfY29tX2NybGZpbGUyLmNybDArBgNVHRAEJDAigA8yMDE2MTIxNDEyNDIy OFqBDzIwMTkxMjE0MTMxMjI4WjAfBgNVHSMEGDAWgBTeBOLMiQj9dYzYpDAx2BBt5aH0mzAdBgNV HQ4EFgQU7zHzHbRQfrCZKNIpxXAhm4UNoqAwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRW OC4xAwIEsDANBgkqhkiG9w0BAQsFAAOCAQEAQhXBnRdtUfXuHnZ4/tHaGQh49p/yH1LdfZYcEjtH 0PdLaVCNgpEp5cdIyr/9aQ17OMVTVZk1LeQ1QQ9LYoWTzdXgvbfZWgrL7JhWeFlcyC0vWUwyCYgU ayC2wF+4T4jUvZQQV0uob/n3H+TG/uanRN1R+1lZBBSDU1Qn+B2ECQdxurdjL7S5as1t2ohHG3oW iK0eOJpTzvT/coglaiwa2DPiNoYFyFdyUf3PFSgfzUW1FOTmoXuIbJpJFGnWzKazJFjuHXc+a88m wsWcuhdqfpvHaUtfr5vjT5BqTffwH2hC78PYlMwJV+WSkxTbnKpl03Wb9EzaxS3Q5MuL6ME4CjGC At0wggLZAgEBMFkwUTETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMGCgmSJomT8ixkARkWBUJvc2No MQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERQIEQ2J2PzAJBgUrDgMCGgUAoIIB WTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMTkxMjI3MjVa MCMGCSqGSIb3DQEJBDEWBBRijyeqlJmlXCJYO9Gj0YLsaY88GDAkBgkqhkiG9w0BCQ8xFzAVMAoG CCqGSIb3DQMHMAcGBSsOAwIaMGgGCSsGAQQBgjcQBDFbMFkwUTETMBEGCgmSJomT8ixkARkWA2Nv bTEVMBMGCgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNB MS1ERQIEQ2J0ADBqBgsqhkiG9w0BCRACCzFboFkwUTETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERQIE Q2J0ADANBgkqhkiG9w0BAQEFAASCAQA2+vpsSc85etsJd9FA7ZGlz5+GDrKy6bNPtKUw16GgjLSQ iRhqb+wm7jPNhbbykQ47AMCA6amppREs36iDo4JCWxDH4z61f6CYrkjulKxmL3IFDM9BloRKUpw7 B9hXkJrpHPYL3SNikY/yoIe9kctf0NakARUMrFRlec900O6G3PHxdZBx6KItLoaLDtz3WP1D0MiP Wh7t9bUZuhwOoF5F6uFLp3zQzUuIdsDIFCFrn0DeD16GZBTKzo5qg5huAMi0QeSoxKFCJe7Za3uz HNvlFUyE4HWvNBFmr2BD7Bx1rCMCn3Qd+8/2eba1F0nWP9mHb2q6dJa1r+KBH0HGEVkEAAAAAAAA ------=_NextPart_000_0007_01D259FB.A2E86BD0-- From nobody Tue Dec 20 06:48:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60491297C3 for ; Tue, 20 Dec 2016 06:48:02 -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 XPLAUMcMgFBO for ; Tue, 20 Dec 2016 06:47:56 -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 1BE091298C2 for ; Tue, 20 Dec 2016 06:47:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id D549B3002BF for ; Tue, 20 Dec 2016 09:37:38 -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 D4yL3TqSo7Ap for ; Tue, 20 Dec 2016 09:37:37 -0500 (EST) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id E2E6830026D for ; Tue, 20 Dec 2016 09:37:36 -0500 (EST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: <13231BFA-5D9B-4706-A7D8-F6697631F625@sn3rd.com> Date: Tue, 20 Dec 2016 09:45:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <4E4365B2-FE35-4294-8C43-F7EA88AEC313@vigilsec.com> References: <13231BFA-5D9B-4706-A7D8-F6697631F625@sn3rd.com> To: IETF TLS X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2016 14:48:03 -0000 > This is the working group last call for the "ECDHE_PSK with AES-GCM = and AES-CCM CSs for TLS=94 draft I am curious about the choice of hash function for = TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256. All of the other AES-256 = ciphersuites defined in this document that use SHA-384. Why does the = one with a truncated authentication tag use SHA-256? The Security Consideration includes: Use of Pre-Shared Keys of limited entropy (for example, a PSK that is relatively short, or was chosen by a human and thus may contain less entropy than its length would imply) may allow an active attacker to perform a brute-force attack where the attacker attempts to connect to the server and tries different keys. Given the mention of passwords, it seems that dictionary attacks should = also be mentioned. Russ From nobody Tue Dec 20 17:24:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EBE129BBD for ; Tue, 20 Dec 2016 17:24:56 -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 vwe7TnQSwufB for ; Tue, 20 Dec 2016 17:24:55 -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 DEF9F129BA4 for ; Tue, 20 Dec 2016 17:24:54 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id c47so193414466qtc.2 for ; Tue, 20 Dec 2016 17:24:54 -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=rTrGh+Segh2THiXH1jpJZebWoJv5bTatXJv1yRcx3rU=; b=I0HfAeQZv5hV60siazPw7oqzsPX5tSRZ/w1ZKHyKZFAEjjtVO5/x9LWf2XCvmxRegN Uo8hLweaMiiHkmfSgKlrRCpOFrhqLLzgIC2vtuCVc4f1AbrO0ZLgm7mYawJdBP3bNoWR kHuwQYuZU8mVNiaWmBQ2iyV4VQglgk4X63m5UMBgUWeg/h2lc1eyNCbqsbYdz89BFE/X xfWStP6jibCMdlCzfIHDptvf9F8CjGvSGog+pGGQOkTLPTez0t2YynVUiYJsuAKrcF68 9oVWItGSFv7rmrpZGGLiYg79US11hSYXHJLVcVLHwo94lCKbjiWotPGsigLlO9JzO4zC lfUA== 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=rTrGh+Segh2THiXH1jpJZebWoJv5bTatXJv1yRcx3rU=; b=nBb6uJ5EvRZdpMaMHVybQqN+zzZyPB+KZ9ruwkOfOrGkbgs2HTf2CsUkjPyAVZ3Is7 cgyPkpsxfrJXBjk1KuxJskSkXw9mRgQU2edgRMBT6mnJLeMOLL376OKmA/VQgqZ5yk2T anx4B7ul+ky9eDd0h0RIq/bF6Kj+F1gNg24S1CGeOszvbVp3d2w2VOxDAdgR4OFN9p/S YLlCUymRuVU9CLmTBQlUibXwbcJxjUY3EnLA5NCK45+ke4xvGvjzlyCgcppOl1JWGmkP C4T5B5bMXXvhK/9wO136W0O4aGRWw1icKrnf+drLls3Ij/Bc54Zuv0/6aag9L88ZIhSj Bp1Q== X-Gm-Message-State: AIkVDXJwG7+G309sPImeDtdYR9gAH1Ssq3l2wLPlYHdkIoH5iuXB+3cahZ8ZnJBLFbOAOdSCghP9NYwoU2F8MA== X-Received: by 10.237.44.161 with SMTP id g30mr2412445qtd.144.1482283494105; Tue, 20 Dec 2016 17:24:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 20 Dec 2016 17:24:53 -0800 (PST) In-Reply-To: <4E4365B2-FE35-4294-8C43-F7EA88AEC313@vigilsec.com> References: <13231BFA-5D9B-4706-A7D8-F6697631F625@sn3rd.com> <4E4365B2-FE35-4294-8C43-F7EA88AEC313@vigilsec.com> From: Martin Thomson Date: Wed, 21 Dec 2016 12:24:53 +1100 Message-ID: To: Russ Housley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF TLS Subject: Re: [TLS] WGLC for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Dec 2016 01:24:56 -0000 On 21 December 2016 at 01:45, Russ Housley wrote: > I am curious about the choice of hash function for TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA256. All of the other AES-256 ciphersuites defined in this document that use SHA-384. Why does the one with a truncated authentication tag use SHA-256? I would go further than Russ and challenge the value of the ciphersuite entirely. Though I think that we've already discussed this before, several times. For some reason I can't remember ever having had my mind changed on this point, though I think John pointed at the larger key size having some advantage with respect to (mumble), even if you aren't concerned about active forgery. From nobody Thu Dec 22 13:54:15 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A1A1295FD for ; Thu, 22 Dec 2016 13:54:13 -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 4uBdbyFbghvB for ; Thu, 22 Dec 2016 13:54:12 -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 295A51295FB for ; Thu, 22 Dec 2016 13:54:12 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id E433B3002BF for ; Thu, 22 Dec 2016 16:43:54 -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 XpWtFby-ltc9 for ; Thu, 22 Dec 2016 16:43:53 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id CF0E5300260 for ; Thu, 22 Dec 2016 16:43:53 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> Date: Thu, 22 Dec 2016 16:54:18 -0500 To: IETF TLS Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [TLS] Using both External PSK and (EC)DH in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 21:54:13 -0000 I want to make sure that it is possible to mix PSK with (EC)DH as a = protection against the discovery of a quantum computer. I recognize = that the WG does not want to tackle this topic in the base = specification; however, the following text in Section 4.1.1 makes this = difficult to do so in a companion document: > The server indicates its selected parameters in the ServerHello as > follows: > > - If PSK is being used then the server will send a = "pre_shared_key" > extension indicating the selected key. > > - If PSK is not being used, then (EC)DHE and certificate-based > authentication are always used. > > - When (EC)DHE is in use, the server will also provide a = "key_share" > extension. > > - When authenticating via a certificate (i.e., when a PSK is not = in > use), the server will send the Certificate (Section 4.4.1) and > CertificateVerify (Section 4.4.2) messages. An Internal PSK offers no protection against the discovery of a quantum = computer. I assume that an attacker can save the handshake that = established the Internal PSK, and then at some future date use the = quantum computer to discover the Internal PSK. Therefore, protection = against the discovery of a quantum computer is only concerned with = External PSK. I would like for the specification to permit normal certificate = authentication when someone is using an External PSK. I am guessing = that the granularity of the name associated with the External PSK to be = pretty broad. If this guess is correct, it would be appropriate for the = name in the certificate to be further restrict the one associated with = the External PSK. Maybe the External PSK is associated with = example.com, and then the certificate that includes www.example.com = would be acceptable acceptable. Then, I would expect any Internal PSK = that is generated after such an authentication would be associated with = the more granular certificate name. Maybe it is as simple as reorganizing these bullets like this: - When only PSK is being used, =85 - When only (EC)DHE is being used, =85 - When PSK and (EC)DHE are both being used, =85 If others agree with this direction, I am willing to propose some text. Happy holidays, Russ= From nobody Thu Dec 22 14:12:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD581295FB for ; Thu, 22 Dec 2016 14:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, 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 dvjHQo1Cy0IF for ; Thu, 22 Dec 2016 14:12:37 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECEFF1295E8 for ; Thu, 22 Dec 2016 14:12:36 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id d45so25096826qta.1 for ; Thu, 22 Dec 2016 14:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=c9N2UnS2oQ4CeqC6GLsCt3jj8Xnd4ggRar/0QvL7e8Q=; b=kASKQthVhL5111H4HCzqk/p4TVLfTgNZkF6IUa28VM4sJU1KhGCJr72ifXAdbJnBLu bScqMtom9a9FHAY7EBtLpaKwnESFz1xUDNvNNq8C3WYjAFStfm9pO4YVkRzyGuOooZEa kNsBaGdO8NuUkcQ8ESxJQCtzt2nJUgNUpgx/Y= 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=c9N2UnS2oQ4CeqC6GLsCt3jj8Xnd4ggRar/0QvL7e8Q=; b=VeiMplltm9Kno0ETJWKQ387kwwleM8Chb+1DCdio8P7aQQqL0XO0UBdeto1UssVrTO nwn0K47xMbqcdN0vBBJJBnRnmhnR6je1lcgPJotUYMi7pf+SFdARBd0a2R0G5INAFl/g 7/HbbG3hd8pSRGZNlMfO90KnzxOO1g2e7BFGPErj7CcLFl66Oi0BemHWv6UjhSoxjKsx Nq+0n9XY/wQjXXGJ2JLbjQVkrUEMgWvZemzwEgllnMbi1waaqdhJ116P7O95XpHCUP1s ZKDvNA94R6afdfK3oqcvvw/pxzHRwMr2H/Ql+qr2I4Ymy/obSBN9tdceJGrPRpilOQPW ds2w== X-Gm-Message-State: AIkVDXLFija7rHGCq2Wm2nDFXe1L2wDxRZjosQAPt46u8bdMvcuq4xmm+yPbl9oQwfhBT3olU/q/UV4vH9nIqV2y X-Received: by 10.200.38.39 with SMTP id u36mr13237698qtu.31.1482444756073; Thu, 22 Dec 2016 14:12:36 -0800 (PST) MIME-Version: 1.0 References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> In-Reply-To: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> From: David Benjamin Date: Thu, 22 Dec 2016 22:12:25 +0000 Message-ID: To: Russ Housley , IETF TLS Content-Type: multipart/alternative; boundary=001a114580ee160d9305444691aa Archived-At: Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 22:12:39 -0000 --001a114580ee160d9305444691aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It's possible I'm misunderstanding your message here (I'm a little confused by the mention of combining normal certificate authentication with an external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. That's the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by the server by sending both pre_shared_key and key_share extensions. Perhaps the wording should be a bit clearer. Our stack does not even implement psk_ke. It always requires an (EC)DH operation in a TLS 1.3 handshake, whether using PSK or certificates. David On Thu, Dec 22, 2016 at 4:54 PM Russ Housley wrote: > I want to make sure that it is possible to mix PSK with (EC)DH as a > protection against the discovery of a quantum computer. I recognize that > the WG does not want to tackle this topic in the base specification; > however, the following text in Section 4.1.1 makes this difficult to do s= o > in a companion document: > > > The server indicates its selected parameters in the ServerHello as > > follows: > > > > - If PSK is being used then the server will send a "pre_shared_key" > > extension indicating the selected key. > > > > - If PSK is not being used, then (EC)DHE and certificate-based > > authentication are always used. > > > > - When (EC)DHE is in use, the server will also provide a "key_share= " > > extension. > > > > - When authenticating via a certificate (i.e., when a PSK is not in > > use), the server will send the Certificate (Section 4.4.1) and > > CertificateVerify (Section 4.4.2) messages. > > An Internal PSK offers no protection against the discovery of a quantum > computer. I assume that an attacker can save the handshake that > established the Internal PSK, and then at some future date use the quantu= m > computer to discover the Internal PSK. Therefore, protection against the > discovery of a quantum computer is only concerned with External PSK. > > I would like for the specification to permit normal certificate > authentication when someone is using an External PSK. I am guessing that > the granularity of the name associated with the External PSK to be pretty > broad. If this guess is correct, it would be appropriate for the name in > the certificate to be further restrict the one associated with the Extern= al > PSK. Maybe the External PSK is associated with example.com, and then the > certificate that includes www.example.com would be acceptable > acceptable. Then, I would expect any Internal PSK that is generated afte= r > such an authentication would be associated with the more granular > certificate name. > > Maybe it is as simple as reorganizing these bullets like this: > > - When only PSK is being used, =E2=80=A6 > > - When only (EC)DHE is being used, =E2=80=A6 > > - When PSK and (EC)DHE are both being used, =E2=80=A6 > > If others agree with this direction, I am willing to propose some text. > > Happy holidays, > Russ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114580ee160d9305444691aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's possible I'm misunderstanding your message he= re (I'm a little confused by the mention of combining normal certificat= e authentication with an external PSK), but TLS 1.3 already allows doing bo= th PSK and (EC)DH. That's the psk_dhe_ke mode, rather than the psk_ke m= ode. It's signaled by the server by sending both pre_shared_key and key= _share extensions. Perhaps the wording should be a bit clearer.

Our stack does not even implement psk_ke. It=C2=A0always requires a= n (EC)DH operation in a TLS 1.3 handshake, whether using PSK or certificate= s.

David

On Thu, Dec 22, 2016 at 4:54 PM Russ Housley <housley@vigilsec.com> wrote:
I want to make sure that it is possible = to mix PSK with (EC)DH as a protection against the discovery of a quantum c= omputer.=C2=A0 I recognize that the WG does not want to tackle this topic i= n the base specification; however, the following text in Section 4.1.1 make= s this difficult to do so in a companion document:

>=C2=A0 =C2=A0 The server indicates its selected parameters in the Serve= rHello as
>=C2=A0 =C2=A0 follows:
>
>=C2=A0 =C2=A0 -=C2=A0 If PSK is being used then the server will send a = "pre_shared_key"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0extension indicating the selected key.
>
>=C2=A0 =C2=A0 -=C2=A0 If PSK is not being used, then (EC)DHE and certif= icate-based
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authentication are always used.
>
>=C2=A0 =C2=A0 -=C2=A0 When (EC)DHE is in use, the server will also prov= ide a "key_share"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0extension.
>
>=C2=A0 =C2=A0 -=C2=A0 When authenticating via a certificate (i.e., when= a PSK is not in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use), the server will send the Certificate (= Section 4.4.1) and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateVerify (Section 4.4.2) messages.<= br class=3D"gmail_msg">
An Internal PSK offers no protection against the discovery of a quantum com= puter.=C2=A0 I assume that an attacker can save the handshake that establis= hed the Internal PSK, and then at some future date use the quantum computer= to discover the Internal PSK.=C2=A0 Therefore, protection against the disc= overy of a quantum computer is only concerned with External PSK.

I would like for the specification to permit normal certificate authenticat= ion when someone is using an External PSK.=C2=A0 I am guessing that the gra= nularity of the name associated with the External PSK to be pretty broad.= =C2=A0 If this guess is correct, it would be appropriate for the name in th= e certificate to be further restrict the one associated with the External P= SK.=C2=A0 Maybe the External PSK is associated with example.co= m, and then the certificate that includes www.example.= com would be acceptable acceptable.=C2=A0 Then, I would expect any Inte= rnal PSK that is generated after such an authentication would be associated= with the more granular certificate name.

Maybe it is as simple as reorganizing these bullets like this:

=C2=A0 =C2=A0- When only PSK is being used, =E2=80=A6

=C2=A0 =C2=A0- When only (EC)DHE is being used, =E2=80=A6

=C2=A0 =C2=A0- When PSK and (EC)DHE are both being used, =E2=80=A6

If others agree with this direction, I am willing to propose some text.

Happy holidays,
=C2=A0 =C2=A0Russ
_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a114580ee160d9305444691aa-- From nobody Thu Dec 22 14:29:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D931295FB for ; Thu, 22 Dec 2016 14:29:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG1oyAWmFDik for ; Thu, 22 Dec 2016 14:29:01 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::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 5D51C1279EB for ; Thu, 22 Dec 2016 14:29:01 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id h133so5019901ioe.3 for ; Thu, 22 Dec 2016 14:29:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6U/pqsU5BnksqhapF2LSuHXIGh+wpD1qscY/OgjWJTg=; b=hcsMUSyhDilJKQqyXeZx+SMuLhyfHVQXmU/w7ZEgswAtxx/1i0fy7mK52/uayC9pQD 4bxd5oxnpqyz/9ell981iV2eVjRdOfKTwSWo2W683eFDOuueswz8ekLQuDTM9GKYoUyK zL02iVeUrgcBouW1vPMZd4oiXTaIR3brt6lz0FyiPbJWbgAnobcy4C9ku3bWhDqTGPM/ bKj2ZHcO+BkjOl/+Z9imm6JyotM7p4xID8z/nJxH6c8XJc8/dNxhDs4XHlIzsudDFJQ1 ydfSFPH0t1oBNnmwvTgOeX+sh39ZdR4rXt/sH+D42Asw08CsR9lpUUVsVqhppF2fwlqe pZxA== 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=6U/pqsU5BnksqhapF2LSuHXIGh+wpD1qscY/OgjWJTg=; b=IB60hoY3HMu4gSeX09J47TRG5zHcI/3eZ4YYtTvJdYvQsx6TYkChsppXUwyZcewjXa RYX2TFK0XdEUQq9A3vgLYrhXiuc9eMGEYEMJSXT4rZueGSN8foYZw2PUCLkpWgZttn2T 07fYBt5zRdi4gZozh+CVUKZ6rJKKRGGHniC9bX9hm3LQPrPh+qT6nDZV0xP1YrU2nkEc C0w+vh8a6aL72QkP4PExi/hhyCzgtkHeKdtKIH+Dvc7x5p8KYSZ+dfSsYTe/xguQ5sSg yayX0V1kGZL0szi5svdwGhjYSsXUE0M3j8iCnev1HLPbvOxyrHAkohMezcrwK07BGGj/ /KZg== X-Gm-Message-State: AIkVDXK60LRHkB3uPug4SOE8mHNlTmDrmnZUSiDOz2nLqp/zSpFVOKuZ5Z0L6E3kbA+ntGYij5KWtiAWEPOLSQ== X-Received: by 10.107.18.162 with SMTP id 34mr1910047ios.14.1482445740621; Thu, 22 Dec 2016 14:29:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.15.73 with HTTP; Thu, 22 Dec 2016 14:28:40 -0800 (PST) In-Reply-To: References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> From: Joseph Salowey Date: Thu, 22 Dec 2016 14:28:40 -0800 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a113f6216c4d6fc054446cb90 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 22:29:04 -0000 --001a113f6216c4d6fc054446cb90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Does you implementation allow a PSK to be used along with certificate based authentication? On Thu, Dec 22, 2016 at 2:12 PM, David Benjamin wrote: > It's possible I'm misunderstanding your message here (I'm a little > confused by the mention of combining normal certificate authentication wi= th > an external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. > That's the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by > the server by sending both pre_shared_key and key_share extensions. Perha= ps > the wording should be a bit clearer. > > Our stack does not even implement psk_ke. It always requires an (EC)DH > operation in a TLS 1.3 handshake, whether using PSK or certificates. > > David > > > On Thu, Dec 22, 2016 at 4:54 PM Russ Housley wrote= : > >> I want to make sure that it is possible to mix PSK with (EC)DH as a >> protection against the discovery of a quantum computer. I recognize tha= t >> the WG does not want to tackle this topic in the base specification; >> however, the following text in Section 4.1.1 makes this difficult to do = so >> in a companion document: >> >> > The server indicates its selected parameters in the ServerHello as >> > follows: >> > >> > - If PSK is being used then the server will send a "pre_shared_key= " >> > extension indicating the selected key. >> > >> > - If PSK is not being used, then (EC)DHE and certificate-based >> > authentication are always used. >> > >> > - When (EC)DHE is in use, the server will also provide a "key_shar= e" >> > extension. >> > >> > - When authenticating via a certificate (i.e., when a PSK is not i= n >> > use), the server will send the Certificate (Section 4.4.1) and >> > CertificateVerify (Section 4.4.2) messages. >> >> An Internal PSK offers no protection against the discovery of a quantum >> computer. I assume that an attacker can save the handshake that >> established the Internal PSK, and then at some future date use the quant= um >> computer to discover the Internal PSK. Therefore, protection against th= e >> discovery of a quantum computer is only concerned with External PSK. >> >> I would like for the specification to permit normal certificate >> authentication when someone is using an External PSK. I am guessing tha= t >> the granularity of the name associated with the External PSK to be prett= y >> broad. If this guess is correct, it would be appropriate for the name i= n >> the certificate to be further restrict the one associated with the Exter= nal >> PSK. Maybe the External PSK is associated with example.com, and then >> the certificate that includes www.example.com would be acceptable >> acceptable. Then, I would expect any Internal PSK that is generated aft= er >> such an authentication would be associated with the more granular >> certificate name. >> >> Maybe it is as simple as reorganizing these bullets like this: >> >> - When only PSK is being used, =E2=80=A6 >> >> - When only (EC)DHE is being used, =E2=80=A6 >> >> - When PSK and (EC)DHE are both being used, =E2=80=A6 >> >> If others agree with this direction, I am willing to propose some text. >> >> Happy holidays, >> Russ >> _______________________________________________ >> 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 > > --001a113f6216c4d6fc054446cb90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

D= oes you implementation allow a PSK to be used along with certificate based authentication?=C2=A0=C2=A0


On Thu, Dec= 22, 2016 at 2:12 PM, David Benjamin <davidben@chromium.org> wrote:
It's pos= sible I'm misunderstanding your message here (I'm a little confused= by the mention of combining normal certificate authentication with an exte= rnal PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. That's= the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by the= server by sending both pre_shared_key and key_share extensions. Perhaps th= e wording should be a bit clearer.

Our stack does not ev= en implement psk_ke. It=C2=A0always requires an (EC)DH operation in a TLS 1= .3 handshake, whether using PSK or certificates.

David


On Thu, Dec 22= , 2016 at 4:54 PM Russ Housley <housley@vigilsec.com> wrote:
I want to make sure that it is possible to mix PSK with = (EC)DH as a protection against the discovery of a quantum computer.=C2=A0 I= recognize that the WG does not want to tackle this topic in the base speci= fication; however, the following text in Section 4.1.1 makes this difficult= to do so in a companion document:

>=C2=A0 =C2=A0 The server indicates its selected parameters in the Serve= rHello as
>=C2=A0 =C2=A0 follows:
>
>=C2=A0 =C2=A0 -=C2=A0 If PSK is being used then the server will send a = "pre_shared_key"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0extension indicating the selected key.
>
>=C2=A0 =C2=A0 -=C2=A0 If PSK is not being used, then (EC)DHE and certif= icate-based
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authentication are always used.
>
>=C2=A0 =C2=A0 -=C2=A0 When (EC)DHE is in use, the server will also prov= ide a "key_share"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0extension.
>
>=C2=A0 =C2=A0 -=C2=A0 When authenticating via a certificate (i.e., when= a PSK is not in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use), the server will send the Certificate (= Section 4.4.1) and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateVerify (Section 4.4.2) messages.<= br class=3D"m_-2200036306902128867gmail_msg">
An Internal PSK offers no protection against the discovery of a quantum com= puter.=C2=A0 I assume that an attacker can save the handshake that establis= hed the Internal PSK, and then at some future date use the quantum computer= to discover the Internal PSK.=C2=A0 Therefore, protection against the disc= overy of a quantum computer is only concerned with External PSK.

I would like for the specification to permit normal certificate authenticat= ion when someone is using an External PSK.=C2=A0 I am guessing that the gra= nularity of the name associated with the External PSK to be pretty broad.= =C2=A0 If this guess is correct, it would be appropriate for the name in th= e certificate to be further restrict the one associated with the External P= SK.=C2=A0 Maybe the External PSK is associated with example.com, and then the certificate that includes www.example.com would be acceptable acc= eptable.=C2=A0 Then, I would expect any Internal PSK that is generated afte= r such an authentication would be associated with the more granular certifi= cate name.

Maybe it is as simple as reorganizing these bullets like this:

=C2=A0 =C2=A0- When only PSK is being used, =E2=80=A6

=C2=A0 =C2=A0- When only (EC)DHE is being used, =E2=80=A6

=C2=A0 =C2=A0- When PSK and (EC)DHE are both being used, =E2=80=A6

If others agree with this direction, I am willing to propose some text.

Happy holidays,
=C2=A0 =C2=A0Russ
_______________________________________________
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


--001a113f6216c4d6fc054446cb90-- From nobody Thu Dec 22 14:36:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5B1298AA for ; Thu, 22 Dec 2016 14:36:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xs4ewO2CLEAj for ; Thu, 22 Dec 2016 14:36:08 -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 303611279EB for ; Thu, 22 Dec 2016 14:29:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id F27773002B9 for ; Thu, 22 Dec 2016 17:19:19 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6ZXwmsgD1mSw for ; Thu, 22 Dec 2016 17:19:18 -0500 (EST) Received: from [192.168.2.100] (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id D723A30025C; Thu, 22 Dec 2016 17:19:17 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_5621000A-ADBD-44FA-A503-93D10F4E89C0" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Thu, 22 Dec 2016 17:29:45 -0500 Message-Id: <9D8BEE12-49F9-4DE3-81C7-909CB114805F@vigilsec.com> References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> To: David Benjamin X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF TLS Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 22:36:09 -0000 --Apple-Mail=_5621000A-ADBD-44FA-A503-93D10F4E89C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 David: Yes, it does allow both, but the authentication is unclear when both are = in play. The last bullet implies that certificate authentication only = comes into play when there is no PSK. So, if there is a PSK, the = identity associated with it seems to trump whatever is in the = certificate. As I explained below, I=92d like the identity associate with the = External PSK and the identity in the certificate to both have a role. Russ On Dec 22, 2016, at 5:12 PM, David Benjamin = wrote: > It's possible I'm misunderstanding your message here (I'm a little = confused by the mention of combining normal certificate authentication = with an external PSK), but TLS 1.3 already allows doing both PSK and = (EC)DH. That's the psk_dhe_ke mode, rather than the psk_ke mode. It's = signaled by the server by sending both pre_shared_key and key_share = extensions. Perhaps the wording should be a bit clearer. >=20 > Our stack does not even implement psk_ke. It always requires an (EC)DH = operation in a TLS 1.3 handshake, whether using PSK or certificates. >=20 > David >=20 > On Thu, Dec 22, 2016 at 4:54 PM Russ Housley = wrote: > I want to make sure that it is possible to mix PSK with (EC)DH as a = protection against the discovery of a quantum computer. I recognize = that the WG does not want to tackle this topic in the base = specification; however, the following text in Section 4.1.1 makes this = difficult to do so in a companion document: >=20 > > The server indicates its selected parameters in the ServerHello = as > > follows: > > > > - If PSK is being used then the server will send a = "pre_shared_key" > > extension indicating the selected key. > > > > - If PSK is not being used, then (EC)DHE and certificate-based > > authentication are always used. > > > > - When (EC)DHE is in use, the server will also provide a = "key_share" > > extension. > > > > - When authenticating via a certificate (i.e., when a PSK is not = in > > use), the server will send the Certificate (Section 4.4.1) and > > CertificateVerify (Section 4.4.2) messages. >=20 > An Internal PSK offers no protection against the discovery of a = quantum computer. I assume that an attacker can save the handshake that = established the Internal PSK, and then at some future date use the = quantum computer to discover the Internal PSK. Therefore, protection = against the discovery of a quantum computer is only concerned with = External PSK. >=20 > I would like for the specification to permit normal certificate = authentication when someone is using an External PSK. I am guessing = that the granularity of the name associated with the External PSK to be = pretty broad. If this guess is correct, it would be appropriate for the = name in the certificate to be further restrict the one associated with = the External PSK. Maybe the External PSK is associated with = example.com, and then the certificate that includes www.example.com = would be acceptable acceptable. Then, I would expect any Internal PSK = that is generated after such an authentication would be associated with = the more granular certificate name. >=20 > Maybe it is as simple as reorganizing these bullets like this: >=20 > - When only PSK is being used, =85 >=20 > - When only (EC)DHE is being used, =85 >=20 > - When PSK and (EC)DHE are both being used, =85 >=20 > If others agree with this direction, I am willing to propose some = text. >=20 > Happy holidays, > Russ > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_5621000A-ADBD-44FA-A503-93D10F4E89C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 David:

Yes, it does allow both, = but the authentication is unclear when both are in play. The last bullet = implies that certificate authentication only comes into play when there = is no PSK.  So, if there is a PSK, the identity associated with it = seems to trump whatever is in the = certificate.

As I explained below, I=92d like = the identity associate with the External PSK and the identity in the = certificate to both have a = role.

Russ


On Dec 22, 2016, at 5:12 PM, David Benjamin <davidben@chromium.org> = wrote:

It's possible I'm misunderstanding your = message here (I'm a little confused by the mention of combining normal = certificate authentication with an external PSK), but TLS 1.3 already = allows doing both PSK and (EC)DH. That's the psk_dhe_ke mode, rather = than the psk_ke mode. It's signaled by the server by sending both = pre_shared_key and key_share extensions. Perhaps the wording should be a = bit clearer.

Our stack does not even implement = psk_ke. It always requires an (EC)DH operation in a TLS 1.3 = handshake, whether using PSK or = certificates.

David

On Thu, Dec 22, 2016 at 4:54 PM = Russ Housley <housley@vigilsec.com> = wrote:
I want to make sure that it is possible to mix PSK with = (EC)DH as a protection against the discovery of a quantum = computer.  I recognize that the WG does not want to tackle this = topic in the base specification; however, the following text in Section = 4.1.1 makes this difficult to do so in a companion document:

>    The server indicates its selected parameters in the = ServerHello as
>    follows:
>
>    -  If PSK is being used then the server will send = a "pre_shared_key"
>       extension indicating the selected key.
>
>    -  If PSK is not being used, then (EC)DHE and = certificate-based
>       authentication are always used.
>
>    -  When (EC)DHE is in use, the server will also = provide a "key_share"
>       extension.
>
>    -  When authenticating via a certificate (i.e., = when a PSK is not in
>       use), the server will send the = Certificate (Section 4.4.1) and
>       CertificateVerify (Section 4.4.2) = messages.

An Internal PSK offers no protection against the discovery of a quantum = computer.  I assume that an attacker can save the handshake that = established the Internal PSK, and then at some future date use the = quantum computer to discover the Internal PSK.  Therefore, = protection against the discovery of a quantum computer is only concerned = with External PSK.

I would like for the specification to permit normal certificate = authentication when someone is using an External PSK.  I am = guessing that the granularity of the name associated with the External = PSK to be pretty broad.  If this guess is correct, it would be = appropriate for the name in the certificate to be further restrict the = one associated with the External PSK.  Maybe the External PSK is = associated with example.com, and then the = certificate that includes www.example.com would be acceptable = acceptable.  Then, I would expect any Internal PSK that is = generated after such an authentication would be associated with the more = granular certificate name.

Maybe it is as simple as reorganizing these bullets like this:

   - When only PSK is being used, =85

   - When only (EC)DHE is being used, =85

   - When PSK and (EC)DHE are both being used, =85

If others agree with this direction, I am willing to propose some = text.

Happy holidays,
   Russ
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_5621000A-ADBD-44FA-A503-93D10F4E89C0-- From nobody Thu Dec 22 14:46:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056C11295CC for ; Thu, 22 Dec 2016 14:46:06 -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 UWNUDHs3hTkY for ; Thu, 22 Dec 2016 14:46:03 -0800 (PST) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C291279EB for ; Thu, 22 Dec 2016 14:46:03 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id r204so122300054ywb.0 for ; Thu, 22 Dec 2016 14:46:03 -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=6+u4izeqbWidNTEoePDWYsXXVsrpZV1+3mRHvVhyrTY=; b=x5+WcT2OrKPb40WCOc6wyqCEf0gc9Ew/te0z9dPdlzxyvHeszcKjUU15fOK8A6W5G6 bZC1rk4L1A2cGG9NvKefQZ8IARjL963sAEFwrEHOFYa9yayDsJXp4DOFAItq0Kl2E7Yy f3kGuKMJzHwuoXmpzCnDsaZfxhn0hyvvuGcs4SWbEGtuE3AxPTzK1+rVJcnow2aQFui4 KEFVd3HSn+G7NmhfuLfFE0Fkc5YoTpPWlzD9SPWWvRr03SdyC6von3To8QlEQHFDxZDz HVfyV3on4V8+g8F+Bc/DXpNj4gddZo3ZyASZxK+5Zl2fa1tzT7aPkRP7aSGF6Sluop3j QanA== 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=6+u4izeqbWidNTEoePDWYsXXVsrpZV1+3mRHvVhyrTY=; b=rM/Fa8cL5AT7Ck3T0XFfAApGjiLL972HsTSs69prjqTJ1nfBa+pas4NquGaMsZv3W/ NeEeQo1SVeCeus3yfYe6lyCLQyWkSPAR73KDlPXoBOCEZnRF2wpmCGCC+0MW3hHQWLYj 3mz5g8CBfR2KjW146lj9Rm4cerEd3le96Ry3Fbnqad75o+8kN+8htGcE/CuSOt/ndIV9 0SJk76lycMau5qJ8qiyNFq6ouhsR3Ec8nkt2ZenUO2iU9hIFed3fi2Qlx5pbxfNWKqEB asw1B+gIw1G8D8qybaR2EzfzPEIRUOb3GozzOxHkxTz4z4D3HR47NDHhQNeLJDu1cEPM lGBw== X-Gm-Message-State: AIkVDXJYfn/ITpff3jv4QI/RXHVKCf0N6Sk7o8aSpq6oGBmzGPex1PQCHGp/+D/ySiUtoPCwGH81Ogt0l37OSw== X-Received: by 10.129.53.203 with SMTP id c194mr7658511ywa.205.1482446762827; Thu, 22 Dec 2016 14:46:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Thu, 22 Dec 2016 14:45:22 -0800 (PST) In-Reply-To: References: <0DA64421-5975-4B7E-BC08-7428AFA9D1A1@vigilsec.com> From: Eric Rescorla Date: Thu, 22 Dec 2016 14:45:22 -0800 Message-ID: To: Joseph Salowey Content-Type: multipart/alternative; boundary=001a11422656b2917a05444708b1 Archived-At: Cc: IETF TLS Subject: Re: [TLS] Using both External PSK and (EC)DH in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Dec 2016 22:46:06 -0000 --001a11422656b2917a05444708b1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 22, 2016 at 2:28 PM, Joseph Salowey wrote: > Does you implementation allow a PSK to be used along with certificate > based authentication? > There is presently no way to negotiate this in TLS 1.3. I have been assuming that if we decide we want this we would add a psk_auth_mode extension to parallel psk_ke_mode. The sense of a number of us is that there are enough complications with adding this feature (consider what happens if the server provides a different set of SANs....) that we should add it later. -Ekr > On Thu, Dec 22, 2016 at 2:12 PM, David Benjamin > wrote: > >> It's possible I'm misunderstanding your message here (I'm a little >> confused by the mention of combining normal certificate authentication w= ith >> an external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. >> That's the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled b= y >> the server by sending both pre_shared_key and key_share extensions. Perh= aps >> the wording should be a bit clearer. >> >> Our stack does not even implement psk_ke. It always requires an (EC)DH >> operation in a TLS 1.3 handshake, whether using PSK or certificates. >> >> David >> >> >> On Thu, Dec 22, 2016 at 4:54 PM Russ Housley >> wrote: >> >>> I want to make sure that it is possible to mix PSK with (EC)DH as a >>> protection against the discovery of a quantum computer. I recognize th= at >>> the WG does not want to tackle this topic in the base specification; >>> however, the following text in Section 4.1.1 makes this difficult to do= so >>> in a companion document: >>> >>> > The server indicates its selected parameters in the ServerHello as >>> > follows: >>> > >>> > - If PSK is being used then the server will send a "pre_shared_ke= y" >>> > extension indicating the selected key. >>> > >>> > - If PSK is not being used, then (EC)DHE and certificate-based >>> > authentication are always used. >>> > >>> > - When (EC)DHE is in use, the server will also provide a >>> "key_share" >>> > extension. >>> > >>> > - When authenticating via a certificate (i.e., when a PSK is not = in >>> > use), the server will send the Certificate (Section 4.4.1) and >>> > CertificateVerify (Section 4.4.2) messages. >>> >>> An Internal PSK offers no protection against the discovery of a quantum >>> computer. I assume that an attacker can save the handshake that >>> established the Internal PSK, and then at some future date use the quan= tum >>> computer to discover the Internal PSK. Therefore, protection against t= he >>> discovery of a quantum computer is only concerned with External PSK. >>> >>> I would like for the specification to permit normal certificate >>> authentication when someone is using an External PSK. I am guessing th= at >>> the granularity of the name associated with the External PSK to be pret= ty >>> broad. If this guess is correct, it would be appropriate for the name = in >>> the certificate to be further restrict the one associated with the Exte= rnal >>> PSK. Maybe the External PSK is associated with example.com, and then >>> the certificate that includes www.example.com would be acceptable >>> acceptable. Then, I would expect any Internal PSK that is generated af= ter >>> such an authentication would be associated with the more granular >>> certificate name. >>> >>> Maybe it is as simple as reorganizing these bullets like this: >>> >>> - When only PSK is being used, =E2=80=A6 >>> >>> - When only (EC)DHE is being used, =E2=80=A6 >>> >>> - When PSK and (EC)DHE are both being used, =E2=80=A6 >>> >>> If others agree with this direction, I am willing to propose some text. >>> >>> Happy holidays, >>> Russ >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11422656b2917a05444708b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 22, 2016 at 2:28 PM, Joseph Salowey <<= a href=3D"mailto:joe@salowey.net" target=3D"_blank">joe@salowey.net>= wrote:

D= oes you implementation allow a PSK to be used along with certificate based authentication?=C2=A0=C2=A0


There is presently no way t= o negotiate this in TLS 1.3. I have been assuming that if we decide we
want this we would add a psk_auth_mode extension to parallel psk_ke_m= ode. The sense of a number
of us is that there are enough complic= ations with adding this feature (consider what happens if the
ser= ver provides a different set of SANs....) that we should add it later.

-Ekr


On= Thu, Dec 22, 2016 at 2:12 PM, David Benjamin <davidben@chromium.org> wrote:
It&= #39;s possible I'm misunderstanding your message here (I'm a little= confused by the mention of combining normal certificate authentication wit= h an external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. T= hat's the psk_dhe_ke mode, rather than the psk_ke mode. It's signal= ed by the server by sending both pre_shared_key and key_share extensions. P= erhaps the wording should be a bit clearer.

Our stack do= es not even implement psk_ke. It=C2=A0always requires an (EC)DH operation i= n a TLS 1.3 handshake, whether using PSK or certificates.

David<= /span>

On Thu, Dec 22, 2016 at 4:= 54 PM Russ Housley <housley@vigilsec.com> wrote:
I want to make sure that it is possible to mix PSK with (EC)DH as a = protection against the discovery of a quantum computer.=C2=A0 I recognize t= hat the WG does not want to tackle this topic in the base specification; ho= wever, the following text in Section 4.1.1 makes this difficult to do so in= a companion document:

>=C2=A0 =C2=A0 The server indicates its selected parameters in the Serve= rHello as
>=C2=A0 =C2=A0 follows:
>
>=C2=A0 =C2=A0 -=C2=A0 If PSK is being used then the server will send a = "pre_shared_key"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0extension indicating the selected key.
>
>=C2=A0 =C2=A0 -=C2=A0 If PSK is not being used, then (EC)DHE and certif= icate-based
>=C2=A0 =C2=A0 =C2=A0 =C2=A0authentication are always used.
>
>=C2=A0 =C2=A0 -=C2=A0 When (EC)DHE is in use, the server will also prov= ide a "key_share"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0extension.
>
>=C2=A0 =C2=A0 -=C2=A0 When authenticating via a certificate (i.e., when= a PSK is not in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0use), the server will send the Certificate (= Section 4.4.1) and
>=C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateVerify (Section 4.4.2) messages.<= br class=3D"m_-8784569679826760129m_3505247621825925368m_-22000363069021288= 67gmail_msg">
An Internal PSK offers no protection against the discovery of a quantum com= puter.=C2=A0 I assume that an attacker can save the handshake that establis= hed the Internal PSK, and then at some future date use the quantum computer= to discover the Internal PSK.=C2=A0 Therefore, protection against the disc= overy of a quantum computer is only concerned with External PSK.

I would like for the specification to permit normal certificate authenticat= ion when someone is using an External PSK.=C2=A0 I am guessing that the gra= nularity of the name associated with the External PSK to be pretty broad.= =C2=A0 If this guess is correct, it would be appropriate for the name in th= e certificate to be further restrict the one associated with the External P= SK.=C2=A0 Maybe the External PSK is associated with example.com, and= then the certificate that includes www.example.com would be ac= ceptable acceptable.=C2=A0 Then, I would expect any Internal PSK that is ge= nerated after such an authentication would be associated with the more gran= ular certificate name.

Maybe it is as simple as reorganizing these bullets like this:

=C2=A0 =C2=A0- When only PSK is being used, =E2=80=A6

=C2=A0 =C2=A0- When only (EC)DHE is being used, =E2=80=A6

=C2=A0 =C2=A0- When PSK and (EC)DHE are both being used, =E2=80=A6

If others agree with this direction, I am willing to propose some text.

Happy holidays,
=C2=A0 =C2=A0Russ
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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



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


--001a11422656b2917a05444708b1-- From nobody Tue Dec 27 13:44:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E87FE129736 for ; Tue, 27 Dec 2016 13:44:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 T4mtrXpKHXgB for ; Tue, 27 Dec 2016 13:44:09 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::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 0A69812970F for ; Tue, 27 Dec 2016 13:44:09 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id 128so161324195oig.0 for ; Tue, 27 Dec 2016 13:44:09 -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=6D8XZ5iAyrpxOhf5LwtLI+vFQ9Fs/RTRKfWj1+FlIWg=; b=Lg1d9ZmZSEoU7lcQMDS6q6ebeG2vGv9vJ+w/Ws44zGJ/BlM82vNnu6O0Q+arP/OK5w SG44dxo+qyQDTssn5kpqtp3A79+pmX30QACEY0+mYgnLx9eZhR7wuoMr7Mw8cQGB5F0C NEpl0BxKUWf2GobzX9VkS9b50Wa4Te70GPrip9Y9viaVOsDP5F5+nV1A8JpPXoaGMcLP CDvvpgz06wo1k9ShJTZdQMAavLJT9wadM4errs0AFVdWKLSNISK7py2g8oOLu01lvLBP bjGTXBxrexgIfcoxoFjubre0CzRdVPI1BlpNxbYKtRWs21rk4ZBium3tEstaD3Zh9ork UQog== 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=6D8XZ5iAyrpxOhf5LwtLI+vFQ9Fs/RTRKfWj1+FlIWg=; b=MTVBG0L8ogZa6lKgHXSaFQ7L1iJtVymp3/GFgTnFj6rTJmnVIteyjkMpQ/7ai3ud4a rWWP/BjmSFvguaFYrZxnFzsEOxi+dLdjOR0EkAhrFRWpv9xKjMm2nu55RPJm/0Npt3gP IXsgKff/ha/zKi8i94BcYilQIP+7iJQJ+ow7pAzkdp9VitaOuFzQziS15VUmhQz4tzki NihPSpEp1undVgz4+NAm/tCHCWviinFkoWEwBMfpo8paaBp5IjeAxKaU8hrMcC7+fAci g32HMP9N0rXUTyjq8Zg3HCuYXDm46XeG+4s+ZJEHFUgPw8J7M/Db+OHki0AdsxyzZVZg lT8g== X-Gm-Message-State: AIkVDXLJr/PmCgu7t0nBtEdy/uJFrjYhndFdTtZZJ1No5zeYaRysdN+kP4E8FUh2gnfnzTrgWeu1C95z3tHAMg== X-Received: by 10.157.9.152 with SMTP id q24mr16598597otd.98.1482875048175; Tue, 27 Dec 2016 13:44:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.206.46 with HTTP; Tue, 27 Dec 2016 13:43:27 -0800 (PST) From: Joseph Birr-Pixton Date: Tue, 27 Dec 2016 21:43:27 +0000 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 21:44:10 -0000 Hi folks, It appears to me that HRR is a pretty large and tricky source of complexity in TLS1.3. Judging by the implementations page, 40% don't support it right now. It's *precisely the kind of thing* that vendors could easily ship broken/missing support for, and they'd get away with it for years until it causes a interop problem. The only case where it is used is (4.1.1): If there is overlap in the "supported_groups" extension but the client did not offer a compatible "key_share" extension, then the server will respond with a HelloRetryRequest We could entirely remove HRR if we slightly strengthen the MTI language covering kx groups: - Clients must not only "implement", but actually offer a key share for NISTP-256 for every ClientHello. Note: Obviously, this doesn't apply to PSK-only connections where psk_key_exchange_modes was provided and did not contain psk_dhe_ke. This need not have any additional computational overhead, because the client can amortise the key generation over all handshakes where the server does not select P-256 (hopefully most of them!). In any case, it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the wire, but only if the client wasn't going to send a NISTP-256 share otherwise. Did I miss something? Are there any other uses of HRR in TLS1.3 which means we can't get rid of it in this way? Cheers, Joe From nobody Tue Dec 27 14:27:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E170129472 for ; Tue, 27 Dec 2016 14:27:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.718 X-Spam-Level: X-Spam-Status: No, score=-1.718 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, FREEMAIL_REPLY=1, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWtO5wH-jFao for ; Tue, 27 Dec 2016 14:27:16 -0800 (PST) Received: from BLU004-OMC2S16.hotmail.com (blu004-omc2s16.hotmail.com [65.55.111.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DE312941D for ; Tue, 27 Dec 2016 14:27:16 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com ([65.55.111.73]) by BLU004-OMC2S16.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 27 Dec 2016 14:27:15 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=39hvU8N55s4eK96l0dA31ilugkSL8odEDGkGGH3gfpA=; b=WIoIPBT/YARnK0PEjZlXABhD4mycl6d6ephvmdvoMU5PNIbn7pJbuTLeGPEkxZiuyU8ccIy76935KVSHynVfNZvp5qLq4YwVyxHmHiN3jP4sJhUZEIDIvKOBFBgTvqC6CwzjrkaSWeuEQJHCWgGHVzznYY4o6ZcryF8xu+C94ILx0Hx5u7kepnvdvEzTrz8WlNQYFQBigCyQ5h4yRzVCtiyAS073gVz9/ifq9HlbYyGxzb4TQMFDt4i0vX63w1isVGJzy/WHq44RimHvAgW2dPZp/0CCQtrVtWol33YYO5aWCPkfMLyUYFX6qVEn80Mvdoyo8zxXBY53lH4MkYuCfw== Received: from SN1NAM04FT048.eop-NAM04.prod.protection.outlook.com (10.152.88.60) by SN1NAM04HT226.eop-NAM04.prod.protection.outlook.com (10.152.88.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.10; Tue, 27 Dec 2016 22:27:14 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.88.52) by SN1NAM04FT048.mail.protection.outlook.com (10.152.89.195) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.789.10 via Frontend Transport; Tue, 27 Dec 2016 22:27:13 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0803.021; Tue, 27 Dec 2016 22:27:13 +0000 From: Xiaoyin Liu To: Joseph Birr-Pixton , "tls@ietf.org" Thread-Topic: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share" Thread-Index: AQHSYIpjgOZS1sV9F0GpO2vvi1qrnaEcX6hc Date: Tue, 27 Dec 2016 22:27:13 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:6E51FFB13A3CB820F4AA5FA9D8B47ADDF69E2250022F9839DBB16C9ACE5B6646; UpperCasedChecksum:AD063ACA7C6A2A389D1C3ABA4A2626C6600DC31594576C0B7EDFA11A64F4312E; SizeAsReceived:7493; Count:39 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [r9NdIfIDz1vlt6gU3yyCWBuFPzbB/ne7] x-incomingheadercount: 39 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SN1NAM04HT226; 7:ZJxyZFnE0mA9UPyPHjQZMJOtTEWDnaMhPOihP/gRQmw7lwKnVWcekxoDqX8YNAvig9BwmcN13Wc9SGZXOP8xgKGn/QQ/cKAmkoRT1S1743dg0ygyX0VHjav5LWlrU1zu1huchHrMUxze/OtQ4Gm5kG58DBgeBz6EVCUV+3vqoX/XmqYaumUaVUXD9l7Rr6L1LtVhsokvnilkU/ze+wu8IAm5x8GFEDfpnylPadghciSR1HGtLBH1D+JAHgwNQ7VEf1Ao9z4qO0USMdSchA+YJmgaL410v215ZztKArV+i1BzE6dzsx+1TCB2ASIFEOalMlT1uEOEBpAFG//neVFBQeJMMzv4axm/Kw7JWx3gZjnPkGlfud3Gbao6JI7qdV93vPlfyjFiewKMfSbqLwAvedAF6qmQqzblAC3/R0mb/uNget3s1BP5XXBmR9K1rQ2jUvhtEROTOSVXiqm+Khbmsw== x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM04HT226; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: f8a4fd1b-b80a-4911-3897-08d42ea781df x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(5061506293)(5061507293)(1603103113)(1603101340)(1601125047); SRVR:SN1NAM04HT226; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(444111334)(444112120)(432015012)(82015046); SRVR:SN1NAM04HT226; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM04HT226; x-forefront-prvs: 0169092318 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0778BFB875873116FF8D48C4FF690CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Dec 2016 22:27:13.8387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM04HT226 X-OriginalArrivalTime: 27 Dec 2016 22:27:15.0306 (UTC) FILETIME=[6038D4A0:01D26090] Archived-At: Subject: Re: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 22:27:17 -0000 --_000_CY1PR15MB0778BFB875873116FF8D48C4FF690CY1PR15MB0778namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Joe, My understanding is that we can't get rid of HRR unless we require clients = to send a key_share for every key exchange group in the supported_groups ex= tension. This would be a quite large overhead if the client wants to suppor= t lots of groups. Also HRR allows servers to request clients to echo Cookies. See section 4.2= .2 Cookie. Best, Xiaoyin From: Joseph Birr-Pixton Sent: Tuesday, December 27, 2016 4:44 PM To: tls@ietf.org Subject: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share" Hi folks, It appears to me that HRR is a pretty large and tricky source of complexity in TLS1.3. Judging by the implementations page, 40% don't support it right now. It's *precisely the kind of thing* that vendors could easily ship broken/missing support for, and they'd get away with it for years until it causes a interop problem. The only case where it is used is (4.1.1): If there is overlap in the "supported_groups" extension but the client did not offer a compatible "key_share" extension, then the server will respond with a HelloRetryRequest We could entirely remove HRR if we slightly strengthen the MTI language covering kx groups: - Clients must not only "implement", but actually offer a key share for NISTP-256 for every ClientHello. Note: Obviously, this doesn't apply to PSK-only connections where psk_key_exchange_modes was provided and did not contain psk_dhe_ke. This need not have any additional computational overhead, because the client can amortise the key generation over all handshakes where the server does not select P-256 (hopefully most of them!). In any case, it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the wire, but only if the client wasn't going to send a NISTP-256 share otherwise. Did I miss something? Are there any other uses of HRR in TLS1.3 which means we can't get rid of it in this way? Cheers, Joe _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CY1PR15MB0778BFB875873116FF8D48C4FF690CY1PR15MB0778namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Joe,

 

My understanding is that we can't get rid of HRR u= nless we require clients to send a key_share for every key exchange group i= n the supported_groups extension. This would be a quite large overhead if t= he client wants to support lots of groups.

 

Also HRR allows servers to request clients to echo= Cookies. See section 4.2.2 Cookie.

 

Best,

Xiaoyin

 

From: Joseph Birr-Pixton
Sent: Tuesday, December 27, 2016 4:44 PM
To: tls@ietf.org
Subject: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect = DHE Share"

 

Hi folks,

It appears to me that HRR is a pretty large and tricky source of
complexity in TLS1.3. Judging by the implementations page, 40% don't
support it right now. It's *precisely the kind of thing* that vendors
could easily ship broken/missing support for, and they'd get away with
it for years until it causes a interop problem.

The only case where it is used is (4.1.1):

  If there is overlap in the "supported_groups" extension bu= t the client
  did not offer a compatible "key_share" extension, then the= server will
  respond with a HelloRetryRequest

We could entirely remove HRR if we slightly strengthen the MTI
language covering kx groups:

- Clients must not only "implement", but actually offer a key sha= re
for NISTP-256 for every ClientHello.

Note: Obviously, this doesn't apply to PSK-only connections where
psk_key_exchange_modes was provided and did not contain psk_dhe_ke.

This need not have any additional computational overhead, because the
client can amortise the key generation over all handshakes where the
server does not select P-256 (hopefully most of them!). In any case,
it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the
wire, but only if the client wasn't going to send a NISTP-256 share
otherwise.

Did I miss something? Are there any other uses of HRR in TLS1.3 which
means we can't get rid of it in this way?

Cheers,
Joe

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
 --_000_CY1PR15MB0778BFB875873116FF8D48C4FF690CY1PR15MB0778namp_-- From nobody Tue Dec 27 14:36:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC191293EE for ; Tue, 27 Dec 2016 14:36:09 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4N_6t3QjVP-o for ; Tue, 27 Dec 2016 14:36:08 -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 1DDF912941D for ; Tue, 27 Dec 2016 14:29:51 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id v81so75018070ywb.2 for ; Tue, 27 Dec 2016 14:29:51 -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=WahNB7xZeMG2+HaN/OTKw3zOSU2HeIfeavmD0GdOY5Q=; b=FBeYd5JOvMBuvL5PlV28+Xc0P6YyT8YDa9lmgeQ9gd8w2bRsRfKQlLS7NlH7T5WX69 JkEkzwaUqPwb7bzPjlZ7QOIJUx/jF10z5zBpitlohA2DkM29MxGd8BqJ8QdtEio5+Mzb Iu9lGnVxH1W/MNp2yX1M5wXvlA3tobNv9UeyBnNtU+g14o2BueboGKpFsZFaOEsKIzDQ YjqXCNpCUgNbk6oonf9L8JbK8HP+XeHQYSuafkNTWqpEuVPV2WZ+PVQ1UKCUV9znDOTV 1LH1Cjy9C3FS12IotxArPd9/GriJ/k/oyorWj+rt7c/6aiJGsKIgjlntVz+PN1u2pynp lpBw== 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=WahNB7xZeMG2+HaN/OTKw3zOSU2HeIfeavmD0GdOY5Q=; b=K0rNCNZnXgyRq7kWk+ZYFFz/FLdvZH4172z0Sn1a356UvjfGJou65nnyWLnzsrORZY JKIFYXvpYNNULBI4E6L55ghhNYdSTuoDnk0HmU0IdOrP0DnT9ZgjahQac7S4NoJcvp8u WNwJ22klymSS1ereOdHKq6/RzekwewSQJejhaGt4pnkS6EHQ98OJJW8/1I5JBcLhJs3x Z08uLH3AQMAaQEAcpCXBFAdzWjT4upyzOO1xgt7Ml/UmzbuWVCQZcqyZejs3yMArztdZ sG5d8T9EANzWADuA1bTpm8j+lIbiZ+TViQVt2Sr6D/EJBL+aol+FEcDBy0RIh41jnCQT asJg== X-Gm-Message-State: AIkVDXLBf1fDzFHOG+MlqrsU3sEmyD4+TxLZH/tX8HNtNB0GaGbT2Rxz6Fk6dci5WY7PLZnygajIms7NfJsWmA== X-Received: by 10.13.195.5 with SMTP id f5mr28919925ywd.354.1482877790394; Tue, 27 Dec 2016 14:29:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Tue, 27 Dec 2016 14:29:09 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 27 Dec 2016 14:29:09 -0800 Message-ID: To: Xiaoyin Liu Content-Type: multipart/alternative; boundary=001a114d5fd6f14e3e0544ab639c Archived-At: Cc: "tls@ietf.org" , Joseph Birr-Pixton Subject: Re: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2016 22:36:09 -0000 --001a114d5fd6f14e3e0544ab639c Content-Type: text/plain; charset=UTF-8 On Tue, Dec 27, 2016 at 2:27 PM, Xiaoyin Liu wrote: > Hi Joe, > > > > My understanding is that we can't get rid of HRR unless we require clients > to send a key_share for every key exchange group in the supported_groups > extension. This would be a quite large overhead if the client wants to > support lots of groups. > This is true, but an additional concern is that it makes it basically impossible to switch MTI groups. I.e., people will have to support P-256 forever. > > Also HRR allows servers to request clients to echo Cookies. See section > 4.2.2 Cookie. > This too. -Ekr > > > Best, > > Xiaoyin > > > > *From: *Joseph Birr-Pixton > *Sent: *Tuesday, December 27, 2016 4:44 PM > *To: *tls@ietf.org > *Subject: *[TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE > Share" > > > Hi folks, > > It appears to me that HRR is a pretty large and tricky source of > complexity in TLS1.3. Judging by the implementations page, 40% don't > support it right now. It's *precisely the kind of thing* that vendors > could easily ship broken/missing support for, and they'd get away with > it for years until it causes a interop problem. > > The only case where it is used is (4.1.1): > > If there is overlap in the "supported_groups" extension but the client > did not offer a compatible "key_share" extension, then the server will > respond with a HelloRetryRequest > > We could entirely remove HRR if we slightly strengthen the MTI > language covering kx groups: > > - Clients must not only "implement", but actually offer a key share > for NISTP-256 for every ClientHello. > > Note: Obviously, this doesn't apply to PSK-only connections where > psk_key_exchange_modes was provided and did not contain psk_dhe_ke. > > This need not have any additional computational overhead, because the > client can amortise the key generation over all handshakes where the > server does not select P-256 (hopefully most of them!). In any case, > it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the > wire, but only if the client wasn't going to send a NISTP-256 share > otherwise. > > Did I miss something? Are there any other uses of HRR in TLS1.3 which > means we can't get rid of it in this way? > > Cheers, > Joe > > _______________________________________________ > 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 > > --001a114d5fd6f14e3e0544ab639c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 27, 2016 at 2:27 PM, Xiaoyin Liu <xiaoyin.l@outlook.co= m> wrote:

Hi Joe,

=C2=A0

My understanding is that we = can't get rid of HRR unless we require clients to send a key_share for = every key exchange group in the supported_groups extension. This would be a= quite large overhead if the client wants to support lots of groups.

This is true, but an additi= onal concern is that it makes it basically impossible to switch MTI groups.= I.e., people will have to support P-256 forever.

=C2=A0

Also HRR allows servers to r= equest clients to echo Cookies. See section 4.2.2 Cookie.


This too.

-Ek= r
=C2=A0

=C2=A0

Best,

Xiaoyin

=C2=A0

=C2=A0

Hi folks,

It appears to me that HRR is a pretty large and tricky source of
complexity in TLS1.3. Judging by the implementations page, 40% don't support it right now. It's *precisely the kind of thing* that vendors could easily ship broken/missing support for, and they'd get away with<= br> it for years until it causes a interop problem.

The only case where it is used is (4.1.1):

=C2=A0 If there is overlap in the "supported_groups" extension bu= t the client
=C2=A0 did not offer a compatible "key_share" extension, then the= server will
=C2=A0 respond with a HelloRetryRequest

We could entirely remove HRR if we slightly strengthen the MTI
language covering kx groups:

- Clients must not only "implement", but actually offer a key sha= re
for NISTP-256 for every ClientHello.

Note: Obviously, this doesn't apply to PSK-only connections where
psk_key_exchange_modes was provided and did not contain psk_dhe_ke.

This need not have any additional computational overhead, because the
client can amortise the key generation over all handshakes where the
server does not select P-256 (hopefully most of them!). In any case,
it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the wire, but only if the client wasn't going to send a NISTP-256 share
otherwise.

Did I miss something? Are there any other uses of HRR in TLS1.3 which
means we can't get rid of it in this way?

Cheers,
Joe

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

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


--001a114d5fd6f14e3e0544ab639c-- From nobody Tue Dec 27 19:06:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E039129413 for ; Tue, 27 Dec 2016 19:06:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 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, RP_MATCHES_RCVD=-3.1, 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 bAiDldhVXAO6 for ; Tue, 27 Dec 2016 19:06:32 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 386E71293F0 for ; Tue, 27 Dec 2016 19:06:31 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id u25so224722812qki.2 for ; Tue, 27 Dec 2016 19:06:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sSuYdbtnKWCFNYLNyOd9Rx+SwaSyL2N5cRvDXZhNN1Y=; b=Ea4ue3xpEhCFBk2V5MIB5/lo3/Aq+hyIPp2iDl8EqsiX3yFG+CbBobfF9HkKRnhUJu BQhnvw2XTXxqY847PSpXOFYIVoHhUKdAiyamVG5zMz0iBnRDx1F1uO5W3Q5uWRCDFe/7 tsYjTd65HJcmQPRjH6icR2jD0lc3rRfh11FuU= 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=sSuYdbtnKWCFNYLNyOd9Rx+SwaSyL2N5cRvDXZhNN1Y=; b=Dsxiz7dXYy7PrGJCsrXPem/nBYMVpBUmTJA6HZqT2rtYrCMS6KQgIS54T4DHhWhcfX RRPmdpnly+zvR090U2sCJQkLqg09DufO4uEMHY4Iub91tBZOmpsVULg2JQdcYak4eMVk x/ZUafaDD6dC0W1Jr09oNrRdNqYRGdtpBpy3kDc2LO9gGvZaJce3lgRO2jFC6fHPxnMx HcRjbYVGtzVJHkxt8lCBKkzrJNNBIapvY2LEEXIODHBdNyRYy2RH0aExr+oyB6F77P5C eXR05hQxxFYn8bNAdHvRGdPSdCupqoonXWw01SF0TybSCXny5JvB2xECy2pOjStX8BJd 5b5A== X-Gm-Message-State: AIkVDXJzejJsO9JxUQiDb6xxO64f1Qh9VByrupRIrVW1QKGdLguv7qCLw1l9APFe8Q52tY/mnokIUKtJyXcxb0GU X-Received: by 10.55.43.149 with SMTP id r21mr36392146qkr.123.1482894390950; Tue, 27 Dec 2016 19:06:30 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Wed, 28 Dec 2016 03:06:20 +0000 Message-ID: To: Joseph Birr-Pixton , tls@ietf.org Content-Type: multipart/alternative; boundary=001a1146d14669ca1e0544af41aa Archived-At: Subject: Re: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 03:06:34 -0000 --001a1146d14669ca1e0544af41aa Content-Type: text/plain; charset=UTF-8 On Tue, Dec 27, 2016 at 4:44 PM Joseph Birr-Pixton wrote: Hi folks, It appears to me that HRR is a pretty large and tricky source of complexity in TLS1.3. Judging by the implementations page, 40% don't support it right now. It's *precisely the kind of thing* that vendors could easily ship broken/missing support for, and they'd get away with it for years until it causes a interop problem. This is indeed a problem. HRR costs an RTT, so enforcing server support is tricky. Realistically, removing groups from the initial ClientHello will probably be impossible, which makes the proposed P-256 mandate especially unappealing. (We hope to try some ideas in Chrome here, but they'll be more complex than GREASE. My current thought is to send the occasional empty key shares ClientHello, either as a parallel probe or just with low probability. Then, once we have any evidence that a server can't HRR, sticky this and refuse to offer it initial key shares until it demonstrates HRR support.) The only case where it is used is (4.1.1): If there is overlap in the "supported_groups" extension but the client did not offer a compatible "key_share" extension, then the server will respond with a HelloRetryRequest We could entirely remove HRR if we slightly strengthen the MTI language covering kx groups: - Clients must not only "implement", but actually offer a key share for NISTP-256 for every ClientHello. Chrome/BoringSSL does not offer P-256 in the initial ClientHello, only X25519. Early in development, we offered P-256 too but intentionally trimmed it to X25519. I do not think this is a good reason to reverse that. On low-end devices, the CPU cost of ECDH starts showing up. X25519 admits simpler and faster implementations than P-256. It wouldn't be okay to waste cycles on a P-256 key share that hopefully tomorrow's TLS 1.3 servers will just ignore anyway. (And today's servers, though predominantly P-256, will also ignore it because they're TLS 1.2.) You are right that one can amortize the cost, but this adds a pile of complexity (make sure to never offer the same key share twice in parallel, cached key shares need lifetimes, limits on cache size, etc). It may end up worthwhile for other reasons, but not just so servers can cut corners to use an unfavored group. TLS 1.3 requires selecting favored group(s), with all the unfortunate results that has. Let's at least get what good effects we can and encourage the current best practice while we have no legacy baggage preventing it. David Note: Obviously, this doesn't apply to PSK-only connections where psk_key_exchange_modes was provided and did not contain psk_dhe_ke. This need not have any additional computational overhead, because the client can amortise the key generation over all handshakes where the server does not select P-256 (hopefully most of them!). In any case, it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the wire, but only if the client wasn't going to send a NISTP-256 share otherwise. Did I miss something? Are there any other uses of HRR in TLS1.3 which means we can't get rid of it in this way? Cheers, Joe _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --001a1146d14669ca1e0544af41aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Dec 27, 2016 at 4:44 PM Joseph Birr-Pixton <jpixt= on@gmail.com> wrote:
Hi folks,

It appears to me that HRR is a pretty large and tricky source of
complexity in TLS1.3. Judging by the implementations page, 40% don't support it right now. It's *precisely the kind of thing* that vendors could easily ship broken/missing support for, and they'd get away with<= br class=3D"gmail_msg"> it for years until it causes a interop problem.

This is= indeed a problem. HRR costs an RTT, so enforcing server support is tricky.= =C2=A0Realistically, removing groups from= the initial ClientHello will probably be impossible, which makes the propo= sed P-256 mandate especially unappealing.
(We hope to try some id= eas in Chrome here, but they'll be more complex than GREASE. My current= thought is to send the occasional empty key shares ClientHello, either as = a parallel probe or just with low probability. Then, once we have any evide= nce that a server can't HRR, sticky this and refuse to offer it initial= key shares until it demonstrates HRR support.)
=C2=A0
The only case where it is used is (4.1.1):

=C2=A0 If there is overlap in the "supported_groups" extension bu= t the client
=C2=A0 did not offer a compatible "key_share" extension, then the= server will
=C2=A0 respond with a HelloRetryRequest

We could entirely remove HRR if we slightly strengthen the MTI
language covering kx groups:

- Clients must not only "implement", but actually offer a key sha= re
for NISTP-256 for every ClientHello.

Chrome/BoringSSL does not offer P-256 in the initial ClientHello, on= ly X25519. Early in development, we offered P-256 too but intentionally tri= mmed it to X25519. I do not think this is a good reason to reverse that.

On low-end devices, the CPU cost of ECDH starts showing up. X25519 = admits simpler and faster implementations than P-256. It wouldn't be ok= ay to waste cycles on a P-256 key share that hopefully tomorrow's TLS 1= .3 servers will just ignore anyway. (And today's servers, though predom= inantly P-256, will also ignore it because they're TLS 1.2.)

= You are right that one can amortize the cost, but this adds a pile of compl= exity (make sure to never offer the same key share twice in parallel, cache= d key shares need lifetimes, limits on cache size, etc). It may end up wort= hwhile for other reasons, but not just so servers can cut corners to use an= unfavored group.

TLS 1.3 requires selecting favored group(s), wi= th all the unfortunate results that has. Let's at least get what good e= ffects we can and encourage the current best practice while we have no lega= cy baggage preventing it.

David=
=C2=A0
Note: Obviously, this doesn't apply to PSK-only connections where
psk_key_exchange_modes was provided and did not contain psk_dhe_ke.

This need not have any additional computational overhead, because the
client can amortise the key generation over all handshakes where the
server does not select P-256 (hopefully most of them!). In any case,
it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the wire, but only if the client wasn't going to send a NISTP-256 share
otherwise.

Did I miss something? Are there any other uses of HRR in TLS1.3 which
means we can't get rid of it in this way?

Cheers,
Joe

_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a1146d14669ca1e0544af41aa-- From nobody Tue Dec 27 19:08:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1248312944F for ; Tue, 27 Dec 2016 19:08: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 xnakXKWzyClJ for ; Tue, 27 Dec 2016 19:08:18 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::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 D8F9B1293F0 for ; Tue, 27 Dec 2016 19:08:17 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id o141so160374441itc.0 for ; Tue, 27 Dec 2016 19:08:17 -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=J00z48t1nUbooPNiYpEiUmhAb+5DzOdsoO9oCDSZONM=; b=JMk7vqJVQH6g4dlsjeDBO+Ww52n3RyYeAzkle7ltE+3P36PCmgAwiMSs8omUwJpXW7 gzbALpuFlJykpS5YjTnUqq6QOu+o0gUNl1KY41imyKx7imvT5lwbBbrbUvJBDUanw0Q8 6oWYfaF1uxB6j2swY7zZ5BbJY1Yc+85C6aSEq2DKj9KKcJGY6y8xbSAULLN+MYlTqYmy 0yp2OOC5Acdda6lL8GTEqBPs+i61k0RkX5jCkoZQrtea4siZykGmR/lGBiPxCNBc9KEH KjrV8dObudcbeJdksVS7alPgJq2snzf+FzYwn+AQL6mGGWj7/HHRh35wjB2SA2mtOeTC 7bdA== 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=J00z48t1nUbooPNiYpEiUmhAb+5DzOdsoO9oCDSZONM=; b=q8zhFgDvUXdLq1xYfTvMZwCPv6+SxHTMzokaaQtJUNjak13U8v/kPmCecjzB1aXHlp GVrCNBdoJq9NI1UhzoM9o4sswt798OeFJDsAUiIvWyJvL0Qc6LFZKS9ODZvKdiHCBI5s dB1Js4OAEyT/mb6t6ma+7BQ+QlYIm435MOYI93CTt9eQh0n4hHH6ZyAN8GRS11Zwo66s +ViiJgFXS9bmS2dtm3gYKByBM2dQMEev6IQqW3rzREVog5SC1ZhrrnVb3KNx036AvJeS eYYbb1FsjLgwSg2RsC9bn3CKUcVYSgKUIYuesKyuesXGhsqGT3al+6uRzUOJZ7fQy5hF TWQQ== X-Gm-Message-State: AIkVDXL9i9TH0nyw1ibWN75naOIjtiVF9mXHqMPyNzXzaFr/X1as0z6hAhZ2NAjHgp5mwQ== X-Received: by 10.36.96.70 with SMTP id i67mr23254151itc.59.1482894496954; Tue, 27 Dec 2016 19:08:16 -0800 (PST) Received: from ?IPv6:2607:fb90:29e:83f:3c78:3ce2:271d:bd62? ([2607:fb90:29e:83f:3c78:3ce2:271d:bd62]) by smtp.gmail.com with ESMTPSA id 130sm21528835ity.5.2016.12.27.19.08.15 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Dec 2016 19:08:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: david wong X-Mailer: iPhone Mail (14C92) In-Reply-To: Date: Tue, 27 Dec 2016 21:08:14 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <52A54FFA-1227-4A69-A4A4-FDC27B9E58AD@gmail.com> References: To: Eric Rescorla Archived-At: Cc: "tls@ietf.org" , Joseph Birr-Pixton Subject: Re: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 03:08:19 -0000 HRR is a pretty simple message to implemement. Including it into a ServerHel= lo would complexify the protocol without much gain imo.=20 I also think that forcing a client to use one of the curve is not a good ide= a either. Who is going to agree on what curve it should be here :) ?=20 Probably browsers and server implementations will end up agreeing on the sam= e set anyway. And client/server controlled infrastructures can enforce that t= o avoid using HRR as well.=20 David= From nobody Tue Dec 27 20:06:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41F311294DC for ; Tue, 27 Dec 2016 20:06:02 -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] 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 gqhXl7sONUcd for ; Tue, 27 Dec 2016 20:06:00 -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 5D4451294A2 for ; Tue, 27 Dec 2016 20:06:00 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id a10so180751635ywa.3 for ; Tue, 27 Dec 2016 20:06: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=I48FkjC/fr8aq1ArGeoNm6DtHPSXZ4mzc93bG0ENfGk=; b=ADWQ4TdY3zDboTBXJ20K+aB7Xrcae7clQKn8hj+/f/ybH8UM0pYaWEC+QrfRUNxJh3 gkWmZr26euwhtVUvNpHtVWIlr1cdiuPJ4NUyKAf49OAwVNdfxdMAxbOW6zmZbStLWiO5 /BYwYRofMHd6Y6sI6iWznQMiE5u97wkzv5twtjhbrGRnkecoaySqfa+EETWRaNbCWvIO xI/DOH2Miwey37O0mDJfbHFxp+VsO0Qu5OuBtP6oaIYCd2Z9Gd5JTa+T2kzemF4zkOZl Fv/B2zVjQvtH1A+WL2C6kcy+73x3VwH29w21lUHRZPNwbQjUuNYjDcpRdH/NHFtJHvTR h1+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I48FkjC/fr8aq1ArGeoNm6DtHPSXZ4mzc93bG0ENfGk=; b=rl360eAgE1F5cpTsGEzWkMY8FGRafmowwUHhpSsv2pYSEkyZzCEiUYX+0DXSobjgac m5N502gDxAN0g3JXP/wVt/39mDdfftO/qcqksbPAuFUG5yK1wRxB8q0yeHv2ws3Adahz Ycf9wpAyjo98B07j9khwfjTRhAlOF5kmuOKIXezeSyiFPlkcJTVRGLjVQ55oXtLyQuOi RobRTvSZ6cg9qizw84lcGXUS+Tn1yDV9YIqMIj1Pqs+0tmuYaZYl4tFCVe01ptv2LDVz TD6/Ah0+SI77Le8cMvRa37WocHdoJgYw5bVpP9RmkieCn5LwEUNTPq3Nf/FOKCI/EGcC hWSg== X-Gm-Message-State: AIkVDXJW0USEPmaMUjR2BkiGFsQa8C/3ehqdEo0HikDhKU/2WsDAlEwt4t2s9n1ZVMxyt1QAA2AP3BWCnBckiA== X-Received: by 10.129.40.141 with SMTP id o135mr20838921ywo.149.1482897959550; Tue, 27 Dec 2016 20:05:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Tue, 27 Dec 2016 20:05:19 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 27 Dec 2016 20:05:19 -0800 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a114087a81e2c990544b016c8 Archived-At: Cc: "tls@ietf.org" , Joseph Birr-Pixton Subject: Re: [TLS] MTI kx groups, HelloRetryRequest and "Incorrect DHE Share" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 04:06:02 -0000 --001a114087a81e2c990544b016c8 Content-Type: text/plain; charset=UTF-8 On Tue, Dec 27, 2016 at 7:06 PM, David Benjamin wrote: > On Tue, Dec 27, 2016 at 4:44 PM Joseph Birr-Pixton > wrote: > > Hi folks, > > It appears to me that HRR is a pretty large and tricky source of > complexity in TLS1.3. Judging by the implementations page, 40% don't > support it right now. It's *precisely the kind of thing* that vendors > could easily ship broken/missing support for, and they'd get away with > it for years until it causes a interop problem. > > > This is indeed a problem. HRR costs an RTT, so enforcing server support is > tricky. Realistically, removing groups from the initial ClientHello will > probably be impossible, which makes the proposed P-256 mandate especially > unappealing. > > (We hope to try some ideas in Chrome here, but they'll be more complex > than GREASE. My current thought is to send the occasional empty key shares > ClientHello, either as a parallel probe or just with low probability. Then, > once we have any evidence that a server can't HRR, sticky this and refuse > to offer it initial key shares until it demonstrates HRR support.) > > > The only case where it is used is (4.1.1): > > If there is overlap in the "supported_groups" extension but the client > did not offer a compatible "key_share" extension, then the server will > respond with a HelloRetryRequest > > We could entirely remove HRR if we slightly strengthen the MTI > language covering kx groups: > > - Clients must not only "implement", but actually offer a key share > for NISTP-256 for every ClientHello. > > > Chrome/BoringSSL does not offer P-256 in the initial ClientHello, only > X25519. Early in development, we offered P-256 too but intentionally > trimmed it to X25519. I do not think this is a good reason to reverse that. > > On low-end devices, the CPU cost of ECDH starts showing up. X25519 admits > simpler and faster implementations than P-256. It wouldn't be okay to waste > cycles on a P-256 key share that hopefully tomorrow's TLS 1.3 servers will > just ignore anyway. (And today's servers, though predominantly P-256, will > also ignore it because they're TLS 1.2.) > > You are right that one can amortize the cost, but this adds a pile of > complexity (make sure to never offer the same key share twice in parallel, > cached key shares need lifetimes, limits on cache size, etc). It may end up > worthwhile for other reasons, but not just so servers can cut corners to > use an unfavored group. > It also creates a potential supercookie in the clear part of the handshake which is obviously problematic, and becomes more problematic the more biased the ecosystem is. E.g., if you always offer P256 + X25519 but practically everyone chooses X25519, then you could be offering the P256 share for a very long time before someone picks it up. And of course if you do the straightforward thing and amortize both shares then you have the pattern: ClientHello Server Picks P1 X1 X P1 X2 X P1 X3 P P2 X3 X P2 X4 X This makes it easy to bridge across share selections. -Ekr > > TLS 1.3 requires selecting favored group(s), with all the unfortunate > results that has. Let's at least get what good effects we can and encourage > the current best practice while we have no legacy baggage preventing it. > > David > > > Note: Obviously, this doesn't apply to PSK-only connections where > psk_key_exchange_modes was provided and did not contain psk_dhe_ke. > > This need not have any additional computational overhead, because the > client can amortise the key generation over all handshakes where the > server does not select P-256 (hopefully most of them!). In any case, > it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the > wire, but only if the client wasn't going to send a NISTP-256 share > otherwise. > > Did I miss something? Are there any other uses of HRR in TLS1.3 which > means we can't get rid of it in this way? > > Cheers, > Joe > > _______________________________________________ > 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 > > --001a114087a81e2c990544b016c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Dec 27, 2016 at 7:06 PM, David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
On Tue, Dec 27, 2016 at 4:44 PM Joseph Bir= r-Pixton <jpixton@gmail.com> wrote:
Hi folks,

It appears to me that HRR is a pretty large and tricky source of
complexity in TLS1.3. Judging by the implementations page, 40% don't support it right now. It's *precisely the kind of thing* that vendors could easily ship broken/missing support for, and they'd get away with<= br class=3D"m_-7453984545143680779gmail_msg"> it for years until it causes a interop problem.

This is indeed a problem. HRR costs an RTT, so enforcing server support= is tricky.=C2=A0Realistically, removing groups from the initial ClientH= ello will probably be impossible, which makes the proposed P-256 mandate es= pecially unappealing.
<= br class=3D"m_-7453984545143680779gmail_msg">
(We hope to try some ideas in Chrome here, but they&= #39;ll be more complex than GREASE. My current thought is to send the occas= ional empty key shares ClientHello, either as a parallel probe or just with= low probability. Then, once we have any evidence that a server can't H= RR, sticky this and refuse to offer it initial key shares until it demonstr= ates HRR support.)
=C2=A0
The only case where it is used is (4.1.1):

=C2=A0 If there is overlap in the "supported_groups" extension bu= t the client
=C2=A0 did not offer a compatible "key_share" extension, then the= server will
=C2=A0 respond with a HelloRetryRequest

We could entirely remove HRR if we slightly strengthen the MTI
language covering kx groups:

- Clients must not only "implement", but actually offer a key sha= re
for NISTP-256 for every ClientHello.

Chrome/BoringSSL does not offer P-2= 56 in the initial ClientHello, only X25519. Early in development, we offere= d P-256 too but intentionally trimmed it to X25519. I do not think this is = a good reason to reverse that.

On low-end devices, the CPU cost of ECDH st= arts showing up. X25519 admits simpler and faster implementations than P-25= 6. It wouldn't be okay to waste cycles on a P-256 key share that hopefu= lly tomorrow's TLS 1.3 servers will just ignore anyway. (And today'= s servers, though predominantly P-256, will also ignore it because they'= ;re TLS 1.2.)

You are right that one can amortize the cost, but this adds = a pile of complexity (make sure to never offer the same key share twice in = parallel, cached key shares need lifetimes, limits on cache size, etc). It = may end up worthwhile for other reasons, but not just so servers can cut co= rners to use an unfavored group.

It also creates a potential supercookie in the cl= ear part of the handshake which is obviously problematic, and becomes more = problematic the more biased the ecosystem is. E.g., if you always offer P25= 6 + X25519 but practically everyone chooses X25519, then you could be offer= ing the P256 share for a very long time before someone picks it up. And of = course if you do the straightforward thing and amortize both shares then yo= u have the pattern:

ClientHello =C2=A0 =C2=A0Serve= r Picks
P1 X1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0X
P1 X2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0X
P1 X3 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0P
P2 X3 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0X
P2 X4 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0X

This makes it easy to bridge across share = selections.

-Ekr

=C2=A0

TLS 1.3 requires selecting = favored group(s), with all the unfortunate results that has. Let's at l= east get what good effects we can and encourage the current best practice w= hile we have no legacy baggage preventing it.

D= avid
=C2=A0<= /div>
Note: Obviously, this doesn't apply to PSK-only connections where
psk_key_exchange_modes was provided and did not contain psk_dhe_ke.

This need not have any additional computational overhead, because the
client can amortise the key generation over all handshakes where the
server does not select P-256 (hopefully most of them!). In any case,
it's one fixed-base pointmul. It obviously costs 64 bytes-odd on the wire, but only if the client wasn't going to send a NISTP-256 share
otherwise.

Did I miss something? Are there any other uses of HRR in TLS1.3 which
means we can't get rid of it in this way?

Cheers,
Joe

_______________________________________________
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


--001a114087a81e2c990544b016c8-- From nobody Wed Dec 28 05:11:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A904129467 for ; Wed, 28 Dec 2016 05:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZyerOpw068r for ; Wed, 28 Dec 2016 05:11:40 -0800 (PST) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 850E4129488 for ; Wed, 28 Dec 2016 05:11:40 -0800 (PST) Received: from vsmta13.fe.internet.bosch.com (unknown [10.4.98.53]) by imta24.fe.bosch.de (Postfix) with ESMTP id 2A24CD8019D for ; Wed, 28 Dec 2016 14:11:38 +0100 (CET) Received: from FE-MBX1027.de.bosch.com (vsgw24.fe.internet.bosch.com [10.4.98.24]) by vsmta13.fe.internet.bosch.com (Postfix) with ESMTP id 0919A2E403AE for ; Wed, 28 Dec 2016 14:11:38 +0100 (CET) Received: from SI-MBX1028.de.bosch.com (10.3.230.42) by FE-MBX1027.de.bosch.com (10.3.230.85) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 28 Dec 2016 14:11:37 +0100 Received: from SI-MBX1028.de.bosch.com ([fe80::c1ec:d83c:fc40:7182]) by SI-MBX1028.de.bosch.com ([fe80::c1ec:d83c:fc40:7182%20]) with mapi id 15.00.1236.000; Wed, 28 Dec 2016 14:11:37 +0100 From: "Guballa Jens (ETAS-PSC/ECS)" To: "TLS@ietf.org" Thread-Topic: PR#837: Forward and backward secrecy Thread-Index: AdJhCeoibfvJgyGQRVaNYfkZRapNKA== Date: Wed, 28 Dec 2016 13:11:36 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.51.202.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22788.006 X-TMASE-MatchedRID: wDTc/wNgEcN4r+bAj/vLecqXjImgj58bXjZP2MOsiT1o5YsPsbyLXYHR joOa89CHehRgIaRxa9/QTW6Kk5j1wzCg8XyTOA8XylAqNTt8FdWP/EshoNKyETAVXG2j6YswA5H e1kDS+OLi8zVgXoAltlSqyRM1YGuh0C1sQRfQzEHEQdG7H66TyHEqm8QYBtMOnPPlp+eUHlFMs4 YCheI5YvlFZdlqailzIyUrcZWcJI2NQlEXxIqsXKGAk8n8c8WNg3SjZDSMJb/IpgnS5LP7/nIdK +rUZ/963paAu7ISFV4OlqViiktq0WMmoo1qIDv9Ugf6wsm4ylk= Archived-At: Subject: [TLS] PR#837: Forward and backward secrecy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 13:11:43 -0000 Hi, I just created a new pull request (and I just recognized it results in a me= rge conflict): https://github.com/tlswg/tls13-spec/pull/837 I think in section "E.2 Record Layer" the terms "forward secrecy" and "back= ward secrecy" have been mixed up. My understanding:=20 A compromised long term key does not compromise captured future traffic =3D= > forward secrecy (provided by (EC)DHE) A compromised long term key does not compromise captured traffic from the p= ast =3D> backward secrecy (provided by HKDF-hash) Thanks, Jens From nobody Wed Dec 28 07:50:57 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F8E129616 for ; Wed, 28 Dec 2016 07:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynxlDJYuLMet for ; Wed, 28 Dec 2016 07:50:54 -0800 (PST) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA7C129408 for ; Wed, 28 Dec 2016 07:50:54 -0800 (PST) Received: from vsmta13.fe.internet.bosch.com (unknown [10.4.98.53]) by imta24.fe.bosch.de (Postfix) with ESMTP id 6A89BD801DB for ; Wed, 28 Dec 2016 16:50:52 +0100 (CET) Received: from FE-MBX1028.de.bosch.com (vsgw24.fe.internet.bosch.com [10.4.98.24]) by vsmta13.fe.internet.bosch.com (Postfix) with ESMTP id 4C7C42E4062F for ; Wed, 28 Dec 2016 16:50:52 +0100 (CET) Received: from SI-MBX1028.de.bosch.com (10.3.230.42) by FE-MBX1028.de.bosch.com (10.3.230.86) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 28 Dec 2016 16:50:51 +0100 Received: from SI-MBX1028.de.bosch.com ([fe80::c1ec:d83c:fc40:7182]) by SI-MBX1028.de.bosch.com ([fe80::c1ec:d83c:fc40:7182%20]) with mapi id 15.00.1236.000; Wed, 28 Dec 2016 16:50:51 +0100 From: "Guballa Jens (ETAS-PSC/ECS)" To: "TLS@ietf.org" Thread-Topic: PR#838: Clients must verify the signature of CertificateVerify Thread-Index: AdJhIe8kL7ln1hp9T+S5OaedOhgsqQ== Date: Wed, 28 Dec 2016 15:50:51 +0000 Message-ID: <598f6b1090f64ac8a6da44bc56f27af2@SI-MBX1028.de.bosch.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.51.202.94] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22788.006 X-TMASE-MatchedRID: mxldsKGO8q2W+cf6nEkoSp1U1lojafr/RWISSV5hxi/OxDyJFXIPjj47 VHZHqWPK+0u/DVAr+l9hrQJTSgXK3EIFCJ5KkAbPngIgpj8eDcDYr6U3ZlQkdtmzcdRxL+xwKra uXd3MZDXZdHL+wYnPi5kHJNdT6x2ZHgwKNM65nO6pyXs3WGzFI8ZVedYOKn8V7KHHdo4rKTh76y KofH98XyBu++nwIIV+G2gHi7HK+HginF4k4qfRx9vQudwJa1UEbiWMdLprM/mbjP55bWdtQcixC jPGQhvOQwymtxuJ6y0= Archived-At: Subject: [TLS] PR#838: Clients must verify the signature of CertificateVerify X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 15:50:56 -0000 Hi, here is another PR: https://github.com/tlswg/tls13-spec/pull/838 The client should be required to verify the CertificateVerify message. In a= ddition I prefer to specify the alert type in case the verification fails (= also for the Finished). Thanks, Jens From nobody Wed Dec 28 10:54:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C500A12943C for ; Wed, 28 Dec 2016 10:54:20 -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 oDmCUoLVJf-6 for ; Wed, 28 Dec 2016 10:54:19 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 978671293E8 for ; Wed, 28 Dec 2016 10:54:19 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 91DA5282FAF; Wed, 28 Dec 2016 18:54:17 +0000 (UTC) Date: Wed, 28 Dec 2016 18:54:17 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20161228185417.GV13486@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.2 (2016-11-26) Archived-At: Subject: Re: [TLS] PR#837: Forward and backward secrecy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 18:54:21 -0000 On Wed, Dec 28, 2016 at 01:11:36PM +0000, Guballa Jens (ETAS-PSC/ECS) wrote: > My understanding: > A compromised long term key does not compromise captured future traffic => forward secrecy (provided by (EC)DHE) This is not correct. Forward-secrecy is the below, not the above. > A compromised long term key does not compromise captured traffic from the past => backward secrecy (provided by HKDF-hash) -- Viktor. From nobody Wed Dec 28 15:12:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC81129554 for ; Wed, 28 Dec 2016 15:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwCYqeKwgiYd for ; Wed, 28 Dec 2016 15:12:56 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF49127058 for ; Wed, 28 Dec 2016 15:12:56 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id c47so361026423qtc.2 for ; Wed, 28 Dec 2016 15:12:56 -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=1gD+aQQgAEPuMziNCrXw51GGosd9SVbWQA49csVjLUI=; b=T95iplyVgiuRxjtYmUVkbpGgTYELa9JXFulgmj7lraIU9d1UY2Yb2dIOnh94EbAl1g MToc6/oqloPsNfgp1u/LdoNEtSNpS0UMZrl3JXIBlYb8NnyPjwhlQImy2a1HWekE4u+2 IbBrPaen3UOooSJtM2tsAM9Hzdz1K2ustW4/vdlCO/aVPlQsQYC3FIKX0p1xPRd+J3iq BfoRKo0rhJP3ZB2jjFzBV7vpwrmQGrNW57W0jm5LB2SCtukFL8jv0FyWp3ZtQqNm7+hh MxP6QRIA8iE6PR+BGxgrJPNQK2I3XvPuM6HWMSkoTdRvE8afvcHNRZvwFBCCUrY1bYbX czrg== 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=1gD+aQQgAEPuMziNCrXw51GGosd9SVbWQA49csVjLUI=; b=UD9Ih+spUSw2YQbuH+McIwTNfyRPq4dr3spOefbzrTvFMAwkRXEC2DZMC/mU4Mk2iP CK+TlLw+MDXac6au2EymMt2Wu0xkR6jYrzb6jrwfu1W1OIg3wX2Nsnfy3jOSwrFROpEY lhRKnuZpiQxKQISbkY9jdaq251JGqZLkMNXh6hNEHimhUXgCsXAtzqS9ARFnd+cFFHjU Vr0txXHmVXYAw+08/1JE3YTMT/x9kx8insO18PkmuqWB2YSAySaV+NFNO6czY+NWKKsM r2YWKgHkz+UjjAMvIlRDe+2wU9fYhMErbayeqwswheGhmKZlS1YCrAW04KHyZihOb+tJ nK7g== X-Gm-Message-State: AIkVDXLkcIVK+/0XVQ7C1TQ7mXSznT+eRpk9BR0l18KYrCSnDobj1cXZ0WpsyaSCXgIwmIw2yG7lmp6gnPE0MQ== X-Received: by 10.200.48.28 with SMTP id f28mr40278342qte.247.1482966775334; Wed, 28 Dec 2016 15:12:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Wed, 28 Dec 2016 15:12:54 -0800 (PST) In-Reply-To: <598f6b1090f64ac8a6da44bc56f27af2@SI-MBX1028.de.bosch.com> References: <598f6b1090f64ac8a6da44bc56f27af2@SI-MBX1028.de.bosch.com> From: Martin Thomson Date: Thu, 29 Dec 2016 10:12:54 +1100 Message-ID: To: "Guballa Jens (ETAS-PSC/ECS)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "TLS@ietf.org" Subject: Re: [TLS] PR#838: Clients must verify the signature of CertificateVerify X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2016 23:12:57 -0000 There are a lot of rebase artifacts here, but it looks good. The PR does beg the question though: how does one verify the signature and with what key? On 29 December 2016 at 02:50, Guballa Jens (ETAS-PSC/ECS) wrote: > Hi, > > here is another PR: https://github.com/tlswg/tls13-spec/pull/838 > > The client should be required to verify the CertificateVerify message. In addition I prefer to specify the alert type in case the verification fails (also for the Finished). > > Thanks, > Jens > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Dec 29 01:53:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766A51295AE for ; Thu, 29 Dec 2016 01:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN9-P1b5w-aE for ; Thu, 29 Dec 2016 01:53:52 -0800 (PST) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8551D129426 for ; Thu, 29 Dec 2016 01:53:51 -0800 (PST) Received: from vsmta12.fe.internet.bosch.com (unknown [10.4.98.52]) by imta23.fe.bosch.de (Postfix) with ESMTP id 460D21580169 for ; Thu, 29 Dec 2016 10:53:48 +0100 (CET) Received: from FE-MBX1028.de.bosch.com (vsgw24.fe.internet.bosch.com [10.4.98.24]) by vsmta12.fe.internet.bosch.com (Postfix) with ESMTP id 25BAA1B8041B for ; Thu, 29 Dec 2016 10:53:48 +0100 (CET) Received: from SI-MBX1028.de.bosch.com (10.3.230.42) by FE-MBX1028.de.bosch.com (10.3.230.86) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 29 Dec 2016 10:53:47 +0100 Received: from SI-MBX1028.de.bosch.com ([fe80::c1ec:d83c:fc40:7182]) by SI-MBX1028.de.bosch.com ([fe80::c1ec:d83c:fc40:7182%20]) with mapi id 15.00.1236.000; Thu, 29 Dec 2016 10:53:47 +0100 From: "Guballa Jens (ETAS-PSC/ECS)" To: "tls@ietf.org" Thread-Topic: [TLS] PR#837: Forward and backward secrecy Thread-Index: AdJhCeoibfvJgyGQRVaNYfkZRapNKAAKX5GAAB61O2A= Date: Thu, 29 Dec 2016 09:53:47 +0000 Message-ID: <7552d0dd141f423591e50398d29e41ae@SI-MBX1028.de.bosch.com> References: <20161228185417.GV13486@mournblade.imrryr.org> In-Reply-To: <20161228185417.GV13486@mournblade.imrryr.org> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.51.202.94] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004C_01D261C1.D3D7E6D0" MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22788.006 X-TMASE-MatchedRID: X+5mRT+D0xsol39hmeEcd/p1plqEbuqxQY6asswqRNstxWNuz6R5rJPG lAhwdrelLNiBsAzWU1gOFzppsEIdiLE2JkUZcFMKbMGKOuLn5FXUVtZ/Qi4vt6+WgCcaviqGLb7 cluQHYe3Ewh+FBAsuQbEEZIBH5eb/npTuOg/W2Y4D2WXLXdz+AZfRrj+dnBcslNU3cWIuTKjsVk d/wLkXBrWhcxSN1KkV6pbNFWS8cDt1L4O6ei8PH6m4PbloS2C3+KgiyLtJrSCyd65qZFFPkzpbf dTAcNXmrdZLelE6wFtcLc3sLtjOt1jtFRRrj2eO5tHwb6x0QAhuRXh7bFKB7glOr4P1gkO9VOGc leSFW91y2O4yqxgUjRJb/sfHPbRBvuvB6gAgryg= Archived-At: Subject: Re: [TLS] PR#837: Forward and backward secrecy X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 09:53:54 -0000 ------=_NextPart_000_004C_01D261C1.D3D7E6D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit > > > My understanding: > > A compromised long term key does not compromise captured future traffic > => forward secrecy (provided by (EC)DHE) > > This is not correct. Forward-secrecy is the below, not the above. [JG] I did not say clearly what I meant. :-) For my statement I set the presence implicitly to the end of the handshake, sorry for the confusion. Anyway, in principle I am in line with the definition of "Forward secret" in section E.1, but still I have two comments: 1. "Forward secret If the long-term keying material (in this case the signature keys in certificate-based authentication modes or the external/resumption PSK in PSK with (EC)DHE modes) are compromised after the handshake is complete, this does not compromise the security of the session key (See [DOW92]).[...]" - I think that "session key" is a synonym for "master secret". - My understanding: The master secret is a short-term secret, I think an implementation can delete it after the working keys have been derived, right? If these assumptions are correct, then I prefer something like "..., this does not compromise the security of the master secret (see [DOW92]) and the derived working keys." 2. If the term "backward secrecy" will remain in the draft, then I propose to either add a definition or refer to a definition of this term outside of the draft. > > > A compromised long term key does not compromise captured traffic from > the past => backward secrecy (provided by HKDF-hash) > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_004C_01D261C1.D3D7E6D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIXKzCCBLcw ggOfoAMCAQICBEMB0LowDQYJKoZIhvcNAQELBQAwUDETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFDASBgNVBAMTC0Jvc2NoLUNBLURFMB4X DTE1MDUxMjA5NDgxMFoXDTI1MDUxMjEwMTgxMFowUTETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKAkjDSX1bM0BhiJa3jlD/DiW+shP849/Bty QKlL7o+Lfdp1GZrW5cHdlg6ks4X8gd3zlpYC+JeWd1clUf2BBHlJKyOHR2caOMnSsNsbDYQ984O8 4dnWS8ex2Jiw+j+wNTtCgL3OhuGTxMIWlWfOhtlzMvz3dqqtMpaYnqzoYb/t+Uzzjg8W0/KdCM60 7M6ic2jpghz1sr5j9N5qYF/ETQWQnNoPdAzohs0bk2W02wVyayVjSVDVK6cPAnBnVzaFv+1NV5ms 53MlmQkgSg7SkRs1xwKsg5MSOsDDL+dn9bi9UU1aYNXFTefUEcHUTsjpk7REV+NQo72O97JfUKOK t18CAwEAAaOCAZYwggGSMIIBGAYDVR0fBIIBDzCCAQswZ6BloGOkYTBfMRMwEQYKCZImiZPyLGQB GRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEUMBIGA1UEAxMLQm9z Y2gtQ0EtREUxDTALBgNVBAMTBENSTDEwgZ+ggZyggZmGVWxkYXA6Ly9ib3NjaC5jb20vY249Qm9z Y2gtQ0EtREUsY249UEtJLGRjPUJvc2NoLGRjPWNvbT9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0 P2Jhc2WGQGh0dHA6Ly90cnVzdGNlbnRlci5ib3NjaC5jb20vQ1JML2Jvc2NoLWNhLWRlX3BraV9j b21fY3JsZmlsZS5jcmwwCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFB6lPyKiCCEbxVgo0R8t8PP4 +RUpMB0GA1UdDgQWBBTeBOLMiQj9dYzYpDAx2BBt5aH0mzAMBgNVHRMEBTADAQH/MBkGCSqGSIb2 fQdBAAQMMAobBFY4LjEDAgCBMA0GCSqGSIb3DQEBCwUAA4IBAQBITOZpOW3DTD72K7WDq5Zh5eHf zeg4FC3xDZ9nj4bs+ObFx+zInsdisYlycj5rlsMjDrS+hNKBCPVsL/JyIgelTb7fHXkl5m2ifsqn wv0YR7Tk509ooHdVXTLmZV4AjyeXUmKXXh+QkK9DiHhU6sLdkPej4gBolemqD0SVrzd7F+ZqHAvg cQtcRMVc+rkADrC2pytD90XpqDl2I5RdnNSfVpo7FsP5zHayNBIBiHBhmVPhgMUCjjxNGuMGTC74 AqqATrAKI3zEADbBoohOlaHmfnurGHHU21IAgXYYz4vngqapYWiTo2dRPuqhaZDNp4tXhBYzqunA YTfXLzo6qbXpMIIE+jCCA+KgAwIBAgIEQwG2sjANBgkqhkiG9w0BAQUFADBQMRMwEQYKCZImiZPy LGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEUMBIGA1UEAxML Qm9zY2gtQ0EtREUwHhcNMDUwODE2MDkxOTQyWhcNMjUwODE2MDk0OTQyWjBQMRMwEQYKCZImiZPy LGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEUMBIGA1UEAxML Qm9zY2gtQ0EtREUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDADDavsLqpxKnP+mAB iNavAOpR8EK4o7E1NxRj//V6gVHdLw9EnRY+CeX6KAf6CjW3X+VRzQMZOMxcj4Hn9T2/hvApgjr4 asLHduTYlNlSPBLH1c0rDBJRj4SllBtkHx4g7eelVWzWT4k2vIgxNtwAR0x+dghgObQBMGnPYGsE RYQ62JU4c3Z3yNVOOCtSh+3J9m+8zMSvPKKpiqK4D5QfhMjJDvOAgJRzkQLnJHTATLhF5Jp0phWU HJGeChwoncbhYX13AnEpqccGrid+ZdKYIFDs/I8t505VTzvQ8O0yMkYc1RLIfXMsDeullW+00lml FylcqXXMStOMhyYii4XXAgMBAAGjggHaMIIB1jARBglghkgBhvhCAQEEBAMCAAcwggEYBgNVHR8E ggEPMIIBCzBnoGWgY6RhMF8xEzARBgoJkiaJk/IsZAEZFgNjb20xFTATBgoJkiaJk/IsZAEZFgVC b3NjaDEMMAoGA1UEAxMDUEtJMRQwEgYDVQQDEwtCb3NjaC1DQS1ERTENMAsGA1UEAxMEQ1JMMTCB n6CBnKCBmYZVbGRhcDovL2Jvc2NoLmNvbS9jbj1Cb3NjaC1DQS1ERSxjbj1QS0ksZGM9Qm9zY2gs ZGM9Y29tP2NlcnRpZmljYXRlUmV2b2NhdGlvbkxpc3Q/YmFzZYZAaHR0cDovL3RydXN0Y2VudGVy LmJvc2NoLmNvbS9DUkwvYm9zY2gtY2EtZGVfcGtpX2NvbV9jcmxmaWxlLmNybDArBgNVHRAEJDAi gA8yMDA1MDgxNjA5MTk0MlqBDzIwMjUwODE2MDk0OTQyWjALBgNVHQ8EBAMCAQYwHwYDVR0jBBgw FoAUHqU/IqIIIRvFWCjRHy3w8/j5FSkwHQYDVR0OBBYEFB6lPyKiCCEbxVgo0R8t8PP4+RUpMAwG A1UdEwQFMAMBAf8wHQYJKoZIhvZ9B0EABBAwDhsIVjcuMTo0LjADAgSQMA0GCSqGSIb3DQEBBQUA A4IBAQBkQ/eOR9L4eenoIddXw7SjnJDnfsgZIaJNsnJ8afxgJjvot/U6AjnmPo7Waa5gyEIS9EEE mAubTwU30NyhHCr8iHjFDWhbSa9Waajb81i6WgklpjM6T1D+RuEO1Ty6sWgPsfx3bZLITQyoXr33 nRokVmKshjwtEU05BKRXgvk7ma9HGCV1lOtwdjHKcK17mE2FHGbFNm/o6P9CkN4P3jdmpWKSb791 5Cz9wdNPOl0IBcSlwH7j3D8YEfbkrDkk2UYPccZUzMkPi6+WhlUmwkc0ea+Fa+pjGBsZ7AEfRCcV Zaz3fjluyBWjuWRa5bY3P86UdjQplcobWrovoIwehkyRMIIGjjCCBXagAwIBAgIEQ2J0ADANBgkq hkiG9w0BAQsFADBRMRMwEQYKCZImiZPyLGQBGRYDY29tMRUwEwYKCZImiZPyLGQBGRYFQm9zY2gx DDAKBgNVBAMTA1BLSTEVMBMGA1UEAxMMQm9zY2gtQ0ExLURFMB4XDTE2MTIxMzEzMTIzNVoXDTE5 MTIxMzEzNDIzNVowgYYxEzARBgoJkiaJk/IsZAEZFgNjb20xFTATBgoJkiaJk/IsZAEZFgVib3Nj aDEMMAoGA1UEAxMDcGtpMQ4wDAYDVQQDEwVCT1NDSDELMAkGA1UEAxMCREUxCjAIBgNVBAMTAUox CjAIBgNVBAMTAUUxFTATBgNVBAMTDEplbnMuR3ViYWxsYTCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAK59uLjqNeweDpPkjdEsVAGfz5PXTtSskmdMlqgkg5otcrYoj+dYCNmBqmisvYri wqY56jf2QBAm8bkjxMQPgox+k4kYA/SsLuQY131ADyzhhvDbX/3PLIeLeE0TIgOMBDcjrJIJxuYc 3efy1u2cnEZyJ+PHBZstVTc+5+K5Ky4Ql7QkoVzJFJgX5zDeAQyotZzZ6s3b+MoXKugPBkK0dsCz amxFynbVYV8RL6GMfNPFqg/Xo2ee75w3w0P3VJ4NWKT1MVJXFY4Zago+8M4uZxUPsuvg+SNVStDO hWCidmY6L7n3lo2W42/LDw0aJ5wVc9x4VFHLqLtlVWjv4E3Kh98CAwEAAaOCAzYwggMyMAsGA1Ud DwQEAwIFIDAeBgNVHSUEFzAVBggrBgEFBQcDBAYJKwYBBAGVEQUBMIIBRgYDVR0gBIIBPTCCATkw ggE1Bg0rBgEEAalGg30BAgEBMIIBIjAsBggrBgEFBQcCARYgaHR0cDovL3RydXN0Y2VudGVyLmJv c2NoLmNvbS9jcHMwgfEGCCsGAQUFBwICMIHkGoHhVGhlIEJvc2NoIENlcnRpZmljYXRpb24gUHJh Y3RpY2UgU3RhdGVtZW50IChDUFMpIGF2YWlsYWJsZSBhdCBodHRwOi8vdHJ1c3RjZW50ZXIuYm9z Y2guY29tL2NwcyBpcyBoZXJlYnkgaW5jb3Jwb3JhdGVkIGludG8geW91ciB1c2Ugb3IgcmVsaWFu Y2Ugb24gdGhpcyBDZXJ0aWZpY2F0ZS4gVGhpcyBDUFMgY29udGFpbnMgbGltaXRhdGlvbnMgb24g d2FycmFudGllcyBhbmQgbGlhYmlsaXRpZXMuMCAGA1UdEQQZMBeBFUplbnMuR3ViYWxsYUBldGFz LmNvbTCCAS8GA1UdHwSCASYwggEiMGugaaBnpGUwYzETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERTEQ MA4GA1UEAxMHQ1JMMjIyMjCBsqCBr6CBrIZmbGRhcDovL2Jvc2NoLmNvbS9jbj1XaW5Db21iaW5l ZDIsY249Qm9zY2gtQ0ExLURFLGNuPVBLSSxkYz1Cb3NjaCxkYz1jb20/Y2VydGlmaWNhdGVSZXZv Y2F0aW9uTGlzdD9iYXNlhkJodHRwOi8vdHJ1c3RjZW50ZXIuYm9zY2guY29tL0NSTC9ib3NjaC1j YTEtZGVfcGtpX2NvbV9jcmxmaWxlMi5jcmwwHwYDVR0jBBgwFoAU3gTizIkI/XWM2KQwMdgQbeWh 9JswHQYDVR0OBBYEFPiN5cC6K62XZu/Zu6CSv7hhpSJAMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EA BAwwChsEVjguMQMCBLAwDQYJKoZIhvcNAQELBQADggEBAHDh6aq0mgFY8lXAJoN2NI18OF5i8CWt gTDqrns6isJxDHaLGjqgeEUcZSmY54f365Ho6io8j+Xr9CNBX1hnHOUH1A16VrWqW0BPWXUO1+rk R6t0HRLmFzEM2Jst5C5cTZucR8j3h7zSx+JWDgPOtGNg6H9XrryH43P6PaVejvPoMTByHjEOxMU8 9RN6OOTrD4zyVh+mX6kis+kFwIfp1kJ/GUk4SOpB3kV9DxLkIZfoyNAZhtZ+izLQZk17YPDPAb3E Vtz6w8A+RMef5pTdPhdZLqde2K3CN3cJvTJoEOCWkwOO0Z67y4H4UGR8dwAX6ebha9SXuEtP1RGr XKTYkK4wggbcMIIFxKADAgECAgRDYnY/MA0GCSqGSIb3DQEBCwUAMFExEzARBgoJkiaJk/IsZAEZ FgNjb20xFTATBgoJkiaJk/IsZAEZFgVCb3NjaDEMMAoGA1UEAxMDUEtJMRUwEwYDVQQDEwxCb3Nj aC1DQTEtREUwHhcNMTYxMjE0MTI0MjI4WhcNMTkxMjE0MTMxMjI4WjCBhjETMBEGCgmSJomT8ixk ARkWA2NvbTEVMBMGCgmSJomT8ixkARkWBWJvc2NoMQwwCgYDVQQDEwNwa2kxDjAMBgNVBAMTBUJP U0NIMQswCQYDVQQDEwJERTEKMAgGA1UEAxMBSjEKMAgGA1UEAxMBRTEVMBMGA1UEAxMMSmVucy5H dWJhbGxhMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnsORNxL2PTGGFOiPkz+PdQqq HnHThJQE13A4haBp369A1J3NXXIsgrrULByynlJNAvEKuO+E79y1pQU2DuPyzmPRnRG4x3qu0Xyf /d+6VFwrrPuhzw38MXroodUMZ0aRBhq49fNUzv+E8El1ZQCNxi52rQHZFn0B0aNcDBaKB2/GYbu+ Q6k1pyVoOc4gBILR84kGiTKdkRchL5JWD6LLoVhvhTH9JYiipjdf0o3K6gDdNMxTeOIUGQEql8BM rWisEE73eYQfTFPEx+4JrgkJD9LRZyN7VT+iFe7727lcvmBFLoguVuRxVH10VJOIhP8Iqv5PN+cM SUqYv1ujyOZJvQIDAQABo4IDhDCCA4AwCwYDVR0PBAQDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMC BggrBgEFBQcDBDCCAUYGA1UdIASCAT0wggE5MIIBNQYNKwYBBAGpRoN9AQIBATCCASIwLAYIKwYB BQUHAgEWIGh0dHA6Ly90cnVzdGNlbnRlci5ib3NjaC5jb20vY3BzMIHxBggrBgEFBQcCAjCB5BqB 4VRoZSBCb3NjaCBDZXJ0aWZpY2F0aW9uIFByYWN0aWNlIFN0YXRlbWVudCAoQ1BTKSBhdmFpbGFi bGUgYXQgaHR0cDovL3RydXN0Y2VudGVyLmJvc2NoLmNvbS9jcHMgaXMgaGVyZWJ5IGluY29ycG9y YXRlZCBpbnRvIHlvdXIgdXNlIG9yIHJlbGlhbmNlIG9uIHRoaXMgQ2VydGlmaWNhdGUuIFRoaXMg Q1BTIGNvbnRhaW5zIGxpbWl0YXRpb25zIG9uIHdhcnJhbnRpZXMgYW5kIGxpYWJpbGl0aWVzLjBC BgNVHREEOzA5gRVKZW5zLkd1YmFsbGFAZXRhcy5jb22gIAYKKwYBBAGCNxQCA6ASDBBnYmo5ZmVA Ym9zY2guY29tMIIBLwYDVR0fBIIBJjCCASIwa6BpoGekZTBjMRMwEQYKCZImiZPyLGQBGRYDY29t MRUwEwYKCZImiZPyLGQBGRYFQm9zY2gxDDAKBgNVBAMTA1BLSTEVMBMGA1UEAxMMQm9zY2gtQ0Ex LURFMRAwDgYDVQQDEwdDUkwyMjIyMIGyoIGvoIGshmZsZGFwOi8vYm9zY2guY29tL2NuPVdpbkNv bWJpbmVkMixjbj1Cb3NjaC1DQTEtREUsY249UEtJLGRjPUJvc2NoLGRjPWNvbT9jZXJ0aWZpY2F0 ZVJldm9jYXRpb25MaXN0P2Jhc2WGQmh0dHA6Ly90cnVzdGNlbnRlci5ib3NjaC5jb20vQ1JML2Jv c2NoLWNhMS1kZV9wa2lfY29tX2NybGZpbGUyLmNybDArBgNVHRAEJDAigA8yMDE2MTIxNDEyNDIy OFqBDzIwMTkxMjE0MTMxMjI4WjAfBgNVHSMEGDAWgBTeBOLMiQj9dYzYpDAx2BBt5aH0mzAdBgNV HQ4EFgQU7zHzHbRQfrCZKNIpxXAhm4UNoqAwCQYDVR0TBAIwADAZBgkqhkiG9n0HQQAEDDAKGwRW OC4xAwIEsDANBgkqhkiG9w0BAQsFAAOCAQEAQhXBnRdtUfXuHnZ4/tHaGQh49p/yH1LdfZYcEjtH 0PdLaVCNgpEp5cdIyr/9aQ17OMVTVZk1LeQ1QQ9LYoWTzdXgvbfZWgrL7JhWeFlcyC0vWUwyCYgU ayC2wF+4T4jUvZQQV0uob/n3H+TG/uanRN1R+1lZBBSDU1Qn+B2ECQdxurdjL7S5as1t2ohHG3oW iK0eOJpTzvT/coglaiwa2DPiNoYFyFdyUf3PFSgfzUW1FOTmoXuIbJpJFGnWzKazJFjuHXc+a88m wsWcuhdqfpvHaUtfr5vjT5BqTffwH2hC78PYlMwJV+WSkxTbnKpl03Wb9EzaxS3Q5MuL6ME4CjGC At0wggLZAgEBMFkwUTETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMGCgmSJomT8ixkARkWBUJvc2No MQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERQIEQ2J2PzAJBgUrDgMCGgUAoIIB WTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMjkwOTUzNDVa MCMGCSqGSIb3DQEJBDEWBBSVA8OJ6yJQ99kIIfEKLouuOa1UojAkBgkqhkiG9w0BCQ8xFzAVMAoG CCqGSIb3DQMHMAcGBSsOAwIaMGgGCSsGAQQBgjcQBDFbMFkwUTETMBEGCgmSJomT8ixkARkWA2Nv bTEVMBMGCgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNB MS1ERQIEQ2J0ADBqBgsqhkiG9w0BCRACCzFboFkwUTETMBEGCgmSJomT8ixkARkWA2NvbTEVMBMG CgmSJomT8ixkARkWBUJvc2NoMQwwCgYDVQQDEwNQS0kxFTATBgNVBAMTDEJvc2NoLUNBMS1ERQIE Q2J0ADANBgkqhkiG9w0BAQEFAASCAQB8kv/n/XutADpJ1BfaINMPyjdfP2nKFByjlUbN52EdcxXP oHxaWWO6GFoC26oG5EcOSoPEsbIU6o33HMTOU3XByNRh5hbEwD/xECMBPswlNF0DTz8GY81U40JI pUWEIVqdzy53xk00GUe5T7Ovo8s1zOVR69NPwcOZJHlFzJc2xKi23lX1MQbJQ4KN0kzVofJpPANQ eFbJtTzs7REspbVNjO6kqjgelwAfPS5cyxChu6S0HSXHsbDpmbJsLPei0dPwFWvSBWnFeOoynmye Zl+5mebkNKid8TNhQyfYfvxS8Vpv5uQ/VPEhWgiRdZJb8KfyVfkf+G9TB799BHRGCE9/AAAAAAAA ------=_NextPart_000_004C_01D261C1.D3D7E6D0-- From nobody Thu Dec 29 09:37:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCD812961E for ; Thu, 29 Dec 2016 09:37:49 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 r_RaYhm7TNPB for ; Thu, 29 Dec 2016 09:37:40 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 50F57129620 for ; Thu, 29 Dec 2016 09:37:40 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id p42so357358157ioo.1 for ; Thu, 29 Dec 2016 09:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=JB09M6lyxGPfI68/nMQYlebHScUzL8BcVJx4a0fyMjE=; b=IhZ7Gs5fTTBZv91NkrDCy/moPsKBwvX+CEBxitggVUCZhYiVrwqZ0LoaMh22bfxMgs Wc0LT1aAjanhbyvpjs55xsh4Toxc43JwEvKgxLB2JzpzRRw7yeeeEg+9ZuAwRD8O9kQC 1K6yDbOVjvI9B/rYXKiBEa0WtvpWrXvfkd3PmY7P3tMi/tuRC8JyLoViB38kLWuDPDW1 T/dBExld11QbioqVHvmy8jv+inQnxWbRTByDcqGzfHtWFlfen0H2vhYNDkMmED2xC/At bPdkCx5Z3GKTNDmrLjtkHF+jm4VGCfZYTH7CgFNia89FE8GZPQ6dGjnXWsLURyPEYrpP DVug== 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=JB09M6lyxGPfI68/nMQYlebHScUzL8BcVJx4a0fyMjE=; b=epN/6zkGrRjtbUe36ZuePOvfJFpeFqOIRUkQoUnWAtNvMf98gWVWaUNswKGyTgQr+T 90s5Rhhvd74SINhpTxv7qtSf1Nv8U5qdYtPslS22ihNUEUKRFuXmIvVtkEne6SYRAcH/ Qlvp4aotIRbKNAuFzgGxnBpBlCpTpUzn9hXVXO4wWKKXy+GdeysonfUV/GIDlaOg5Chd T0YbFXWpU8LciszEamN1QOBBWZuH8aydRyg9q+idg+sm7FaWt3H7W5cfDFFzGECiJRow qId9ZemacVJ/Z1U+pqRzx6K6+R89+z6jBFxFkQKL+ce2ar1mbu6Yfrdejx/f/neaCah6 60yA== X-Gm-Message-State: AIkVDXLwUF+pnl6Ni0J3GL+Tz3T9361g9JFTUfT8L+i9baZmpvBcqvQU30rSlPKvKSI8DraT9oBwhzeppNBKXQ== X-Received: by 10.107.134.131 with SMTP id q3mr24194186ioi.168.1483033059445; Thu, 29 Dec 2016 09:37:39 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.22.83 with HTTP; Thu, 29 Dec 2016 09:37:39 -0800 (PST) From: Adam Langley Date: Thu, 29 Dec 2016 09:37:39 -0800 X-Google-Sender-Auth: VrdlIEnCqdJX7tXQPaV1IPC55Tw Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [TLS] Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 17:37:50 -0000 https://github.com/tlswg/tls13-spec/pull/840 is a pull request that specifies that (EC)DH values must be fresh for both parties in TLS 1.3. For clients, this is standard practice (as far as I'm aware) so should make no difference. For servers, this is not always the case: Springall, Durumeric & Halderman note[1] that with TLS 1.2: =E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for mo= re than a day. =E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a da= y. Since this defeats forward security, and is clearly something that implementations of previous versions have done, this change specifically calls it out as a MUST NOT. Implementations would then be free to detect and reject violations of this. This does have a cost because it also excludes the reasonable practice of amortising public value generation over all connections for a few seconds. The draft could attempt to specify a precise, maximum duration for reuse but that is more complex and no value is clearly optimal. Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse values and manage fine today. The generation of (EC)DH public values is also a fixed-based operation and thus can be much faster than DH key-agreement. Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling TLS connections to be decrypted and monitored by a middlebox. TLS is not designed to be decrypted by third-parties=E2=80=94that's kind of the point. Thus anyone doing this should not be surprised to hit a few MUST NOTs and, potentially, to have to configure implementations to allow such a deployment. [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2=80=9D, = IMC 2016, pages 33=E2=80=9347, section 4.4. https://dl.acm.org/citation.cfm?id=3D2987= 480 [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Dec 29 10:15:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A484912987B for ; Thu, 29 Dec 2016 10:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qiPQ7rXH5mIR for ; Thu, 29 Dec 2016 10:15:29 -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 8A0A7129878 for ; Thu, 29 Dec 2016 10:15:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 277C8BE50; Thu, 29 Dec 2016 18:15:27 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 UmH7X94lkrXt; Thu, 29 Dec 2016 18:15:25 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 24D8BBE2F; Thu, 29 Dec 2016 18:15:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483035325; bh=vGIs888jI5GeaCZeXLQjn1Hve9tBBtS5QiwyY63OnQc=; h=Subject:To:References:From:Date:In-Reply-To:From; b=wW3ltD04MrQUjd9rdtL6g8BDdAJSB+kWCDL1JCo1GdTjH+2WETYxshp2jgmzp7+eS sww6o6xKC872hgWtc7RaXCG3iNttuHwfHFUIquViML4MFo8GjWetwUG5yLm9SgTMTp 3lrtZGObqO8vxscYGx+r6bLRSaK7HhmyAW0+zatw= To: Adam Langley , "tls@ietf.org" References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> Date: Thu, 29 Dec 2016 18:15:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090208070909030903040103" Archived-At: Subject: Re: [TLS] Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 18:15:31 -0000 This is a cryptographically signed message in MIME format. --------------ms090208070909030903040103 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 29/12/16 17:37, Adam Langley wrote: > https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > specifies that (EC)DH values must be fresh for both parties in TLS > 1.3. >=20 > For clients, this is standard practice (as far as I'm aware) so should > make no difference. For servers, this is not always the case: >=20 > Springall, Durumeric & Halderman note[1] that with TLS 1.2: > =E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so fo= r more > than a day. > =E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than = a day. =2E.. As an individual, I'd be in favour of this change but reading over [1], section 5, I wondered if we'd analysed the effects of 0rtt/replayable-data with that kind of cross-domain re-use in mind? The situation being where session ID based caches or session ticket equivalents in tls1.3 are shared over multiple domains. I don't recall this being explicitly considered, but maybe that's just me forgetting. And hopefully the analysis is that such re-use doesn't enable broader replay of early data, but there may be something worth a mention in the tls1.3 spec, e.g. that there may be linkages between the duration for which entries are maintained in resumption and replay detection caches. Cheers, S. >=20 > [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2=80=9D= , IMC 2016, > pages 33=E2=80=9347, section 4.4. https://dl.acm.org/citation.cfm?id=3D= 2987480 > [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13= / >=20 >=20 > Cheers >=20 > AGL >=20 --------------ms090208070909030903040103 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMjkx ODE1MjRaMC8GCSqGSIb3DQEJBDEiBCADEt764kBj3tw+iCie/Cn4BeThCEITkfVmTpbChZP0 ZTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAsZLB9oK53EpNf9qqqwhySUYft+dlsWUxBb+5k0yhNS3oPFTXHAxXc H/+BpWgEhqfaHDntxIE6fDP+PA8530LX8ije8I1K/sV7i9nvji1jffCBQsqf6PerVi8vYoX4 VJbGOvun7OqE6xGhyCx7DRGj1patc5V07fb2aG2Vm7HlM0LHs9lAFSIbJUHFGMf3tmBFk68H Fu2RqhqNrs2DhqJ71OvYG3ncJp+FGFF1bx2rin44FLALZARtYz1Ep1qeyR/nxMDhVkw2KBYq 5CT+9qPYkujeOMowjGOEgkI39Xi7BlFfYaNoVa1SiIg/yCACReb1HtvL6P2CLZ4rPFXdGLbj AAAAAAAA --------------ms090208070909030903040103-- From nobody Thu Dec 29 10:39:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736CB129880 for ; Thu, 29 Dec 2016 10:39:38 -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 rfppSwn6raI9 for ; Thu, 29 Dec 2016 10:39:36 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB9112963E for ; Thu, 29 Dec 2016 10:39:35 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id t125so212051250ywc.1 for ; Thu, 29 Dec 2016 10:39:35 -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=vkSZ/Yl/Ejj9mTuDpNJaZd5ZKzXjuHMC6PP3Eaa7srs=; b=YmWjBszUv03LZdUDlYCOKi6GmJoxPpvnX3MqcVHNoPxr8fvDZbYqbPaC/6ZSHPy9xE GG4elTiFs8aGHGLRYv1TM/AQYatFId46YiiRLzgyLsu1mdMPx/36pgKSRNMTEn8Ehbqn h9S6p8EZVPotGyfSkRRoX0Bp5PsceYZzc1j64vv/yIKS5St5qrfqK6KKHMoKk/eOaqho 8rKi2iWUnGH9visgfST4an9ytSNT04e3XCpQlQFBfz6vnJ9VYVwhkaQKCQMOIr7luLPh lhL4zd5Pb+Shn9kzC/MjQcBKUFUhAmfjOKED1v4ZZ3NRMEfNq2mDlifFTRx6f7eTrZVw ckkw== 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=vkSZ/Yl/Ejj9mTuDpNJaZd5ZKzXjuHMC6PP3Eaa7srs=; b=UlgTyFlQzGUcyi4f6B8O0saFo1LUJ8V1bJ5Sz4WQ9B0r6fMoL3hulAQsg9fKJgAF8Z SQqK0+FCwhabTKWHTbzEsZc0aS3Is5kx1cpdhoslNJ2ouAQEbfFIK9JusYx23xN4ja8U 3FgbdMZ5Gytp9R9kYWV1TEfBYf5UBNfbnyoBwH7W1+U4xqfgm4tpnlIS8wekRoDOJ2Zu d+aTvjHH3iaWO0vCLgPypxYzSCNtJ9xZuTA+nxViWt6u4r6No7hmIFVomk2UJ/f+2CQt JQdvXNREzgAr5lBkiwzt9tntw+OBLiPD/3rdDCxMtg42cCf+t+yh1cXBdEGTY/7CO1Ze vqJA== X-Gm-Message-State: AIkVDXJIWt+OUO22AM0Xr2prdlfG/rgeQ4gRZkvoH8sHI0kEfOpB6gw6h0glowqWJ60WkO2N3CJjc4f+yB9TFQ== X-Received: by 10.129.59.9 with SMTP id i9mr40743952ywa.79.1483036775198; Thu, 29 Dec 2016 10:39:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Thu, 29 Dec 2016 10:38:54 -0800 (PST) In-Reply-To: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> From: Eric Rescorla Date: Thu, 29 Dec 2016 10:38:54 -0800 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114325bc2cf39d0544d06897 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 18:39:38 -0000 --001a114325bc2cf39d0544d06897 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell wrote: > > Hiya, > > On 29/12/16 17:37, Adam Langley wrote: > > https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > > specifies that (EC)DH values must be fresh for both parties in TLS > > 1.3. > > > > For clients, this is standard practice (as far as I'm aware) so should > > make no difference. For servers, this is not always the case: > > > > Springall, Durumeric & Halderman note[1] that with TLS 1.2: > > =E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so fo= r more > > than a day. > > =E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than = a day. > ... > > As an individual, I'd be in favour of this change but reading > over [1], section 5, I wondered if we'd analysed the effects of > 0rtt/replayable-data with that kind of cross-domain re-use in mind? > The situation being where session ID based caches or session ticket > equivalents in tls1.3 are shared over multiple domains. > > I don't recall this being explicitly considered, but maybe that's > just me forgetting. And hopefully the analysis is that such re-use > doesn't enable broader replay of early data, but there may be > something worth a mention in the tls1.3 spec, e.g. that there may > be linkages between the duration for which entries are maintained > in resumption and replay detection caches. > This question seems essentially orthogonal to the question of ECDHE key reuse because even if you use the same ECDHE key in perpetuity you get unique traffic keying material for each connection. -Ekr > Cheers, > S. > > > > > [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2=80= =9D, IMC 2016, > > pages 33=E2=80=9347, section 4.4. https://dl.acm.org/citation.cfm?id=3D= 2987480 > > [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13= / > > > > > > Cheers > > > > AGL > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114325bc2cf39d0544d06897 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <= ;stephen.far= rell@cs.tcd.ie> wrote:

Hiya,

On 29/12/16 17:37, Adam Langley wrote:
> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that
> specifies that (EC)DH values must be fresh for both parties in TLS
> 1.3.
>
> For clients, this is standard practice (as far as I'm aware) so sh= ould
> make no difference. For servers, this is not always the case:
>
> Springall, Durumeric & Halderman note[1] that with TLS 1.2:
>=C2=A0 =C2=A0=E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.= 3% do so for more
>=C2=A0 =C2=A0 =C2=A0than a day.
>=C2=A0 =C2=A0=E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for= more than a day.
...

As an individual, I'd be in favour of this change but reading
over [1], section 5, I wondered if we'd analysed the effects of
0rtt/replayable-data with that kind of cross-domain re-use in mind?
The situation being where session ID based caches or session ticket
equivalents in tls1.3 are shared over multiple domains.

I don't recall this being explicitly considered, but maybe that's just me forgetting. And hopefully the analysis is that such re-use
doesn't enable broader replay of early data, but there may be
something worth a mention in the tls1.3 spec, e.g. that there may
be linkages between the duration for which entries are maintained
in resumption and replay detection caches.

<= div>This question seems essentially orthogonal to the question of ECDHE key= reuse
<= div>


Cheers,
S.

>
> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2=80= =9D, IMC 2016,
> pages 33=E2=80=9347, section 4.4. https://dl.acm.or= g/citation.cfm?id=3D2987480
> [2] https://datatracker.iet= f.org/doc/draft-green-tls-static-dh-in-tls13/
>
>
> Cheers
>
> AGL
>


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


--001a114325bc2cf39d0544d06897-- From nobody Thu Dec 29 10:50:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820A81299F6 for ; Thu, 29 Dec 2016 10:50:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGOk_t8iMzKw for ; Thu, 29 Dec 2016 10:50:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 044FD1295AB for ; Thu, 29 Dec 2016 10:50:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5CFA0BE4C; Thu, 29 Dec 2016 18:50:29 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 LdiedcZ41bmi; Thu, 29 Dec 2016 18:50:25 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 62555BE47; Thu, 29 Dec 2016 18:50:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483037424; bh=7GnLO6l7nGnRX3+HSyQ0vTVLnWFi9S4BeR5F6R9fLsg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=IRPquyUFVA0PR9sI2VuFtbwQaKdrybEql4Vzm+6cFmMRFWQC81/CJ8an7BBv0p72Q kZ/ZIfV66JZXmmjfRrh+fmYpnnxH2XQ8ePeYh5FWJtp6Z7NnAGQk5XgNT3/ytjzV4u mQX6nM7OMYaoZSoqe2uYxME+D80Bv4WSWB9jEce8= To: Eric Rescorla References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> Date: Thu, 29 Dec 2016 18:50:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010802050601010205090808" Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 18:50:34 -0000 This is a cryptographically signed message in MIME format. --------------ms010802050601010205090808 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 29/12/16 18:38, Eric Rescorla wrote: > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> On 29/12/16 17:37, Adam Langley wrote: >>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that >>> specifies that (EC)DH values must be fresh for both parties in TLS >>> 1.3. >>> >>> For clients, this is standard practice (as far as I'm aware) so shoul= d >>> make no difference. For servers, this is not always the case: >>> >>> Springall, Durumeric & Halderman note[1] that with TLS 1.2: >>> =E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so = for more >>> than a day. >>> =E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for more tha= n a day. >> ... >> >> As an individual, I'd be in favour of this change but reading >> over [1], section 5, I wondered if we'd analysed the effects of >> 0rtt/replayable-data with that kind of cross-domain re-use in mind? >> The situation being where session ID based caches or session ticket >> equivalents in tls1.3 are shared over multiple domains. >> >> I don't recall this being explicitly considered, but maybe that's >> just me forgetting. And hopefully the analysis is that such re-use >> doesn't enable broader replay of early data, but there may be >> something worth a mention in the tls1.3 spec, e.g. that there may >> be linkages between the duration for which entries are maintained >> in resumption and replay detection caches. >> >=20 > This question seems essentially orthogonal to the question of ECDHE key= > reuse > because even if you use the same ECDHE key in perpetuity you get unique= > traffic keying material for each connection. Fair enough, I probably should've started a new thread so have done that now. S >=20 > -Ekr >=20 >=20 >> Cheers, >> S. >> >>> >>> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2=80= =9D, IMC 2016, >>> pages 33=E2=80=9347, section 4.4. https://dl.acm.org/citation.cfm?id=3D= 2987480 >>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls= 13/ >>> >>> >>> Cheers >>> >>> AGL >>> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >=20 --------------ms010802050601010205090808 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMjkx ODUwMjRaMC8GCSqGSIb3DQEJBDEiBCA5XR3Wm7hafwXhxnGzl+QHJ+li6J5Qexb9lPRg0uUG DzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBtpGT4PVLW1aKUnCBnW0Y5KHd59FFuyKQLeyV4wRK4fs85l9aPJewq /84S3QOcHc6P9aGr+LdmIPzY321zL55zUQEZZbnp71eKINgaeKNOT2EKoqkeVZXNHPK0clXu 2SKOH9jm1f4U7msQVtKRwWyLZ5kQNIj4AAhcW3J3XfCzwN2Fmlo4ehjOApOyowLvjhGW2vck 7YoVwTCRmuPE0INNPO1onyQBPJVxKjQ+Sk0OEW6V7spq9lAf9J48z9yIumkdFsnjyh9NF+hL EOearpbK21P3s7OkjOLgpC4ERnc9I5lKJkeWE90rYYEXKZJmIC2/s3pvIoPieELezCyjaSgI AAAAAAAA --------------ms010802050601010205090808-- From nobody Thu Dec 29 11:09:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22EB12961A for ; Thu, 29 Dec 2016 11:09:14 -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 Grgs5WD5iOqw for ; Thu, 29 Dec 2016 11:09:13 -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 1DE1F129444 for ; Thu, 29 Dec 2016 11:09:13 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id r204so212872497ywb.0 for ; Thu, 29 Dec 2016 11:09: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=QoG0BfGq5hQSj8bRLaDa1+j/6V2Rnt7+x5BmyJQDZ9g=; b=rKAO9VwJosI9b5hoJjXTodFMTdDKZDYOLl41eCzGVzvptp7CElbFOGS5SitRZOTi+U 8IESeJp/Yz0wa0zMNARyM/FhRec7+J2LRWPWCtZ97NYfXGMms2V9BYKA23qT9S6lVSnW DPyt4WUR3xChGM2CGrboi26GtEntVq5QWeDj0855WQ4iOlUX1CsTkA+F0t0KwE+kbSfJ BaWp4dwBZLYETBHkIozSv74m/MgwFPR6k3WSEt12I4tdbOwwAqtIEuYZjHhBKZPhJT1H Er7km00qp7cWXIANgNKsStZHAfUjm6n8Z6EPPTmMJ48dT4t0E1cC2g/T/34EBVczSZI1 SByQ== 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=QoG0BfGq5hQSj8bRLaDa1+j/6V2Rnt7+x5BmyJQDZ9g=; b=SUJT8U+g630jc8xX3T2NnhltJuPd1IIICeG1EFEl8tXpWy+aweIebSygpWW7olU7Sm cGg1K1KO9jth3i2uK+BOMJV9Z7WwfMHPO9yLbQwXZeihcYNrq3kPkX3ytyC11zg5RHVs OqzEVyLteRcFrMSNjYwYhpXS7Vtawk7tWTj7vdNn22nvJUxhjENSe+NceSfkBGtvzWkh IYzkoh4fZtxLkqCtWGDHbbQpm8MDCAqt7t30g3iZ+QapFT/xMSoUex8QGNa14mhXNac7 3jygtm7wpMYNHMjHryFUA+P9qkMWrVlBf7jvmAnV9VUOhxQnt17Z6giofDk7DIuJiIoP jtig== X-Gm-Message-State: AIkVDXK8gb41dRtN8lwS5rqvOaDB5JZ3fYKIzowuRsXBu0Nyd3kfDo4KM7DVCYsvsaHUowWtPnKwrF7QKcRmWA== X-Received: by 10.129.110.66 with SMTP id j63mr29844522ywc.52.1483038551627; Thu, 29 Dec 2016 11:09:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Thu, 29 Dec 2016 11:08:31 -0800 (PST) In-Reply-To: <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> From: Eric Rescorla Date: Thu, 29 Dec 2016 11:08:31 -0800 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114929fc0f138d0544d0d21f Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 19:09:14 -0000 --001a114929fc0f138d0544d0d21f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell wrote: > > > On 29/12/16 18:38, Eric Rescorla wrote: > > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie > >> wrote: > > > >> > >> Hiya, > >> > >> On 29/12/16 17:37, Adam Langley wrote: > >>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > >>> specifies that (EC)DH values must be fresh for both parties in TLS > >>> 1.3. > >>> > >>> For clients, this is standard practice (as far as I'm aware) so shoul= d > >>> make no difference. For servers, this is not always the case: > >>> > >>> Springall, Durumeric & Halderman note[1] that with TLS 1.2: > >>> =E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so = for more > >>> than a day. > >>> =E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for more tha= n a day. > >> ... > >> > >> As an individual, I'd be in favour of this change but reading > >> over [1], section 5, I wondered if we'd analysed the effects of > >> 0rtt/replayable-data with that kind of cross-domain re-use in mind? > >> The situation being where session ID based caches or session ticket > >> equivalents in tls1.3 are shared over multiple domains. > >> > >> I don't recall this being explicitly considered, but maybe that's > >> just me forgetting. And hopefully the analysis is that such re-use > >> doesn't enable broader replay of early data, but there may be > >> something worth a mention in the tls1.3 spec, e.g. that there may > >> be linkages between the duration for which entries are maintained > >> in resumption and replay detection caches. > >> > > > > This question seems essentially orthogonal to the question of ECDHE key > > reuse > > because even if you use the same ECDHE key in perpetuity you get unique > > traffic keying material for each connection. > > Fair enough, I probably should've started a new thread so have > done that now. > Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI changes: https://tlswg.github.io/tls13-spec/#NewSessionTicket "Any ticket MUST only be resumed with a cipher suite that has the same KDF hash as that used to establish the original connection, and only if the client provides the same SNI value as in the original connection, as described in Section 3 of [RFC6066] ." We have discussed relaxing that restriction, specifically to allow the following case: - Client connects to server with SNI=3DA and the server supplies a cert wit= h SNI=3DA, B - Client reconnects to server and tries to resume with SNI=3DB See PR: https://github.com/tlswg/tls13-spec/pull/777. However, the general consensus was to leave this out of the base spec, though we might supply an enhancement for that later (and potentially slightly soften the above language to foreshadow such an enhancement). -Ekr > S > > > > > -Ekr > > > > > >> Cheers, > >> S. > >> > >>> > >>> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2= =80=9D, IMC 2016, > >>> pages 33=E2=80=9347, section 4.4. https://dl.acm.org/citation.cfm?id= =3D2987480 > >>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh- > in-tls13/ > >>> > >>> > >>> Cheers > >>> > >>> AGL > >>> > >> > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > >> > > > > --001a114929fc0f138d0544d0d21f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell <= ;stephen.far= rell@cs.tcd.ie> wrote:


On 29/12/16 18:38, Eric Rescorla wrote:
> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>> Hiya,
>>
>> On 29/12/16 17:37, Adam Langley wrote:
>>> https://github.com/tlswg/tls13-spec/= pull/840 is a pull request that
>>> specifies that (EC)DH values must be fresh for both parties in= TLS
>>> 1.3.
>>>
>>> For clients, this is standard practice (as far as I'm awar= e) so should
>>> make no difference. For servers, this is not always the case:<= br> >>>
>>> Springall, Durumeric & Halderman note[1] that with TLS 1.2= :
>>>=C2=A0 =C2=A0=E2=88=99 4.4% of the Alexa Top 1M reuse DHE value= s and 1.3% do so for more
>>>=C2=A0 =C2=A0 =C2=A0than a day.
>>>=C2=A0 =C2=A0=E2=88=99 14.4% of the Top 1M reuse ECDHE values, = 3.4% for more than a day.
>> ...
>>
>> As an individual, I'd be in favour of this change but reading<= br> >> over [1], section 5, I wondered if we'd analysed the effects o= f
>> 0rtt/replayable-data with that kind of cross-domain re-use in mind= ?
>> The situation being where session ID based caches or session ticke= t
>> equivalents in tls1.3 are shared over multiple domains.
>>
>> I don't recall this being explicitly considered, but maybe tha= t's
>> just me forgetting. And hopefully the analysis is that such re-use=
>> doesn't enable broader replay of early data, but there may be<= br> >> something worth a mention in the tls1.3 spec, e.g. that there may<= br> >> be linkages between the duration for which entries are maintained<= br> >> in resumption and replay detection caches.
>>
>
> This question seems essentially orthogonal to the question of ECDHE ke= y
> reuse
> because even if you use the same ECDHE key in perpetuity you get uniqu= e
> traffic keying material for each connection.

Fair enough, I probably should've started a new thread so have
done that now.

Currently TLS 1.3 forbid= s *both* 0-RTT and resumption if the SNI changes:

"Any tick= et MUST only be resumed with a cipher suite that has the same=20 KDF hash as that used to establish the original connection, and only if=20 the client provides the same SNI value as in the original connection, as described in Section 3 of [RFC6066]."

We have discussed rel= axing that restriction, specifically to allow the following case:

- Client connects to server with SNI=3DA and the server sup= plies a cert with SNI=3DA, B
- Client reconnects to server and tr= ies to resume with SNI=3DB=C2=A0


However, the general c= onsensus was to leave this out of the base spec, though we
might = supply an enhancement for that later (and potentially slightly soften the a= bove
language to foreshadow such an enhancement).

<= /div>
-Ekr



S

>
> -Ekr
>
>
>> Cheers,
>> S.
>>
>>>
>>> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcu= ts=E2=80=9D, IMC 2016,
>>> pages 33=E2=80=9347, section 4.4. https://d= l.acm.org/citation.cfm?id=3D2987480
>>> [2] https://datatra= cker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/
>>>
>>>
>>> Cheers
>>>
>>> AGL
>>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls=
>>
>>
>


--001a114929fc0f138d0544d0d21f-- From nobody Thu Dec 29 11:28:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7912B1294E4 for ; Thu, 29 Dec 2016 11:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esz6QrtVLw7M for ; Thu, 29 Dec 2016 11:28:47 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with SMTP id 0BB2F129478 for ; Thu, 29 Dec 2016 11:28:46 -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 3tqKQj3PnHz26M6; Thu, 29 Dec 2016 20:28:45 +0100 (CET) X-purgate-ID: 152705::1483039725-0000521C-E80CDBAB/0/0 X-purgate-size: 2826 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 3tqKQj15XdzGnyg; Thu, 29 Dec 2016 20:28:45 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 201121A5D4; Thu, 29 Dec 2016 20:28:45 +0100 (CET) In-Reply-To: To: Adam Langley Date: Thu, 29 Dec 2016 20:28:45 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161229192845.201121A5D4@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 19:28:49 -0000 Adam Langley wrote: > > https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > specifies that (EC)DH values must be fresh for both parties in TLS > 1.3. > > For clients, this is standard practice (as far as I'm aware) so should > make no difference. For servers, this is not always the case: > > Springall, Durumeric & Halderman note[1] that with TLS 1.2: > ? 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so for more > than a day. > ? 14.4% of the Top 1M reuse ECDHE values, 3.4% for more than a day. > > Since this defeats forward security, and is clearly something that > implementations of previous versions have done, this change > specifically calls it out as a MUST NOT. Implementations would then be > free to detect and reject violations of this. While you may have good intentions, the idea "and reject violations of this" sounds like a bad idea to me. First of all, forward secrecy is equally defeated by TLS session caching (traditional as well as session tickets), and the effect of rfc5077 TLS session tickets is likely at least a magnitude worse--and cannot be "fixed" by clients purging the tickets earlier. Reuse of DHE values should not come as a surprise, PFS with DHE is prohibitively expensive with 2048+ bit ephemeral keys. DHE in TLS has been well known to be fatally flawed (publicly known since the issue was raised by Yngve on the TLS ietf mailing list in 2007). https://www.ietf.org/mail-archive/web/tls/current/msg01647.html Since Sun/Oracle hardwired DHE to at most 1024 bits up to JavaSE 7, i.e. on Billions on devices out there, DHE in TLS is a very dead horse. Ephemeral ECDHE values should be much less painful performance-wise, but may happen to accidentally share the same properties as DHE values. Potentially, the (EC)DHE keypairs are (mis-)managed above the TLS stack, instead of entirely within--in which case this would not be the fault of the TLS implementation code, but of the TLS implementation API (design). Now what does it mean when a _client_ that happens to connect to one of these 14.4% Alexa top 1M sites that reuse ECDHE values, notices a reuse of ECDHE on a repeated full handshake (which will not happen immediately due to session caching&resumption). This would result is random handshake failures (client aborting the TLS handshake). The server doesn't know why the client chokes, only the client can decided to retry, but this is unlikely to affect the servers approach to reusing the (EC)DHE value at all. So the only thing this will cause is headaches to users and support folks. It will *NOT* improve the security by one iota. If you want to improve something, then specify how to obtain the desired behaviour, not how to panic and choke. -Martin From nobody Thu Dec 29 11:36:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14E76129614 for ; Thu, 29 Dec 2016 11:36:12 -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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 QI3AdA-IcKgT for ; Thu, 29 Dec 2016 11:36:10 -0800 (PST) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52786129488 for ; Thu, 29 Dec 2016 11:36:10 -0800 (PST) Received: by mail-io0-x244.google.com with SMTP id j76so22221142ioe.0 for ; Thu, 29 Dec 2016 11:36:10 -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=K7flfoqkZHvS5vWknHKurKDPYnPqDCH6z8kUjB/ln5A=; b=jN8OPhpOPpNnauax5bMgfVV0NNzZPU5pYQ3PDDc2XqD3PrM3A9g9y8GnHwbZtdOFky rx4E23T5UbPHw5qLHzQSIBcPsSPBvgikli4oKbl35rtZ9NBeIPzKFuMdVYD8cgzbKes4 9OHj+AHYBTEcjAe2i66lW73dOief87MRdQAUqKTTD/ypOcoC7iKhqVljxCL+kTjWyVOG 6aMgl52Z49cX1LD2+qhZrywoxtAmhTPMVNMoUL2dgTON6Z5owi8tp65wG+oq6J3jk+P5 sFkgUjvmF2f/9IEWRKqcThbn1Wxxo7UA1msgxG5Wgz6vUiwBNqNuRSNutAvdUZ0S3jMX V0cQ== 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=K7flfoqkZHvS5vWknHKurKDPYnPqDCH6z8kUjB/ln5A=; b=TR9UWqI77fBr39vnMvIy5cvp1/mYPINuHRyzsgSgkQf1sVvhE+ZRgLqS2w+TK9j+Kd mP2IqSTo4Q1EDgbxZt0b5TVSlhIuuM9jy6nGOVjexYxOnzgG79T3HEv/+0jW0hj15KsA Z5bRTdlhDp+/Xwiq2hhGI7vGLmelBapltIclIJI8Q6hZHEdsAgiSFLeFrF0lZOPrL305 FaxGOEWAxUpDDw4H+msmnkjfAe8jRzXCGa7AlNHXFUoC9zo+gin3xZKJBofSIqX+QE/x q5JBOH/t0pEWjxbjah8p3/lxYULmBKV+7nI2ID1FGxsKiPoUL7CXIsjQ+a3sF2sd3RI4 DmTw== X-Gm-Message-State: AIkVDXLMLvfqS6oZraMOUj3ZSFxWkkFAgTYku4EN+JeMo0dsIxLRBauzQv1eCQodoxNLDyuWarT+zdJ/h81ZpQ== X-Received: by 10.107.134.131 with SMTP id q3mr24587240ioi.168.1483040169563; Thu, 29 Dec 2016 11:36:09 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.22.83 with HTTP; Thu, 29 Dec 2016 11:36:09 -0800 (PST) In-Reply-To: <20161229192845.201121A5D4@ld9781.wdf.sap.corp> References: <20161229192845.201121A5D4@ld9781.wdf.sap.corp> From: Adam Langley Date: Thu, 29 Dec 2016 11:36:09 -0800 X-Google-Sender-Auth: F3jegHnlLQy3hXxXjXACZiPAHy0 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 19:36:12 -0000 On Thu, Dec 29, 2016 at 11:28 AM, Martin Rex wrote: > First of all, forward secrecy is equally defeated by TLS session caching > (traditional as well as session tickets), and the effect of rfc5077 > TLS session tickets is likely at least a magnitude worse--and cannot > be "fixed" by clients purging the tickets earlier. That is true in TLS 1.2, but one of the things that have been addressed in 1.3. > Reuse of DHE values should not come as a surprise, PFS with DHE is > prohibitively expensive with 2048+ bit ephemeral keys. DHE in TLS has > been well known to be fatally flawed (publicly known since the issue > was raised by Yngve on the TLS ietf mailing list in 2007). > https://www.ietf.org/mail-archive/web/tls/current/msg01647.html > > Since Sun/Oracle hardwired DHE to at most 1024 bits up to JavaSE 7, > i.e. on Billions on devices out there, DHE in TLS is a very dead horse. Again, true in 1.2 but 1.3 has fixed the groups to stronger values. Also, the key-generation of DHE is significantly cheaper than the key-agreement so ephemeral values might be more reasonable then benchmarks suggest. As noted, I think specifying a maximum caching duration is plausible. (Google servers cache QUIC X25519 values for 60-seconds, for example.) But I'm worried about an endless discussion about how long is too long (or long enough). > Now what does it mean when a _client_ that happens to connect to one > of these 14.4% Alexa top 1M sites that reuse ECDHE values, notices a > reuse of ECDHE on a repeated full handshake (which will not happen > immediately due to session caching&resumption). This would result > is random handshake failures (client aborting the TLS handshake). > The server doesn't know why the client chokes, only the client can > decided to retry, but this is unlikely to affect the servers approach > to reusing the (EC)DHE value at all. The idea is to establish this in clients early in the life of 1.3 so that the pressure is enough to keep the ecosystem clean. I don't think that enforcing it in versions prior to 1.3 is viable. Cheers AGL From nobody Thu Dec 29 14:46:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8494A129475 for ; Thu, 29 Dec 2016 14:46: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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 RsdFLOV2_2ty for ; Thu, 29 Dec 2016 14:46:01 -0800 (PST) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB1F912940D for ; Thu, 29 Dec 2016 14:46:01 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id n85so128026797ioi.2 for ; Thu, 29 Dec 2016 14:46:01 -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=zbw960EPdI4IsMHmdSjdN8ApKEAJLKIYiIqQGjksnbI=; b=pf27F145ao1jCoLVxR4RzR0VW68pkeINqf9n/rOgOVckkW31L+PdNlQVZyxT0I+p9v QY44Sw9QDZ1CbjyY36jnyWgpI3FvlBs8o2/9XD8pVzsx19fvrjSXvqOIWmmN5i4bSh8g LIjI7pKS6/S1z/eExi1QAfr4rYTKY7OBetFuYJdlRKiSrvEMx/9mQWU5SI9Zr8twOdnq RJvqkXTNatF74Tz8QQ6sKOYokSkRi4C8r44UEMv/XAb5srlf2YwR1xjx8nk/6XKTt+qc D5mx9/iVptFeQaKLPBzRKC+Ev1ubwAWrnyBmgZQCkSBRAVDOuaEJuhuhuxKWWv3z6qMs mF8g== 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=zbw960EPdI4IsMHmdSjdN8ApKEAJLKIYiIqQGjksnbI=; b=mWJ7+mSphwn67EEWP/H/MvDLQb5qQZQV+s13DU5OysJOCeE8CKVysrVCa3AZar61HH qVeurQIe3wF0aQm1BI/W/jujM99tNr0AiCYJ1BjBipXG1GGsBh/TxS1EDnGP/LSvLD+s +RiAe2jfUZo9+SQWMk5LVKEgUpXWT5wD32PV/W0eSmhq58exLdk9tDxKAew1CS3a11cc uoOKifhv7UR8JN21TbgoqDF0rCJTzZTcxAA0eMcbGN8b893VaklVuqRXvO/sEfeC1ffZ QDQkK0rr+ZZxLyoG5P8zOaMzKvjwmRiZ8uXU5hKpvqgDbjcn79jNOnUiXKm4EiK/pUK0 rSmw== X-Gm-Message-State: AIkVDXLIQGB8vaTW9GtTPt+6nnJ8+cL5Q3b0nHd0cEEPtF6Y+1yg9lFGLspTZwxJ2d4qklz9kmXhNl6kT3Py2w== X-Received: by 10.107.134.131 with SMTP id q3mr25140440ioi.168.1483051554046; Thu, 29 Dec 2016 14:45:54 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.22.83 with HTTP; Thu, 29 Dec 2016 14:45:53 -0800 (PST) In-Reply-To: References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> From: Adam Langley Date: Thu, 29 Dec 2016 14:45:53 -0800 X-Google-Sender-Auth: pFqI23DYCIVZR40jpFOwSe4z4_Y Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2016 22:46:03 -0000 On Thu, Dec 29, 2016 at 11:08 AM, Eric Rescorla wrote: >> >> As an individual, I'd be in favour of this change but reading >> >> over [1], section 5, I wondered if we'd analysed the effects of >> >> 0rtt/replayable-data with that kind of cross-domain re-use in mind? >> >> The situation being where session ID based caches or session ticket >> >> equivalents in tls1.3 are shared over multiple domains. I think there is the following interaction: Given two servers, S1 and S2, which are nominally s1.example.com and s2.example.com, but which both have a *.example.com cert and share ticket keys: An attacker could redirect a 0-RTT handshake that was destined to S1 and feed it to S2. If S2 ignores the SNI value (common) it could accept and process the 0-RTT data even though it was destined for S1. However, in that case TLS 1.2 is probably also affected because S2 would likely process a 1.2 handshake that was destined to S1 as well. (Even without a shared ticket key or session cache.) See http://antoine.delignat-lavaud.fr/doc/www15.pdf for more. Cheers AGL From nobody Thu Dec 29 16:29:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BB9F129562 for ; Thu, 29 Dec 2016 16:29:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNyZiVcRwjl7 for ; Thu, 29 Dec 2016 16:29:08 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 0A08F129486 for ; Thu, 29 Dec 2016 16:29:08 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id x2so222823908itf.1 for ; Thu, 29 Dec 2016 16:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=IwVvtKT3dBDTCkH/sFG9i5HN3CW2O2FLiyiSzkY48BU=; b=u+kIPbdzdoYjOCp5xiLJ6CcFgMWh83Q13VuHZAaJ0cKLtVZ56qrD6LNPLMVqS/PFuI Kc46Ep8qxrPL5+/ITjTSi+zuSf1wiWHyxlKtGzb871SWuUvmetWfftHEdZTXp4L/1Y0k Op08RLyo5D1XyTKIV+YTmlSyxJrX878B/6HHtM4bniHL+SalWpNzXoWuRb/WJ9wvd/9w GHCy83xRWF/0kl0uZUuVxEVVJfHXLP7iV5vMBQhik5z+EhloBQVNMWI77glcl6uxqKHM I7XpeJYRt3oD38Lvb+9c82vWAQ72FMBM1WwZ8sAMiAH3WndB8xCVOVW50R030qM2A+2A HAiQ== 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=IwVvtKT3dBDTCkH/sFG9i5HN3CW2O2FLiyiSzkY48BU=; b=egrFdLBP5ByMOUfyH3ou9k+c+lHtkSU1qXWTdYr/GcpFdSAtjiOBwtzPKgdGjVduMw SkRTAp97+OEaieOGhtM/6F/GcIBOEJAAR8Mnl7IoARD04c/x2E66NsrOW6J5bUT/QeJP iqI3bew3zZE2CRuln9F5Yu3QfKLY9hFFEVW+WYZ9I6mR4sgyCVFybge39ypJiiey4qIe 1FaZzASaSsCmAfHhvnGlwqdabClJj8ZMlfbn8kDlC8WY2qDJa+ckrTqtolExcXy80Egj wkypjJK3Jsrs8R1etwLfy8nWZoHn962Wv1fHmUVlAIVvu/n0dWd065k4xCR92bi2N5Vc OOTQ== X-Gm-Message-State: AIkVDXJYnFKcPbmtqUqEd/hbQj/VcJjrDI2qc4w8pHUQKRCA7aOAIn8KfHkNF/k6dPvLnS1NrMZ6wB1TByBi7w== X-Received: by 10.36.54.135 with SMTP id l129mr35496101itl.58.1483057747315; Thu, 29 Dec 2016 16:29:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.108.137 with HTTP; Thu, 29 Dec 2016 16:29:06 -0800 (PST) In-Reply-To: References: From: Brian Smith Date: Thu, 29 Dec 2016 14:29:06 -1000 Message-ID: To: Adam Langley Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 00:29:09 -0000 Adam Langley wrote: > Since this defeats forward security, and is clearly something that > implementations of previous versions have done, this change > specifically calls it out as a MUST NOT. Implementations would then be > free to detect and reject violations of this. > > This does have a cost because it also excludes the reasonable practice > of amortising public value generation over all connections for a few > seconds. The draft could attempt to specify a precise, maximum > duration for reuse but that is more complex and no value is clearly > optimal. We should brainstorm the unintended negative consequences of this. It would make self-hosting a small that can survive a spike in traffic ("slashdot effect") more difficult, thus encouraging sites to use CDNs, which decrease the integrity, confidentiality, and privacy properties of all connections between the client and the origin server. Unfortunately I don't know how to quantify that. Another unintended consequence is that it makes the PSK modes relatively more attractive. For some very small devices doing ECDH agreement on every connection and only doing a occasionally doing a ECDH keygen could be at the edge of their performance/power limits, and needing to do the ECDH keygen for every connection could easily make using ECDH prohibitive. OTOH, we don't want these devices to use have a fixed ECDH key burned into their ROM, or similar, either. Another unintended consequence is that it makes resumption (formulated as a sort of server-generated PSK in TLS 1.3) more necessary. Although many implementations will probably implement resumption, I think there are a lot of cases where one might prefer to avoid implementing and/or enabling it. Also, even when it is enabled, making ECDH more expensive relative to PSK/resumption would encourage building more complex server software to distribute PSKs across machines. And/or the server may choose to reuse PSKs longer. And/or the server may choose to use the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I can't quantify the effect here. > Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse > values and manage fine today. The generation of (EC)DH public values > is also a fixed-based operation and thus can be much faster than DH > key-agreement. According to the paper, a large majority of servers in the Alexa top 1M are reusing keys. That 14.4% number is a fraction of the 80% servers consistently in the Alexa top 1M that use browser-trusted certificates and that use ECDHE. IIUC, approximately 20% of servers in the Alexa top 1M that use browser-trusted certificates are using RSA key exchange, which means they are also reusing the same key for every connection. Also, according to the paper, more than half of servers aren't using TLS or aren't using browser-trusted certificates, which means that web browser connections to them are likely using the same NULL key. Also, the Alexa top 1M isn't representative of every use of TLS, but rather only one kind of application. > Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling > TLS connections to be decrypted and monitored by a middlebox. TLS is > not designed to be decrypted by third-parties=E2=80=94that's kind of the > point. Thus anyone doing this should not be surprised to hit a few > MUST NOTs and, potentially, to have to configure implementations to > allow such a deployment. The (presumably) accidental reuse of keys for long periods of time is bad, and this MitM idea is even worse. But, if reuse were made a MUST NOT, wouldn't such systems just use a different, perhaps worse, more complex, and undetectable mechanism, like the one Dan Brown suggested in the earlier thread? I think we should assume that while we may be able to help prevent the former accidental badness with such a rule, such a mechanism probably isn't going to have much effect on the latter intentional badness. With all this in mind, absent other information. In the case of servers hosting websites, I do think a limit of less than a minute is reasonable. However, I think for the small device (IoT) case, the limit should be longer, perhaps even hours. Cheers, Brian --=20 https://briansmith.org/ From nobody Fri Dec 30 04:44:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B62E1295C9 for ; Fri, 30 Dec 2016 04:44:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 ZGRoATiEOeN1 for ; Fri, 30 Dec 2016 04:44:34 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 3E30B1295BE for ; Fri, 30 Dec 2016 04:44:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id A353415A3E; Fri, 30 Dec 2016 14:44:32 +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 8X2cX2UpsfEh; Fri, 30 Dec 2016 14:44:31 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 62C102310; Fri, 30 Dec 2016 14:44:31 +0200 (EET) Date: Fri, 30 Dec 2016 14:44:20 +0200 From: Ilari Liusvaara To: Adam Langley Message-ID: <20161230124420.GA11229@LK-Perkele-V2.elisa-laajakaista.fi> References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 12:44:36 -0000 On Thu, Dec 29, 2016 at 02:45:53PM -0800, Adam Langley wrote: > On Thu, Dec 29, 2016 at 11:08 AM, Eric Rescorla wrote: > >> >> As an individual, I'd be in favour of this change but reading > >> >> over [1], section 5, I wondered if we'd analysed the effects of > >> >> 0rtt/replayable-data with that kind of cross-domain re-use in mind? > >> >> The situation being where session ID based caches or session ticket > >> >> equivalents in tls1.3 are shared over multiple domains. > > I think there is the following interaction: > > Given two servers, S1 and S2, which are nominally s1.example.com and > s2.example.com, but which both have a *.example.com cert and share > ticket keys: > > An attacker could redirect a 0-RTT handshake that was destined to S1 > and feed it to S2. If S2 ignores the SNI value (common) it could > accept and process the 0-RTT data even though it was destined for S1. Sounds like standard-issue default-vhost attack (which are sadly common security issues in https://). > However, in that case TLS 1.2 is probably also affected because S2 > would likely process a 1.2 handshake that was destined to S1 as well. > (Even without a shared ticket key or session cache.) See > http://antoine.delignat-lavaud.fr/doc/www15.pdf for more. You mean redirecting full handshake meant for s1.example.com to s2.example.com? Or redirecting a TLS 1.2 resumption handshake? Also, wonder how many servers don't check for SNI when resuming... -Ilari From nobody Fri Dec 30 06:24:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26FDA1293D8 for ; Fri, 30 Dec 2016 06:24:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bduSUeXrE1ip for ; Fri, 30 Dec 2016 06:24:08 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 F4159129445 for ; Fri, 30 Dec 2016 06:24:07 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id 88so248841986uaq.3 for ; Fri, 30 Dec 2016 06:24:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G+t8kIPDn7/MuD+HOVyYP+nesI5+vA4LrzYqyhxhRpM=; b=P3E2i64jUT1fvN2dVJmWuwcapX7YUXt8unfy45c6y+o4NPbjPBUYhIlnhxXMDO6S+Y k76lNPSYv/994AhWuTiRdEeGm+rarKaty5sPDOepY6jps2BaWgaGn2jkI87Ul0gu9I4V AL1Uz96K7hYsAyOQ642CulMO/kJZdipGFFpRMuLleUr1O2FsvK9VG8w2+NuhJV/ZCD4+ FCTGTXDOXwi9zI74uQQ2WqpqmNDZhRZdpnnbRH5Z0mgCBcivzDvg5i/2X4FBzH76amnQ jhU4pZEhBOKivQTiIp8r3QlPC6UeTBG8tuC1WkoK9qMKwF/zGwR+3acV44Vu0WP6cHYA fNXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G+t8kIPDn7/MuD+HOVyYP+nesI5+vA4LrzYqyhxhRpM=; b=Vbu+iVj3e+kLggCvnJADfqKyCOvOu2fyeeoCblKmkIiX7S+My5NrPDx2KEtfpGDKlB ddrZpoJ0JjtO9sMjcop+3ruDMXfh7K/XuRNlsINmybwFZXlz1ULv/KjLSVU93TRgP4Lh oyjtHXoUW9t4g0QcqaiAqJS5p5W3pLGKY9tmKFyOBjJfTPscfxF/S8TY1p0CEfucOdD2 +AKH1VVmE8G8yrs/ZR54NsgV2uCMtk+fEEFjMH0LhZcwDQW+9IbjkJYk7jR3kDV3hvK4 esoJf4YJMtjlRC8i4FiYB5jlEZWzdn14CXHIpXWjYJvV1rWjPOuC3HWnI5C5605KpKZL 1f5w== X-Gm-Message-State: AIkVDXI9qfBCunuy5zbyMg5YUyIx4Gq0Zho/1w/8Asa/vSYmhJUFsXLcg/wH9l+UdK1uNFuZpREUKhLp9ciLeQ== X-Received: by 10.176.2.145 with SMTP id 17mr29268595uah.38.1483107846964; Fri, 30 Dec 2016 06:24:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.106.71 with HTTP; Fri, 30 Dec 2016 06:24:06 -0800 (PST) In-Reply-To: <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> From: Richard Barnes Date: Fri, 30 Dec 2016 09:24:06 -0500 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113e378861feb10544e0f422 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 14:24:10 -0000 --001a113e378861feb10544e0f422 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Dec 29, 2016 at 1:50 PM, Stephen Farrell wrote: > > > On 29/12/16 18:38, Eric Rescorla wrote: > > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie > >> wrote: > > > >> > >> Hiya, > >> > >> On 29/12/16 17:37, Adam Langley wrote: > >>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > >>> specifies that (EC)DH values must be fresh for both parties in TLS > >>> 1.3. > >>> > >>> For clients, this is standard practice (as far as I'm aware) so shoul= d > >>> make no difference. For servers, this is not always the case: > >>> > >>> Springall, Durumeric & Halderman note[1] that with TLS 1.2: > >>> =E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do so = for more > >>> than a day. > >>> =E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for more tha= n a day. > >> ... > >> > >> As an individual, I'd be in favour of this change but reading > >> over [1], section 5, I wondered if we'd analysed the effects of > >> 0rtt/replayable-data with that kind of cross-domain re-use in mind? > >> The situation being where session ID based caches or session ticket > >> equivalents in tls1.3 are shared over multiple domains. > FWIW, we've been working on separating session caches at a finer-than-domain-name level in Firefox, in support of allowing users to set tracking boundaries. https://bugzilla.mozilla.org/show_bug.cgi?id=3D1316283 https://blog.mozilla.org/tanvi/2016/06/16/contextual-identities-on-the-web/ https://www.torproject.org/projects/torbrowser/design/#identifier-linkabili= ty --Richard >> > >> I don't recall this being explicitly considered, but maybe that's > >> just me forgetting. And hopefully the analysis is that such re-use > >> doesn't enable broader replay of early data, but there may be > >> something worth a mention in the tls1.3 spec, e.g. that there may > >> be linkages between the duration for which entries are maintained > >> in resumption and replay detection caches. > >> > > > > This question seems essentially orthogonal to the question of ECDHE key > > reuse > > because even if you use the same ECDHE key in perpetuity you get unique > > traffic keying material for each connection. > > Fair enough, I probably should've started a new thread so have > done that now. > > S > > > > > -Ekr > > > > > >> Cheers, > >> S. > >> > >>> > >>> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2= =80=9D, IMC 2016, > >>> pages 33=E2=80=9347, section 4.4. https://dl.acm.org/citation.cfm?id= =3D2987480 > >>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh- > in-tls13/ > >>> > >>> > >>> Cheers > >>> > >>> AGL > >>> > >> > >> > >> _______________________________________________ > >> 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 > > --001a113e378861feb10544e0f422 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Dec 29, 2016 at 1:50 PM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:


On 29/12/16 18:38, Eric Rescorla wrote:
> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>> Hiya,
>>
>> On 29/12/16 17:37, Adam Langley wrote:
>>> https://github.com/tlswg/tls13-spec/= pull/840 is a pull request that
>>> specifies that (EC)DH values must be fresh for both parties in= TLS
>>> 1.3.
>>>
>>> For clients, this is standard practice (as far as I'm awar= e) so should
>>> make no difference. For servers, this is not always the case:<= br> >>>
>>> Springall, Durumeric & Halderman note[1] that with TLS 1.2= :
>>>=C2=A0 =C2=A0=E2=88=99 4.4% of the Alexa Top 1M reuse DHE value= s and 1.3% do so for more
>>>=C2=A0 =C2=A0 =C2=A0than a day.
>>>=C2=A0 =C2=A0=E2=88=99 14.4% of the Top 1M reuse ECDHE values, = 3.4% for more than a day.
>> ...
>>
>> As an individual, I'd be in favour of this change but reading<= br> >> over [1], section 5, I wondered if we'd analysed the effects o= f
>> 0rtt/replayable-data with that kind of cross-domain re-use in mind= ?
>> The situation being where session ID based caches or session ticke= t
>> equivalents in tls1.3 are shared over multiple domains.

FWIW, we've been working on separating sessio= n caches at a finer-than-domain-name level in Firefox, in support of allowi= ng users to set tracking boundaries.

https://bugzilla.mozilla.org/show_bug.c= gi?id=3D1316283
>>
>> I don't recall this being explicitly considered, but maybe tha= t's
>> just me forgetting. And hopefully the analysis is that such re-use=
>> doesn't enable broader replay of early data, but there may be<= br> >> something worth a mention in the tls1.3 spec, e.g. that there may<= br> >> be linkages between the duration for which entries are maintained<= br> >> in resumption and replay detection caches.
>>
>
> This question seems essentially orthogonal to the question of ECDHE ke= y
> reuse
> because even if you use the same ECDHE key in perpetuity you get uniqu= e
> traffic keying material for each connection.

Fair enough, I probably should've started a new thread so have
done that now.

S

>
> -Ekr
>
>
>> Cheers,
>> S.
>>
>>>
>>> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcu= ts=E2=80=9D, IMC 2016,
>>> pages 33=E2=80=9347, section 4.4. https://d= l.acm.org/citation.cfm?id=3D2987480
>>> [2] https://datatra= cker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/
>>>
>>>
>>> Cheers
>>>
>>> AGL
>>>
>>
>>
>> _______________________________________________
>> 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


--001a113e378861feb10544e0f422-- From nobody Fri Dec 30 06:44:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F05D31294B3 for ; Fri, 30 Dec 2016 06:44:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DfFDJpRGnARS for ; Fri, 30 Dec 2016 06:44:05 -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 91654124281 for ; Fri, 30 Dec 2016 06:44:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0EBFEBE2E; Fri, 30 Dec 2016 14:44:03 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 6jV6Etc-iU_i; Fri, 30 Dec 2016 14:43:56 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 62F6CBDF9; Fri, 30 Dec 2016 14:43:55 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483109035; bh=BaeKmhyudASDFEDUcHhqWFQkrE4yqJfFMCCMe1yaiq4=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=2Sxjh2qs8gaW06LITKByftSNl54yhH9vWL8dCjGKYg6mR6z+PMQhrdzisRIXB6WFL 7eMFrySdkn3s3luD755YdqimjWFr2CjsHp6MbkfMb7XhIMIn2W9AbCMWLdmWdIwYP3 GXwL1NtZ3Coubx2xLmgkr4DopD5vCiY6D55PFvuA= To: Eric Rescorla References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <96ff5e9c-8d13-0a97-50e4-370df680b40a@cs.tcd.ie> Date: Fri, 30 Dec 2016 14:43:55 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms080202040309080308050606" Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 14:44:08 -0000 This is a cryptographically signed message in MIME format. --------------ms080202040309080308050606 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 29/12/16 19:08, Eric Rescorla wrote: > On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell > wrote: >=20 >> >> >> On 29/12/16 18:38, Eric Rescorla wrote: >>> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie >>>> wrote: >>> >>>> >>>> Hiya, >>>> >>>> On 29/12/16 17:37, Adam Langley wrote: >>>>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that= >>>>> specifies that (EC)DH values must be fresh for both parties in TLS >>>>> 1.3. >>>>> >>>>> For clients, this is standard practice (as far as I'm aware) so sho= uld >>>>> make no difference. For servers, this is not always the case: >>>>> >>>>> Springall, Durumeric & Halderman note[1] that with TLS 1.2: >>>>> =E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do s= o for more >>>>> than a day. >>>>> =E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for more t= han a day. >>>> ... >>>> >>>> As an individual, I'd be in favour of this change but reading >>>> over [1], section 5, I wondered if we'd analysed the effects of >>>> 0rtt/replayable-data with that kind of cross-domain re-use in mind? >>>> The situation being where session ID based caches or session ticket >>>> equivalents in tls1.3 are shared over multiple domains. >>>> >>>> I don't recall this being explicitly considered, but maybe that's >>>> just me forgetting. And hopefully the analysis is that such re-use >>>> doesn't enable broader replay of early data, but there may be >>>> something worth a mention in the tls1.3 spec, e.g. that there may >>>> be linkages between the duration for which entries are maintained >>>> in resumption and replay detection caches. >>>> >>> >>> This question seems essentially orthogonal to the question of ECDHE k= ey >>> reuse >>> because even if you use the same ECDHE key in perpetuity you get uniq= ue >>> traffic keying material for each connection. >> >> Fair enough, I probably should've started a new thread so have >> done that now. >> >=20 > Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI change= s: > https://tlswg.github.io/tls13-spec/#NewSessionTicket What I'm wondering is if we're maybe missing a server-side check on that, with the possible attempted attack of a 0rtt replay in mind. E.g. a MUST check for the server that SNI is the same as for initial h/s before processing early data, (as is done for ALPN now) and/or some guidance about what might not be an obvious relationship between any 0rtt replay detection mechanisms and session ticket equivalents. >=20 > "Any ticket MUST only be resumed with a cipher suite that has the same = KDF > hash as that used to establish the original connection, and only if the= > client provides the same SNI value as in the original connection, as > described in Section 3 of [RFC6066] > ." >=20 > We have discussed relaxing that restriction, specifically to allow the > following case: >=20 > - Client connects to server with SNI=3DA and the server supplies a cert= with > SNI=3DA, B > - Client reconnects to server and tries to resume with SNI=3DB >=20 > See PR: https://github.com/tlswg/tls13-spec/pull/777. I'd wonder if that optimisation is really worthwhile, esp if it opens the door wider to 0rtt replay. (And it seems like it'd be somewhat complex to take advantage of the optimisation anyway.) >=20 > However, the general consensus was to leave this out of the base spec, Seems right. Cheers, S. > though we > might supply an enhancement for that later (and potentially slightly so= ften > the above > language to foreshadow such an enhancement). >=20 > -Ekr >=20 >=20 >=20 >> S >> >>> >>> -Ekr >>> >>> >>>> Cheers, >>>> S. >>>> >>>>> >>>>> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2= =80=9D, IMC 2016, >>>>> pages 33=E2=80=9347, section 4.4. https://dl.acm.org/citation.cfm?i= d=3D2987480 >>>>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh- >> in-tls13/ >>>>> >>>>> >>>>> Cheers >>>>> >>>>> AGL >>>>> >>>> >>>> >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>> >>>> >>> >> >> >=20 --------------ms080202040309080308050606 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMzAx NDQzNTVaMC8GCSqGSIb3DQEJBDEiBCAyB1U07AQ7gWa5Sz3R+Ufo3lTPD4sXK86CaCITDsBC yzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAwZHNj9vEfxAvQEw+/V0XcjJmfm1fqSr6KB/ext3k5t98Ngy9Ioq2m 62oAThILJWWlx4+58JAKd9LidL3A4lV3qMf+H0G6llWxrNZPX8z2ry87vbfYoqU0QN8GzgvQ 4TSRkzGZNS8vWYXrNDJXSGr1OUC5IpGKazqHngDfM97EbZWWh+0e2R+oEh59i1kBUiRURHr0 drCXIFnUq8Swcv6BP6QpfOkJCakjyfHU35B0NVtZ3OeLEfp9txirFFGgPTyfryLaCWfOSFFL RfiT8c+EtAxp1Sht1JMs8XgFEypkdSNDIZURMX/vM3WAHtLZqVqgYV4OO7q4xeythWqEvTZ+ AAAAAAAA --------------ms080202040309080308050606-- From nobody Fri Dec 30 08:15:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36873129539 for ; Fri, 30 Dec 2016 08:15:47 -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] 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 qKOxfmg9kBhF for ; Fri, 30 Dec 2016 08:15:39 -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 2E0711293F5 for ; Fri, 30 Dec 2016 08:15:39 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id a10so228532191ywa.3 for ; Fri, 30 Dec 2016 08:15:39 -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=k/teTKWYbuB7qbUfJ2puaTvNb7IuDqjUMZsZ2smd8QA=; b=u6/F29cRHIa21ZSb9TOHmgKokm8H/FhJxU4Jhjbmt3knAlNDdn9jkUnfw9r83Pe5kj lZPJ7T8VRAwda+iE2mASDKmo4n2ZfbbE/m+E0s694V49CczMCxBtXGV13BFSuhtzqAZZ a9Y5KGvFS10I3Qc3xaK/TlSfxYvoXBQCzMs58ospMhby/AilwIiIxf86X4zrBPWzWc9J Yss+Fu6egrBbhGXE8q/y4JKcD6BpHxnXbwigq/NQfsP6SlplDyLfhb6wS54tdKdP7sae BDKTcW4M5VTPaVS+8pZfx198loIjiXexJYC3B9T94oqqx7mtBbdF87wmMjX9qn6o8Pll vXmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=k/teTKWYbuB7qbUfJ2puaTvNb7IuDqjUMZsZ2smd8QA=; b=hDEdN/rW2kFRTO+29tzwAS5aP9/8g/11qVnKnEXegKSRT9O+TgcBCN3+6j366vACKC rUOjen8RQM2b/O6j/1/ddmhoILBJDDrDptVa3SHkqQIbZSnB34F7qAYWFy/zW7p2PJ+I dH3xndTP3qxSHAINAfIORLMyy59SHIVINkqiWTbuQyPXZoUa996kSHXjMtiVr+dEh4SC mV4y8SJ5Hzlgv1nztHqIdBAUARR/VhZO5SoxXJ5ruSw8wMT8tDnwUR82hWaryk0fA+7K c5dzDSyN1A/jxM0DSMlHqGKrWFq6QZd1iRdFl/eqORpqbsViEOi/eZB6hzABUuxqkfZP TsVg== X-Gm-Message-State: AIkVDXIShejU3mDdDqnnjKjwASTHsGNaOdGLWpezk7e4sZM4AkeBTCrWGs4xgv19xTNAIoIsWxxxPgBPwKwbxg== X-Received: by 10.129.78.71 with SMTP id c68mr41040905ywb.21.1483114538381; Fri, 30 Dec 2016 08:15:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Fri, 30 Dec 2016 08:14:57 -0800 (PST) In-Reply-To: <96ff5e9c-8d13-0a97-50e4-370df680b40a@cs.tcd.ie> References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> <96ff5e9c-8d13-0a97-50e4-370df680b40a@cs.tcd.ie> From: Eric Rescorla Date: Fri, 30 Dec 2016 08:14:57 -0800 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a114dac9c3909430544e28306 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 16:15:47 -0000 --001a114dac9c3909430544e28306 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell wrote: > > Hiya, > > On 29/12/16 19:08, Eric Rescorla wrote: > > On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie > >> wrote: > > > >> > >> > >> On 29/12/16 18:38, Eric Rescorla wrote: > >>> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell < > >> stephen.farrell@cs.tcd.ie > >>>> wrote: > >>> > >>>> > >>>> Hiya, > >>>> > >>>> On 29/12/16 17:37, Adam Langley wrote: > >>>>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > >>>>> specifies that (EC)DH values must be fresh for both parties in TLS > >>>>> 1.3. > >>>>> > >>>>> For clients, this is standard practice (as far as I'm aware) so > should > >>>>> make no difference. For servers, this is not always the case: > >>>>> > >>>>> Springall, Durumeric & Halderman note[1] that with TLS 1.2: > >>>>> =E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do s= o for more > >>>>> than a day. > >>>>> =E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for more t= han a day. > >>>> ... > >>>> > >>>> As an individual, I'd be in favour of this change but reading > >>>> over [1], section 5, I wondered if we'd analysed the effects of > >>>> 0rtt/replayable-data with that kind of cross-domain re-use in mind? > >>>> The situation being where session ID based caches or session ticket > >>>> equivalents in tls1.3 are shared over multiple domains. > >>>> > >>>> I don't recall this being explicitly considered, but maybe that's > >>>> just me forgetting. And hopefully the analysis is that such re-use > >>>> doesn't enable broader replay of early data, but there may be > >>>> something worth a mention in the tls1.3 spec, e.g. that there may > >>>> be linkages between the duration for which entries are maintained > >>>> in resumption and replay detection caches. > >>>> > >>> > >>> This question seems essentially orthogonal to the question of ECDHE k= ey > >>> reuse > >>> because even if you use the same ECDHE key in perpetuity you get uniq= ue > >>> traffic keying material for each connection. > >> > >> Fair enough, I probably should've started a new thread so have > >> done that now. > >> > > > > Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI change= s: > > https://tlswg.github.io/tls13-spec/#NewSessionTicket > > What I'm wondering is if we're maybe missing a server-side check > on that, with the possible attempted attack of a 0rtt replay in > mind. E.g. a MUST check for the server that SNI is the same as for > initial h/s before processing early data, (as is done for ALPN now) > and/or some guidance about what might not be an obvious relationship > between any 0rtt replay detection mechanisms and session ticket > equivalents I believe that the text I quote below already requires that check. The reason it's there and not in the 0-RTT text is that it is a requirement on resumption which itself is a requirement for 0-RTT. The ALPN check is an explicit 0-RT= T requirement but not a resumption requirement. I.e., Can resume only if SNI is equal Can accept 0-RTT only if (resumed && ALPN is equal) -Ekr > "Any ticket MUST only be resumed with a cipher suite that has the same KD= F > > hash as that used to establish the original connection, and only if the > > client provides the same SNI value as in the original connection, as > > described in Section 3 of [RFC6066] > > ." > > > > We have discussed relaxing that restriction, specifically to allow the > > following case: > > > > - Client connects to server with SNI=3DA and the server supplies a cert > with > > SNI=3DA, B > > - Client reconnects to server and tries to resume with SNI=3DB > > > > See PR: https://github.com/tlswg/tls13-spec/pull/777. > > I'd wonder if that optimisation is really worthwhile, esp if it > opens the door wider to 0rtt replay. (And it seems like it'd be > somewhat complex to take advantage of the optimisation anyway.) > > > > > However, the general consensus was to leave this out of the base spec, > > Seems right. > > Cheers, > S. > > > though we > > might supply an enhancement for that later (and potentially slightly > soften > > the above > > language to foreshadow such an enhancement). > > > > -Ekr > > > > > > > >> S > >> > >>> > >>> -Ekr > >>> > >>> > >>>> Cheers, > >>>> S. > >>>> > >>>>> > >>>>> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2= =80=9D, IMC 2016, > >>>>> pages 33=E2=80=9347, section 4.4. https://dl.acm.org/citation.cfm?i= d=3D2987480 > >>>>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh- > >> in-tls13/ > >>>>> > >>>>> > >>>>> Cheers > >>>>> > >>>>> AGL > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> TLS mailing list > >>>> TLS@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tls > >>>> > >>>> > >>> > >> > >> > > > > --001a114dac9c3909430544e28306 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya,

On 29/12/16 19:08, Eric Rescorla wrote:
> On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie
>> wrote:
>
>>
>>
>> On 29/12/16 18:38, Eric Rescorla wrote:
>>> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell <
>> stephen.farrell@cs.tc= d.ie
>>>> wrote:
>>>
>>>>
>>>> Hiya,
>>>>
>>>> On 29/12/16 17:37, Adam Langley wrote:
>>>>> https://github.com/tlswg/tls13= -spec/pull/840 is a pull request that
>>>>> specifies that (EC)DH values must be fresh for both pa= rties in TLS
>>>>> 1.3.
>>>>>
>>>>> For clients, this is standard practice (as far as I= 9;m aware) so should
>>>>> make no difference. For servers, this is not always th= e case:
>>>>>
>>>>> Springall, Durumeric & Halderman note[1] that with= TLS 1.2:
>>>>>=C2=A0 =C2=A0=E2=88=99 4.4% of the Alexa Top 1M reuse D= HE values and 1.3% do so for more
>>>>>=C2=A0 =C2=A0 =C2=A0than a day.
>>>>>=C2=A0 =C2=A0=E2=88=99 14.4% of the Top 1M reuse ECDHE = values, 3.4% for more than a day.
>>>> ...
>>>>
>>>> As an individual, I'd be in favour of this change but = reading
>>>> over [1], section 5, I wondered if we'd analysed the e= ffects of
>>>> 0rtt/replayable-data with that kind of cross-domain re-use= in mind?
>>>> The situation being where session ID based caches or sessi= on ticket
>>>> equivalents in tls1.3 are shared over multiple domains. >>>>
>>>> I don't recall this being explicitly considered, but m= aybe that's
>>>> just me forgetting. And hopefully the analysis is that suc= h re-use
>>>> doesn't enable broader replay of early data, but there= may be
>>>> something worth a mention in the tls1.3 spec, e.g. that th= ere may
>>>> be linkages between the duration for which entries are mai= ntained
>>>> in resumption and replay detection caches.
>>>>
>>>
>>> This question seems essentially orthogonal to the question of = ECDHE key
>>> reuse
>>> because even if you use the same ECDHE key in perpetuity you g= et unique
>>> traffic keying material for each connection.
>>
>> Fair enough, I probably should've started a new thread so have=
>> done that now.
>>
>
> Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI chang= es:
> https://tlswg.github.io/tls13-spec/#= NewSessionTicket

What I'm wondering is if we're maybe missing a server-side check on that, with the possible attempted attack of a 0rtt replay in
mind. E.g. a MUST check for the server that SNI is the same as for
initial h/s before processing early data, (as is done for ALPN now)
and/or some guidance about what might not be an obvious relationship
between any 0rtt replay detection mechanisms and session ticket
equivalents

I believe that the text I quote= below already requires that check. The reason
it's there and= not in the 0-RTT text is that it is a requirement on resumption
= which itself is a requirement for 0-RTT. The ALPN check is an explicit 0-RT= T
requirement but not a resumption requirement.

I.e.,
Can resume only if SNI is equal
Can accep= t 0-RTT only if (resumed && ALPN is equal)

-Ekr



> "Any ticket MUST only be resumed with a cipher suite that has the= same KDF
> hash as that used to establish the original connection, and only if th= e
> client provides the same SNI value as in the original connection, as > described in Section 3 of [RFC6066]
> <https://tlswg.github.io/tls13-spec/#RFC6066= >."
>
> We have discussed relaxing that restriction, specifically to allow the=
> following case:
>
> - Client connects to server with SNI=3DA and the server supplies a cer= t with
> SNI=3DA, B
> - Client reconnects to server and tries to resume with SNI=3DB
>
> See PR: https://github.com/tlswg/tls13-spec/= pull/777.

I'd wonder if that optimisation is really worthwhile, esp if it
opens the door wider to 0rtt replay. (And it seems like it'd be
somewhat complex to take advantage of the optimisation anyway.)

>
> However, the general consensus was to leave this out of the base spec,=

Seems right.

Cheers,
S.

> though we
> might supply an enhancement for that later (and potentially slightly s= often
> the above
> language to foreshadow such an enhancement).
>
> -Ekr
>
>
>
>> S
>>
>>>
>>> -Ekr
>>>
>>>
>>>> Cheers,
>>>> S.
>>>>
>>>>>
>>>>> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto= Shortcuts=E2=80=9D, IMC 2016,
>>>>> pages 33=E2=80=9347, section 4.4. h= ttps://dl.acm.org/citation.cfm?id=3D2987480
>>>>> [2] https://datatrac= ker.ietf.org/doc/draft-green-tls-static-dh-
>> in-tls13/
>>>>>
>>>>>
>>>>> Cheers
>>>>>
>>>>> AGL
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> https://www.ietf.org/mailman/listinf= o/tls
>>>>
>>>>
>>>
>>
>>
>


--001a114dac9c3909430544e28306-- From nobody Fri Dec 30 08:17:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02CEF12950A for ; Fri, 30 Dec 2016 08:17:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfsBgjKDhLjN for ; Fri, 30 Dec 2016 08:17:16 -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 719A41294BD for ; Fri, 30 Dec 2016 08:17:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id C131BBDF9; Fri, 30 Dec 2016 16:17:13 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 KO8oG_c3pWcj; Fri, 30 Dec 2016 16:17:06 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0A84FBDCC; Fri, 30 Dec 2016 16:17:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483114626; bh=ib5WsfsdJsdLy0w0YW1qiu7gz/DXF0AnOgkDkgH/YMw=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=RUk8zhandIRwHJgAO58oSjy8NKJv5GIFTYtJmxqqlLdY7W3B1HwgTvAwiJlmLxplw MORO1Lxk5sxwYIRlm6WbpQPQXkqvhBkK5CnIFX92FsW4oPlKF8M2tcunLpF0zHOBMU 6YEK8k2YqVI88kGmpytHiY4csSDnHuCdqAnNPIEg= To: Eric Rescorla References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> <96ff5e9c-8d13-0a97-50e4-370df680b40a@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <20b97648-ed16-d042-c6c9-eabdb1b1cf33@cs.tcd.ie> Date: Fri, 30 Dec 2016 16:17:05 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030801030503020404080507" Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 16:17:19 -0000 This is a cryptographically signed message in MIME format. --------------ms030801030503020404080507 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 30/12/16 16:14, Eric Rescorla wrote: > On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> On 29/12/16 19:08, Eric Rescorla wrote: >>> On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie >>>> wrote: >>> >>>> >>>> >>>> On 29/12/16 18:38, Eric Rescorla wrote: >>>>> On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell < >>>> stephen.farrell@cs.tcd.ie >>>>>> wrote: >>>>> >>>>>> >>>>>> Hiya, >>>>>> >>>>>> On 29/12/16 17:37, Adam Langley wrote: >>>>>>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request th= at >>>>>>> specifies that (EC)DH values must be fresh for both parties in TL= S >>>>>>> 1.3. >>>>>>> >>>>>>> For clients, this is standard practice (as far as I'm aware) so >> should >>>>>>> make no difference. For servers, this is not always the case: >>>>>>> >>>>>>> Springall, Durumeric & Halderman note[1] that with TLS 1.2: >>>>>>> =E2=88=99 4.4% of the Alexa Top 1M reuse DHE values and 1.3% do= so for more >>>>>>> than a day. >>>>>>> =E2=88=99 14.4% of the Top 1M reuse ECDHE values, 3.4% for more= than a day. >>>>>> ... >>>>>> >>>>>> As an individual, I'd be in favour of this change but reading >>>>>> over [1], section 5, I wondered if we'd analysed the effects of >>>>>> 0rtt/replayable-data with that kind of cross-domain re-use in mind= ? >>>>>> The situation being where session ID based caches or session ticke= t >>>>>> equivalents in tls1.3 are shared over multiple domains. >>>>>> >>>>>> I don't recall this being explicitly considered, but maybe that's >>>>>> just me forgetting. And hopefully the analysis is that such re-use= >>>>>> doesn't enable broader replay of early data, but there may be >>>>>> something worth a mention in the tls1.3 spec, e.g. that there may >>>>>> be linkages between the duration for which entries are maintained >>>>>> in resumption and replay detection caches. >>>>>> >>>>> >>>>> This question seems essentially orthogonal to the question of ECDHE= key >>>>> reuse >>>>> because even if you use the same ECDHE key in perpetuity you get un= ique >>>>> traffic keying material for each connection. >>>> >>>> Fair enough, I probably should've started a new thread so have >>>> done that now. >>>> >>> >>> Currently TLS 1.3 forbids *both* 0-RTT and resumption if the SNI chan= ges: >>> https://tlswg.github.io/tls13-spec/#NewSessionTicket >> >> What I'm wondering is if we're maybe missing a server-side check >> on that, with the possible attempted attack of a 0rtt replay in >> mind. E.g. a MUST check for the server that SNI is the same as for >> initial h/s before processing early data, (as is done for ALPN now) >> and/or some guidance about what might not be an obvious relationship >> between any 0rtt replay detection mechanisms and session ticket >> equivalents >=20 >=20 > I believe that the text I quote below already requires that check. The > reason > it's there and not in the 0-RTT text is that it is a requirement on > resumption > which itself is a requirement for 0-RTT. The ALPN check is an explicit = 0-RTT > requirement but not a resumption requirement. >=20 > I.e., > Can resume only if SNI is equal > Can accept 0-RTT only if (resumed && ALPN is equal) Fair enough. I didn't read enough text to get that clearly I guess, which is my fault:-) Thanks, S. >=20 > -Ekr >=20 >=20 >=20 >> "Any ticket MUST only be resumed with a cipher suite that has the same= KDF >>> hash as that used to establish the original connection, and only if t= he >>> client provides the same SNI value as in the original connection, as >>> described in Section 3 of [RFC6066] >>> ." >>> >>> We have discussed relaxing that restriction, specifically to allow th= e >>> following case: >>> >>> - Client connects to server with SNI=3DA and the server supplies a ce= rt >> with >>> SNI=3DA, B >>> - Client reconnects to server and tries to resume with SNI=3DB >>> >>> See PR: https://github.com/tlswg/tls13-spec/pull/777. >> >> I'd wonder if that optimisation is really worthwhile, esp if it >> opens the door wider to 0rtt replay. (And it seems like it'd be >> somewhat complex to take advantage of the optimisation anyway.) >> >>> >>> However, the general consensus was to leave this out of the base spec= , >> >> Seems right. >> >> Cheers, >> S. >> >>> though we >>> might supply an enhancement for that later (and potentially slightly >> soften >>> the above >>> language to foreshadow such an enhancement). >>> >>> -Ekr >>> >>> >>> >>>> S >>>> >>>>> >>>>> -Ekr >>>>> >>>>> >>>>>> Cheers, >>>>>> S. >>>>>> >>>>>>> >>>>>>> [1] =E2=80=9CMeasuring the Security Harm of TLS Crypto Shortcuts=E2= =80=9D, IMC 2016, >>>>>>> pages 33=E2=80=9347, section 4.4. https://dl.acm.org/citation.cfm= ?id=3D2987480 >>>>>>> [2] https://datatracker.ietf.org/doc/draft-green-tls-static-dh- >>>> in-tls13/ >>>>>>> >>>>>>> >>>>>>> Cheers >>>>>>> >>>>>>> AGL >>>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> TLS mailing list >>>>>> TLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>> >>>>>> >>>>> >>>> >>>> >>> >> >> >=20 --------------ms030801030503020404080507 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMzAx NjE3MDVaMC8GCSqGSIb3DQEJBDEiBCB+7WB4Boe+lA4G5YS7URvzTC0AuKAqNkZRK2HAQjt8 nTBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCimxMdJTD9koqvt54tLbrAYIahEaPqjqCrUhhsRfJ/NE28JkQowblj ewLJ0/rBjEPFBKT2MkB+wQBLwR2Fl1n7AEoXtNigDfneDztoG0UuxjmAxDJeCLo0UgpCHvOI 02omoGxqzcS5zZ12CazH8Xq2rQD+1ZdqrJ2sM8fiLUOxmzdbyDcSkRCFZDKgAF6mv+LeWxp0 aCeC844bKABbkhshuOfnIP64/9Lp5kFKiCj7Yn1XYvK5cmP5yD/I8SwJi8jpMkXx4ZEwnuVn TVbZ+QtGK4xFuRG366cdcRU7YVBzamw1/niswNoldC8TKM98PbCDV2D7vNwZWmUkaQme+oq/ AAAAAAAA --------------ms030801030503020404080507-- From nobody Fri Dec 30 09:21:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A781312941E for ; Fri, 30 Dec 2016 09:21:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5 X-Spam-Level: X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.1] 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 pksFxflHIJ7s for ; Fri, 30 Dec 2016 09:21:48 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id BE7A0128AC9 for ; Fri, 30 Dec 2016 09:21:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 37E7F18FC7; Fri, 30 Dec 2016 19:21:47 +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 k9VrJ-LTB3ys; Fri, 30 Dec 2016 19:21:46 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 8AF0CC4; Fri, 30 Dec 2016 19:21:46 +0200 (EET) Date: Fri, 30 Dec 2016 19:21:36 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20161230172135.GA11298@LK-Perkele-V2.elisa-laajakaista.fi> References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> <96ff5e9c-8d13-0a97-50e4-370df680b40a@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 17:21:50 -0000 On Fri, Dec 30, 2016 at 08:14:57AM -0800, Eric Rescorla wrote: > On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell > wrote: > > > > What I'm wondering is if we're maybe missing a server-side check > > on that, with the possible attempted attack of a 0rtt replay in > > mind. E.g. a MUST check for the server that SNI is the same as for > > initial h/s before processing early data, (as is done for ALPN now) > > and/or some guidance about what might not be an obvious relationship > > between any 0rtt replay detection mechanisms and session ticket > > equivalents > > > I believe that the text I quote below already requires that check. The > reason > it's there and not in the 0-RTT text is that it is a requirement on > resumption > which itself is a requirement for 0-RTT. The ALPN check is an explicit 0-RTT > requirement but not a resumption requirement. > > I.e., > Can resume only if SNI is equal > Can accept 0-RTT only if (resumed && ALPN is equal) Actually, AFAICT all types of PSKs can be used for 0-RTT if all the needed data is provisioned. But AFAICT only dynamically provisioned PSKs have SNI requirements. So statically provisioned ("external") PSKs AFAICT can do 0-RTT across SNI values. -Ilari From nobody Fri Dec 30 09:57:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5853129451 for ; Fri, 30 Dec 2016 09:57:00 -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 UZ3XioyN1CtB for ; Fri, 30 Dec 2016 09:56:59 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93E0C129407 for ; Fri, 30 Dec 2016 09:56:59 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id a10so230147399ywa.3 for ; Fri, 30 Dec 2016 09:56:59 -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=JRyAp2JFvPaZra0s7yeowYMPepPYtZKuTcsOlNWh5cI=; b=BZEyT7LPpPzy3wTrCDkMHWfbtga13TsTJrOeodimiA8CX+FVK+lxRObf5KMLkzzqtD mKbVYqPlh71xHNTYyIca1TBXsMbkPSLldhUmxToB7gEZir8eo2LHUjdIfV60Msj/H4T5 DBJDQ2Pgvq6JKc/Du5Mrl8mo2VEvn6/5ZdS7BeWD7eKz0jAsRRrkBzuI0EZt3lIebN4K QumiLt/J3m4CuIj5BKfZO/SaZzg4D7NJaAnkjC6VYfnqMZzRUlPZd2uujHZXwOKMg6gz 7O9XSs7vnagSqm2jRfmLBG6iuym+//vLTiOfHWFKb2wig4yKZXENf+XOgtzLPB0J09AP EOYg== 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=JRyAp2JFvPaZra0s7yeowYMPepPYtZKuTcsOlNWh5cI=; b=kMqKhuzY7Re7rJSZYGAKB5v12EWFmNpXEXjTtbFs8AzQI0hcIg7mUkXM0R1TCN9p++ H+IfD8qZO1FAFAl1ssXQBUJlwoJpRWnlqebx+Rp/ZZsnwQCm6wXbABMldUzc0ATzV7P+ X0O3h4Y5j5tDW7ownseVIW1sv3uwtHkJ/F6sjypDigLu/QVaHjqbAKe6Gfk+nxo6hS3f 6x9FD6pxu/vfLfjijsAyMdbmI7/tsfe4iYAJ9AOp8RaHSZCJIOi2M5o6IonX0u7Laz1r V+l6lIfnYGaiZPlI4+18dKKRBOUzupt4mzoVesKQ00LE0e3CjR3CXZchOFKfUKkX3crs +vbQ== X-Gm-Message-State: AIkVDXLgy9y/Nnx2kqTkVvj23RDOYL9ILPuj1ZYRnXS6UccNaCz/HHobEbd2kVdrZbZLiCNuBs22aS6/UlWoLA== X-Received: by 10.129.125.215 with SMTP id y206mr40016598ywc.234.1483120618866; Fri, 30 Dec 2016 09:56:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Fri, 30 Dec 2016 09:56:18 -0800 (PST) In-Reply-To: <20161230172135.GA11298@LK-Perkele-V2.elisa-laajakaista.fi> References: <79db4a88-e435-2e5b-47a5-9048acef45e2@cs.tcd.ie> <582703ab-4340-35e7-a3d2-45dd606f10a1@cs.tcd.ie> <96ff5e9c-8d13-0a97-50e4-370df680b40a@cs.tcd.ie> <20161230172135.GA11298@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 30 Dec 2016 09:56:18 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a11492dfaa5baa20544e3ed6d Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] cross-domain cache sharing and 0rtt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 17:57:01 -0000 --001a11492dfaa5baa20544e3ed6d Content-Type: text/plain; charset=UTF-8 On Fri, Dec 30, 2016 at 9:21 AM, Ilari Liusvaara wrote: > On Fri, Dec 30, 2016 at 08:14:57AM -0800, Eric Rescorla wrote: > > On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > > > > What I'm wondering is if we're maybe missing a server-side check > > > on that, with the possible attempted attack of a 0rtt replay in > > > mind. E.g. a MUST check for the server that SNI is the same as for > > > initial h/s before processing early data, (as is done for ALPN now) > > > and/or some guidance about what might not be an obvious relationship > > > between any 0rtt replay detection mechanisms and session ticket > > > equivalents > > > > > > I believe that the text I quote below already requires that check. The > > reason > > it's there and not in the 0-RTT text is that it is a requirement on > > resumption > > which itself is a requirement for 0-RTT. The ALPN check is an explicit > 0-RTT > > requirement but not a resumption requirement. > > > > I.e., > > Can resume only if SNI is equal > > Can accept 0-RTT only if (resumed && ALPN is equal) > > Actually, AFAICT all types of PSKs can be used for 0-RTT if all the > needed data is provisioned. But AFAICT only dynamically provisioned > PSKs have SNI requirements. > > So statically provisioned ("external") PSKs AFAICT can do 0-RTT across > SNI values. > Yes, I think that would be permitted by this text, though that's just a result of bad writing, which would be resolved by saying that you must only accept a PSK (rather than resume) if the SNIs are equal. -Ekr > > > > -Ilari > --001a11492dfaa5baa20544e3ed6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Dec 30, 2016 at 9:21 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
O= n Fri, Dec 30, 2016 at 08:14:57AM -0800, Eric Rescorla wrote:
> On Fri, Dec 30, 2016 at 6:43 AM, Stephen Farrell <stephen.farrell@cs.tcd.ie= >
> wrote:
> >
> > What I'm wondering is if we're maybe missing= a server-side check
> > on that, with the possible attempted attack of a 0rtt replay in > > mind. E.g. a MUST check for the server that SNI is the same as fo= r
> > initial h/s before processing early data, (as is done for ALPN no= w)
> > and/or some guidance about what might not be an obvious relations= hip
> > between any 0rtt replay detection mechanisms and session ticket > > equivalents
>
>
> I believe that the text I quote below already requires that check. The=
> reason
> it's there and not in the 0-RTT text is that it is a requirement o= n
> resumption
> which itself is a requirement for 0-RTT. The ALPN check is an explicit= 0-RTT
> requirement but not a resumption requirement.
>
> I.e.,
> Can resume only if SNI is equal
> Can accept 0-RTT only if (resumed && ALPN is equal)

Actually, AFAICT all types of PSKs can be used for 0-RTT if all the<= br> needed data is provisioned. But AFAICT only dynamically provisioned
PSKs have SNI requirements.

So statically provisioned ("external") PSKs AFAICT can do 0-RTT a= cross
SNI values.

Yes, I think that would be = permitted by this text, though that's just a result of bad writing,
which would be resolved by saying that you must only accept a PSK (r= ather than
resume) if the SNIs are equal.

-Ekr
=C2=A0



-Ilari

--001a11492dfaa5baa20544e3ed6d-- From nobody Fri Dec 30 11:42:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2FFC12949E for ; Fri, 30 Dec 2016 11:42:04 -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 T6Dnlfm4n3ng for ; Fri, 30 Dec 2016 11:42:03 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAEA5129494 for ; Fri, 30 Dec 2016 11:42:03 -0800 (PST) Received: from [47.143.125.15] (helo=Williams-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1cN33d-0006ko-DY; Fri, 30 Dec 2016 14:41:41 -0500 Date: Fri, 30 Dec 2016 11:41:41 -0800 From: Bill Frantz To: Stephen Farrell X-Priority: 3 In-Reply-To: <20b97648-ed16-d042-c6c9-eabdb1b1cf33@cs.tcd.ie> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79519b1c7a722695a0dff17b1ecee01ecc350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.15 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] cross-domain cache sharing and 0rtt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 19:42:05 -0000 On 12/30/16 at 8:17 AM, stephen.farrell@cs.tcd.ie (Stephen Farrell) wrote: > Fair enough. I didn't read enough text to get that clearly > I guess, which is my fault:-) If you didn't read enough, is this a mistake that implementer's are likely = to make? Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | "The only thing we have to | Periwinkle (408)356-8506 | fear is fear itself." - FDR | 16345 Englewood Ave www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos, CA 95032 From nobody Fri Dec 30 11:53:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76A6C12940B for ; Fri, 30 Dec 2016 11:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.401 X-Spam-Level: X-Spam-Status: No, score=-7.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTdOSJv_bV7s for ; Fri, 30 Dec 2016 11:53:16 -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 5C40E129483 for ; Fri, 30 Dec 2016 11:53:15 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 338C2BE2C; Fri, 30 Dec 2016 19:53:12 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 S6U-NqMcHC_y; Fri, 30 Dec 2016 19:53:10 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 72391BDCC; Fri, 30 Dec 2016 19:53:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1483127590; bh=HGFZpc/Bd+OZc3cUdU+I7gSe0xup800uBxXyNFpvIqo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=kq3F85HzzSf4S3nib7ubppwp5coBpEvRD9Dap0I3TSzkoM5G6NJyxnypT+ErH+3eY /Tdzj8njwOe7ZBCVywe3CAuW8VFM2gWN6j/HnZXs0M5XzHWbBrgBdw4yGa0ga7WlYm Fv7mndZfnSJShZ219XeqSTCpH26Gzu6wXsUCtPo0= To: Bill Frantz References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Fri, 30 Dec 2016 19:53:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090004050001030106080302" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] cross-domain cache sharing and 0rtt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Dec 2016 19:53:18 -0000 This is a cryptographically signed message in MIME format. --------------ms090004050001030106080302 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 30/12/16 19:41, Bill Frantz wrote: > On 12/30/16 at 8:17 AM, stephen.farrell@cs.tcd.ie (Stephen Farrell) wro= te: >=20 >> Fair enough. I didn't read enough text to get that clearly >> I guess, which is my fault:-) >=20 > If you didn't read enough, is this a mistake that implementer's are lik= ely to make? >=20 Not sure tbh - I've not given the draft a full read-through for ages so it could well just be me. But I will give it a full read as part of my AD review once the WGLC is done and will watch out for this. Cheers, S. > Cheers - Bill >=20 > -----------------------------------------------------------------------= > Bill Frantz | "The only thing we have to | Periwinkle > (408)356-8506 | fear is fear itself." - FDR | 16345 Englewood Ave= > www.pwpconsult.com | Inaugural address, 3/4/1933 | Los Gatos, CA 95032= >=20 >=20 --------------ms090004050001030106080302 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjEyMzAx OTUzMTBaMC8GCSqGSIb3DQEJBDEiBCAVo0LBneXbUHTPwmwGipw8OFHgFkab4U0xRCMHvGe/ HjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBCUeDixkGgwNCu8DsnhQmGf5knSmq56i8J38ehx1V8vbBkTj68kiUK ovA5IpSxqy1sgbWnH8/uf7wbmHSq4R0XRsO+mpjUy0T+858kPx8EKA1Hb/9hNHN86vmPdqLC FqTY9iiRRNXVp9Ffvz3ttqUw5hbMlqW4htGQa9wSNEkKm7Sb/A76y6mZNBr7pr741qPnVV4P e5/kFWErokVwWSeWKzqNUzX77uzbQSyb7hje0rKfvkacg6EN4Jjq87KVeS1WFutIoaRsnMjC EXNqzdI1FIdrJQ/8PYIHKySTnQrQr4U38bVRELY9Lyzs6j+2PWjqMFzStVjnYLk/TlOs/5p+ AAAAAAAA --------------ms090004050001030106080302-- From nobody Sat Dec 31 07:29:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDD781293FE for ; Sat, 31 Dec 2016 07:29:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.8 X-Spam-Level: X-Spam-Status: No, score=-5.8 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, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rrHfMYGarlX6 for ; Sat, 31 Dec 2016 07:29:33 -0800 (PST) Received: from resqmta-ch2-04v.sys.comcast.net (resqmta-ch2-04v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:36]) (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 0BDE4124281 for ; Sat, 31 Dec 2016 07:29:32 -0800 (PST) Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-04v.sys.comcast.net with SMTP id NLaqcOfr5GIgtNLbAczznO; Sat, 31 Dec 2016 15:29:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20161114; t=1483198172; bh=UiRIEG+pzeduOrhOBRqcVDXFVIKoxqX/MFb1BhCunNw=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=FJlPIKA2Bdr6Qv8izwNCR4pZhIp239Q3ftYs3HdoCIDFl98iUMYF1VORNTYVbddew HCmelQs5lrAajP+/Uab1ubfhuakUbEE08HvSvORuDB/qzHAldCdLStJ6qNLbRKSZOh 6r7QoEzdQgfXvqiyxy+lf442Q2QIFbh0V38PypkNdPCrCB+DDVUfsYh6CPSdu8Q7sN cASOwI8caOAENF9my4ItyU7G0ezy2C7+HBHuUphO5d/O3ZH31QBeM+QYvfPcX+L6Ec yQRmnDbp/EsxN1ffE3YBI1rWZKwhtrzmzeI9XvAQj5dC10xzYoZUzw/oDpuzbMLpVl zLNn9uy2SuvRA== Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-ch2-19v.sys.comcast.net with SMTP id NLazc7QXcJrRENLb3c9fqU; Sat, 31 Dec 2016 15:29:30 +0000 Received: from odin.ulthar.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id uBVFTJCm023953 for ; Sat, 31 Dec 2016 10:29:19 -0500 Received: (from draco@localhost) by odin.ulthar.us (8.15.2/8.15.2/Submit) id uBVFTJEm023952 for tls@ietf.org; Sat, 31 Dec 2016 10:29:19 -0500 Date: Sat, 31 Dec 2016 10:29:19 -0500 From: Scott Schmit To: tls@ietf.org Message-ID: <20161231152919.GA23861@odin.ULTHAR.us> References: <20161229192845.201121A5D4@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161229192845.201121A5D4@ld9781.wdf.sap.corp> User-Agent: Mutt/1.7.1 (2016-10-04) X-CMAE-Envelope: MS4wfEco9Qz6lFabgZO7cBeVPBPfimCt/mXxFP6dOjZ8nUYEzglO4Pm8ygvPmCDmXsKDa66E11U33jdeOU0MsKPIH5gDcCctX8xmwZ5a39kutiAiE1uACggy v17caNf4gWv2E7E8doD+JIwBPMFTiab+uOo= Archived-At: Subject: Re: [TLS] Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 15:29:34 -0000 On Thu, Dec 29, 2016 at 08:28:45PM +0100, Martin Rex wrote: > Adam Langley wrote: > > Since this defeats forward security, and is clearly something that > > implementations of previous versions have done, this change > > specifically calls it out as a MUST NOT. Implementations would then be > > free to detect and reject violations of this. > > While you may have good intentions, the idea "and reject violations of this" > sounds like a bad idea to me. > > Now what does it mean when a _client_ that happens to connect to one > of these 14.4% Alexa top 1M sites that reuse ECDHE values, notices a > reuse of ECDHE on a repeated full handshake (which will not happen > immediately due to session caching&resumption). This would result > is random handshake failures (client aborting the TLS handshake). > The server doesn't know why the client chokes, only the client can > decided to retry, but this is unlikely to affect the servers approach > to reusing the (EC)DHE value at all. > > > So the only thing this will cause is headaches to users and support > folks. It will *NOT* improve the security by one iota. If we add an alert to be sent in this case, it would be possible for the server to know why the clients were disconnecting and resolve the issue. -- Scott Schmit From nobody Sat Dec 31 10:36:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD7D129556 for ; Sat, 31 Dec 2016 10:36: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, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 Maw9Pg3fpg3F for ; Sat, 31 Dec 2016 10:36:14 -0800 (PST) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 275BE12944B for ; Sat, 31 Dec 2016 10:36:14 -0800 (PST) Received: by mail-io0-x244.google.com with SMTP id m204so18628521ioe.3 for ; Sat, 31 Dec 2016 10:36:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=y1xnJq5lDgIC4dNNYSWaj1B/IW3I7+rjlT0HcUb99+I=; b=gWXFMSerK7JMQaEdqjJ6tziSiJqPIGYeVYb7/HSKVCTxu5S6ZZVsz7idiSi7/2LX1q 0sUmA9/2rry1X2KfqrpPRhvgpNw1shDmzJcTcDNbn6f7u2qbNrOxPuA58Iru2QBttqJU xIozBwoZ8mgrvBGP3wE5U0LVzkgUxBtu8a6uFQAWM50dbQcA661CRpuioWTd3GAhZNVN /9QKKuCz6WtJk7qrnbtCuam7xhxM3sbmtJIZU8kmdmDLwhdVf0jbDNzLDZhEhTkx0SWa aUVVFfyz0mi0QDLDzoLCvalrT1qVQwiao3XYxa9JEgPsWiSQM9W8YYN0KxaPA/fNN9L3 wg3A== 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:content-transfer-encoding; bh=y1xnJq5lDgIC4dNNYSWaj1B/IW3I7+rjlT0HcUb99+I=; b=rspm4qL8Sm1ckV31p8QR0lNtoB/JtcBXGNgUbnya8j2IQemLE607ZURIAHQLLhR5+0 dQOBbcfJNQ+BXiuJ/xTY4PK0SGH8MZRCa50sLtXJ5SLYgRWm1kWw+E03dvSdX7A/DQOp N1EQ3SVfpLXDiATY7B804FuA5p/dinsq0A+Oxl4jojYLc3GcQWoSIpDaN2Ttjd/uritL /CLyUe4yf/Lyms/PKfIYiwCvKDoIxly+vYN2CRbMewbYO6XEU5dpZOHl1H5PAz1bxYlf 9P3KaIXhkquqaR4w9jbyeFrl262Kltux63cKorwiDwSG/j5y1JqJtjrPxDgo24MZmpzj 2Qmw== X-Gm-Message-State: AIkVDXKfFRZVTtfxVwcgIEcQ7UTzMi10sMECH6G7aRfAj45Hi/Nv1ra12ovPRfqLbyV6kLD+zpUttB+kWprwuw== X-Received: by 10.107.134.131 with SMTP id q3mr31418359ioi.168.1483209373100; Sat, 31 Dec 2016 10:36:13 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.27.136 with HTTP; Sat, 31 Dec 2016 10:36:12 -0800 (PST) In-Reply-To: References: From: Adam Langley Date: Sat, 31 Dec 2016 10:36:12 -0800 X-Google-Sender-Auth: wlGbgEMewHSL2_iVaZ7mpI7rcAw Message-ID: To: Brian Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Requiring that (EC)DHE public values be fresh X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Dec 2016 18:36:16 -0000 (Note: I'm reordering Brian's paragraphs here so that I can address all of those on a single topic at a time.) On Thu, Dec 29, 2016 at 4:29 PM, Brian Smith wrote: > It would make self-hosting a small that can survive a spike in traffic > ("slashdot effect") more difficult, thus encouraging sites to use > CDNs, which decrease the integrity, confidentiality, and privacy > properties of all connections between the client and the origin > server. Unfortunately I don't know how to quantify that. > > Another unintended consequence is that it makes the PSK modes > relatively more attractive. For some very small devices doing ECDH > agreement on every connection and only doing a occasionally doing a > ECDH keygen could be at the edge of their performance/power limits, > and needing to do the ECDH keygen for every connection could easily > make using ECDH prohibitive. OTOH, we don't want these devices to use > have a fixed ECDH key burned into their ROM, or similar, either. > > Another unintended consequence is that it makes resumption (formulated > as a sort of server-generated PSK in TLS 1.3) more necessary. Although > many implementations will probably implement resumption, I think there > are a lot of cases where one might prefer to avoid implementing and/or > enabling it. Also, even when it is enabled, making ECDH more expensive > relative to PSK/resumption would encourage building more complex > server software to distribute PSKs across machines. And/or the server > may choose to reuse PSKs longer. And/or the server may choose to use > the non-ECDHE form of PSK-based resumption (IIUC). Again, though, I > can't quantify the effect here. > > With all this in mind, absent other information. In the case of > servers hosting websites, I do think a limit of less than a minute is > reasonable. However, I think for the small device (IoT) case, the > limit should be longer, perhaps even hours. In practice, at the moment, sites are generally using RSA certificates, so a small device getting slashdotted would be dominated by the RSA signing costs rather than the ECDHE. But let's posit EdDSA certificates, where ECDHE generation might then account for a 1/3 of the handshake cost. You make a good point that we don't want to push low-end devices into PSK. Also, small devices are less likely to be able to afford the tables that make fixed-base operations fast. I don't actually object to allowing servers to cache a ECDHE public value for a small about of time. (QUIC currently does so for 30 seconds.) But I was worried about the arguments over the duration if I specified one :) Consider the motivations here: 1) We know that some implementations have gotten this wrong with TLS 1.2 and cached values for far too long. Presumably if they were to be naively extended to TLS 1.3 this issue would carry over. 2) We probably disagree with this banking industry desire to be able to backdoor their TLS connections, but we're not the police and fixing DH values is probably how they would do it. If it's going to be A Thing then it's much more likely that things will get misconfigured and it'll be enabled in places where it shouldn't be. If we have no detection mechanism then what we'll probably end up with is a Blackhat talk in a few years time about how x% of banks botched forward security at their frontends. Say that a value of an hour makes sense for some device and we feel that an hour's forward-security window is reasonable for security. The issue is that it significantly diminishes our detection ability because clients need to remember more than an hour's worth of values and I don't know if we can dedicate that amount of storage to this. Since I think the utility of this falls off as a reciprocal, I'll try making a concrete suggestion for a time limit: 10 seconds. >> Also, this cost doesn't seem too high: 85.6% of servers /don't/ reuse >> values and manage fine today. The generation of (EC)DH public values >> is also a fixed-based operation and thus can be much faster than DH >> key-agreement. > > According to the paper, a large majority of servers in the Alexa top > 1M are reusing keys. That 14.4% number is a fraction of the 80% > servers consistently in the Alexa top 1M that use browser-trusted > certificates and that use ECDHE. IIUC, approximately 20% of servers in > the Alexa top 1M that use browser-trusted certificates are using RSA > key exchange, which means they are also reusing the same key for every > connection. Also, according to the paper, more than half of servers > aren't using TLS or aren't using browser-trusted certificates, which > means that web browser connections to them are likely using the same > NULL key. Thanks for pointing that out. I thought that saying "14.4%" and so on was reasonable because it's a prevalence and we can assume that if other sites did enable (EC)DHE then they would probably make the same mistakes at a similar rate. But then I subtracted it from 100 and that really doesn't make sense. > Also, the Alexa top 1M isn't representative of every use of TLS, but > rather only one kind of application. > >> Lastly, some have proposed[2] (EC)DH reuse as a mechanism for enabling >> TLS connections to be decrypted and monitored by a middlebox. TLS is >> not designed to be decrypted by third-parties=E2=80=94that's kind of the >> point. Thus anyone doing this should not be surprised to hit a few >> MUST NOTs and, potentially, to have to configure implementations to >> allow such a deployment. > > The (presumably) accidental reuse of keys for long periods of time is > bad, and this MitM idea is even worse. But, if reuse were made a MUST > NOT, wouldn't such systems just use a different, perhaps worse, more > complex, and undetectable mechanism, like the one Dan Brown suggested > in the earlier thread? I think we should assume that while we may be > able to help prevent the former accidental badness with such a rule, > such a mechanism probably isn't going to have much effect on the > latter intentional badness. I much prefer people who are going to backdoor their TLS to use DH as the mechanism rather than something less detectable. I don't expect a MUST NOT will slow them down at all. I just want to ensure that this doesn't accidently carry into 1.3, and that any unofficial backdoor mechanism needed by some organisations doesn't inadvertently get enabled more widely than planned. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org