From nobody Mon Feb 1 00:30:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4F31A8A91 for ; Mon, 1 Feb 2016 00:30:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.927 X-Spam-Level: X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=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 luEncpXjOhI6 for ; Mon, 1 Feb 2016 00:30:18 -0800 (PST) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AA0E1A8A8F for ; Mon, 1 Feb 2016 00:30:17 -0800 (PST) Received: from mail-wm0-f47.google.com ([74.125.82.47]) by mrelayeu.kundenserver.de (mreue001) with ESMTPSA (Nemesis) id 0MDHlU-1aITqE2Qeq-00GY0I for ; Mon, 01 Feb 2016 09:30:14 +0100 Received: by mail-wm0-f47.google.com with SMTP id l66so59024618wml.0 for ; Mon, 01 Feb 2016 00:30:13 -0800 (PST) X-Gm-Message-State: AG10YORgLIoiEJOXZ+gVcxPOj37EpbqNEHyqkxqwbAN1SbR5F4Lvo6BmiNLpsRbje7NYaW1MDLGZQU1LOsAtog== MIME-Version: 1.0 X-Received: by 10.28.52.195 with SMTP id b186mr10029630wma.40.1454315413595; Mon, 01 Feb 2016 00:30:13 -0800 (PST) Received: by 10.28.30.129 with HTTP; Mon, 1 Feb 2016 00:30:13 -0800 (PST) In-Reply-To: References: <20160127151803.17788998.50067.47728@ll.mit.edu> Date: Mon, 1 Feb 2016 09:30:13 +0100 X-Gmail-Original-Message-ID: Message-ID: From: Bodo Moeller To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1143112e9e6dad052ab13129 X-Provags-ID: V03:K0:M1uSuCcxOG2PXG4cDCd0TwvZDdQq63eD2MBxcNR0SRGn/TbbQea sKuslri2lukXI9zOnWKMivc7OcsFKXkYnxBWpkOuEQHz3ElNVNyQpZuVxjdmf5hlxPabwBK lNV2/sLoRAL+wtHa+TX+3YeuoZgpcUGQXsISHAQNnEYVYGKkF5voK/hwXRuWFe0i7NPpt1F WXs6s0lUS2TO40fBcXmLA== X-UI-Out-Filterresults: notjunk:1;V01:K0:NqsDiFC4J0k=:H0vhmIeFlesnYBk1Qkx19X 7xQTdW+KkuSzWapOIkQm1GjajNKJGnvYOsdAGFM6QKz6jRy/qGV+Qy/EH0mmhLQOq37K9AqHX iaF+dgwtSttRoa0cAUGrTUNFTZNIieOgD8soPrmHC7RU461uBK0ve8zi4zwmuE4t1rWcxqu/i PGO9IsxkBxqb8WVMAZ3DWAo+/EfM5c6ssvuFOp9Ktqv71vigDsvmQidHUednAhIJL5cTcqAGd +/b2GLOO+eviYW1rQpWiSzv1tH5ZPGeF8dBw3N1ZHrCG7Iti3UaAHz99Ty6AXdqk9z8ws4OSO qfGqAYWgbuiQ1+4CbylcmMRvChVU6uxvCdCXCjb9stqNlqSeZdKEU0+mdeon5P7KlHGvtfVlz TA6qiuNZhGNDa76jDbqUIjKNwAjh3rT1uB0iUspNksNS8qpa48bIqJsjzc5IRCtr9un7c65nc P90qShg6J1CPuwHqR2Rxp9kkfbgaa56IAFBX833ZIz5bKeUGrrwhrH/tjnYf9aJP84AnhDsOI a5eHffkKhB7i12ARvYDDCRwn24T3M99HMOBUmH32xJbDNIJJP0x3+luAlKjRzuriV6Z5Iga/T NczGLpgrHgi82LhKAru15JED7hQsURTezXS51DesL4oULBr0qP/eYrh/wS5O6B1xrk8SraPvW /0NQMRaWmOVDnrnxFQs1PD5Qq/MM2MBGPOOSDFy99et2pidCFlr870iKlVA0sQ5QTTz2HhJdw HI9TaO6b4+HjQMns Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 08:30:20 -0000 --001a1143112e9e6dad052ab13129 Content-Type: text/plain; charset=UTF-8 If you keep using the same [EC]DH keys indefinitely, you're merely pseudonymous, not anonymous :-) Without a naming precedent, I'd still prefer [EC]DHE_anon over [EC]DH_anon (and possibly "unauth" over "anon", because "anon" could be interpreted as overpromising), but given the existing naming pattern started by DH_anon, I prefer consistency with that one. Bodo --001a1143112e9e6dad052ab13129 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If you keep using the same [EC]DH keys indefinitely, you&#= 39;re merely pseudonymous, not anonymous :-)

Withou= t a naming precedent, I'd still prefer [EC]DHE_anon over [EC]DH_anon (a= nd possibly "unauth" over "anon", because "anon&qu= ot; could be interpreted as overpromising), but given the existing naming p= attern started by DH_anon, I prefer consistency with that one.
Bodo

--001a1143112e9e6dad052ab13129-- From nobody Mon Feb 1 07:01:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 817F71AC3A1 for ; Mon, 1 Feb 2016 07:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gc4MK0dd7x5T for ; Mon, 1 Feb 2016 07:01:09 -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 937FA1A930A for ; Mon, 1 Feb 2016 07:01:09 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7F0A2433409 for ; Mon, 1 Feb 2016 15:01:08 +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 691A54DE70 for ; Mon, 1 Feb 2016 15:01:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1454338868; bh=919UmdvJcq1d+W+9RF/h84JRewTi5MTkjTNXIS2ZcXs=; l=2630; h=From:To:Date:From; b=FFnNmTTg/iUXQkOGskyAPDI+oqymS7jwT7VmMOc3RZSx9agGAZvhQHSffon1MDUBf Mlr2rcpQ1qm2BC/VRrZzdEp4G0PwRLEgVzcBe48NT2mP7xCDavYrDxLYldX4zvP0Is B5qS+81ylpo4sqgSHPXQr/Yy8d8xaECL1OHchEos= 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 66A60202D for ; Mon, 1 Feb 2016 15:01:08 +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.1076.9; Mon, 1 Feb 2016 10:01:07 -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.1076.000; Mon, 1 Feb 2016 10:01:07 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: Interop for X25519 Thread-Index: AdFdAU6vZ7mgHNyzS6SARLAyS2xxnA== Date: Mon, 1 Feb 2016 15:01:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.73] Content-Type: multipart/alternative; boundary="_000_e3992ccaac08429eb5a7ee96631b176busma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Interop for X25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 15:01:12 -0000 --_000_e3992ccaac08429eb5a7ee96631b176busma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If you have X25519 key exchange for TLS and are willing to help OpenSSL int= erop (soon), please drop me a line. -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_e3992ccaac08429eb5a7ee96631b176busma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you have X25519 key exchange for TLS and are will= ing to help OpenSSL interop (soon), please drop me a line.

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_e3992ccaac08429eb5a7ee96631b176busma1exdag1mb1msgcorpak_-- From nobody Mon Feb 1 08:48:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC19B1B3266 for ; Mon, 1 Feb 2016 08:48:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtITSxT5ab66 for ; Mon, 1 Feb 2016 08:48:23 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 962631B3264 for ; Mon, 1 Feb 2016 08:48:23 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D5E9910224008; Mon, 1 Feb 2016 08:48:22 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Mon, 1 Feb 2016 08:48:23 -0800 (PST) Message-ID: <031c3dafb6fd308daab9e5174812c385.squirrel@www.trepanning.net> In-Reply-To: References: <20160127151803.17788998.50067.47728@ll.mit.edu> Date: Mon, 1 Feb 2016 08:48:23 -0800 (PST) From: "Dan Harkins" To: "Martin Thomson" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] ECDH_anon X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 16:48:25 -0000 On Sun, January 31, 2016 10:00 pm, Martin Thomson wrote: > On 1 February 2016 at 16:56, Dan Harkins wrote: >>>>From a protocol perspective, they are the same. The distinction at >>> the protocol level between ECDH_RSA (for example) and ECDH_anon is >>> that ECDH_anon requires a ServerKeyShare message in the same way that >>> ECDHE_RSA does. >> >> So? A static-static, static-ephemeral, and ephemeral-ephemeral >> all look the same from a protocol perspective too but they are >> very different and have very different properties. > > If a tree falls in the forest and no one deletes the private key, is > it static or ephemeral. If you never use it again then its compromise would only expose that 1 exchange so I'd say it's ephemeral. If you reuse it then it becomes static. But if this problem is because we have code that is not deleting the private keys for the ECDH_anon exchange then I'd say the pull request should be with that codebase to fix that problem. Dan. From nobody Mon Feb 1 15:01:28 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 A24761B3862; Mon, 1 Feb 2016 15:01:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160201230127.6174.99318.idtracker@ietfa.amsl.com> Date: Mon, 01 Feb 2016 15:01:27 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 23:01:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier Authors : Yoav Nir Simon Josefsson Manuel Pegourie-Gonnard Filename : draft-ietf-tls-rfc4492bis-06.txt Pages : 31 Date : 2016-02-01 Abstract: This document describes key exchange algorithms based on Elliptic Curve Cryptography (ECC) for the Transport Layer Security (TLS) protocol. In particular, it specifies the use of Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards Digital Signature Algorithm (EdDSA) as new authentication mechanisms. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 1 15:15:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CF01B3882 for ; Mon, 1 Feb 2016 15:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qRXLz0KWqe4 for ; Mon, 1 Feb 2016 15:15:09 -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 D17001B3881 for ; Mon, 1 Feb 2016 15:15:08 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id l66so94191157wml.0 for ; Mon, 01 Feb 2016 15:15:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=H76hRN3tBw8EYeNkioUwSQZRR4Pg3l5QlaG3P2XTwF0=; b=UDU534B1hf8D3IcIGFXJ5DfwfBo1KwQQGvCXU0zRKPnqDtXaR5IxvlFzZ6AfaKANtc /efFXZJZm9MWRsnJv8eGJ+1l9j5A5SWK33Mh0ZogE58dmkc/6gd9RCckDTjEtOYYe6Ia LpYPDHNb36B32VWwqezYlCLdSo9OKj6IuW4+YLbJNm9xkfQCaFvbHEhuIPb9CP/ozwIS Srnjfb9GoupBCUJMi5I8UJqyRUh1BOVgNgHfKVKlT8PIENZN4WJuGElrisw9ZV9hoMwW PSk6DZA3YN/Ybje5vlM4rxfIJ2lF/6iL4vfZ8l4f3tRK0/hKahL2ispFHW/58j+LqL7I 2j4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=H76hRN3tBw8EYeNkioUwSQZRR4Pg3l5QlaG3P2XTwF0=; b=OxzGP8dPP53b8CMsc65u1/U6x5eH982LyFucnFuN3dQylqn/Fkab85Copcxpkf8PrE c9GubOUGzqXEXbjKNXO4tPfqd4DVonr6UzhZoPwM5ukRIc+sqYvUpE4/NmkE5Fpt08NH RkQf2ibGB4Av3rVRQw1WyF8HKPOjnJAd64rXYF927MU3QFQn/dhn2Y1D/wn9KpgH2Tdb 1WsZ6uSpTlh5ih3lLswA8AtYCO5aO5mD0vVnwamk/MPIPr+hBjp+qHJAZyakU9GOEgP4 M+Lni9/TXDUQLwDOgy0knOouHB6Ocsjmldn7xQvVYKaZlvV8PQcte2HWxF+76AUaRr+1 PyMw== X-Gm-Message-State: AG10YOTSAU3jhAMWAhZDLQ5PHyronXNBcLR99g1DnFXoAsyGLF9HIeA4T95WC2h3fnwEHg== X-Received: by 10.28.113.220 with SMTP id d89mr15191732wmi.56.1454368507294; Mon, 01 Feb 2016 15:15:07 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id 75sm13684698wmo.22.2016.02.01.15.15.06 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Feb 2016 15:15:06 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <20160201230127.6174.99318.idtracker@ietfa.amsl.com> Date: Tue, 2 Feb 2016 01:15:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4735FA26-ED6C-4DDE-9062-F4895FB8AA95@gmail.com> References: <20160201230127.6174.99318.idtracker@ietfa.amsl.com> To: "" X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Feb 2016 23:15:11 -0000 Hi No big changes: - Replaced the reference to the CFRG draft with RFC 7748 - Some editorial improvements by Martin Thomson. So there are still a few open issues (you can see them on github: = https://github.com/tlswg/rfc4492bis/issues We=E2=80=99re also waiting for the CFRG EdDSA draft (now in RGLC) to = complete that part of the document. Yoav > On 2 Feb 2016, at 1:01 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Transport Layer Security Working = Group of the IETF. >=20 > Title : Elliptic Curve Cryptography (ECC) Cipher = Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier > Authors : Yoav Nir > Simon Josefsson > Manuel Pegourie-Gonnard > Filename : draft-ietf-tls-rfc4492bis-06.txt > Pages : 31 > Date : 2016-02-01 >=20 > Abstract: > This document describes key exchange algorithms based on Elliptic > Curve Cryptography (ECC) for the Transport Layer Security (TLS) > protocol. In particular, it specifies the use of Ephemeral Elliptic > Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and = the > use of Elliptic Curve Digital Signature Algorithm (ECDSA) and = Edwards > Digital Signature Algorithm (EdDSA) as new authentication = mechanisms. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-06 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-rfc4492bis-06 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Feb 2 00:39:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D8A91AC3D6 for ; Tue, 2 Feb 2016 00:37:36 -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, RP_MATCHES_RCVD=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id phMKGT0a4TqZ for ; Tue, 2 Feb 2016 00:37:34 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 93FD31A8A97 for ; Tue, 2 Feb 2016 00:37:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7465B28F7; Tue, 2 Feb 2016 10:37: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-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id KO_2dQNQs8PE; Tue, 2 Feb 2016 10:37:29 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id DFF1D230D; Tue, 2 Feb 2016 10:37:29 +0200 (EET) Date: Tue, 2 Feb 2016 10:37:28 +0200 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20160202083728.GA9143@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160201230127.6174.99318.idtracker@ietfa.amsl.com> <4735FA26-ED6C-4DDE-9062-F4895FB8AA95@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4735FA26-ED6C-4DDE-9062-F4895FB8AA95@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-06.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Feb 2016 08:37:36 -0000 On Tue, Feb 02, 2016 at 01:15:05AM +0200, Yoav Nir wrote: > Hi > > No big changes: > - Replaced the reference to the CFRG draft with RFC 7748 > - Some editorial improvements by Martin Thomson. > > So there are still a few open issues (you can see them on github: https://github.com/tlswg/rfc4492bis/issues > > We’re also waiting for the CFRG EdDSA draft (now in RGLC) to complete that part of the document. Also, I would want the negotiation mechanisms for EdDSA in TLS 1.2 and TLS 1.3 to be the same, so those should be decided. -Ilari From nobody Wed Feb 3 16:47:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6A751B379A; Wed, 3 Feb 2016 16:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wumRTW_0JP-O; Wed, 3 Feb 2016 16:47:24 -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 8C56F1ACE85; Wed, 3 Feb 2016 16:47:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E443EBE3F; Thu, 4 Feb 2016 00:47:20 +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 WxxAvW65v_1h; Thu, 4 Feb 2016 00:47:18 +0000 (GMT) Received: from [10.87.48.75] (unknown [86.42.27.19]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 725BCBE3E; Thu, 4 Feb 2016 00:47:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1454546838; bh=MM0GP4SvRgzpMlZoWB8dzU0cs8kqjzmecAGpFnicJ7M=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=0GtRYDbzKox4w2vkdPelFUVdkfm/fFP47nT6xYejiK7JRm9AGvfNKDbMJgZlOrytP gJpylEc6szxzBBTOV3mYnO3zktWYZ2VdBt8XtnvNdPVs3vaRn705zBAkkFJIUEhJPz XZwmcbPbe1bh2d+xYjTflDSAjMgq9ZH4YywSYG/Y= To: John Bradley , iana@iana.org References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56B29F96.9050107@cs.tcd.ie> Date: Thu, 4 Feb 2016 00:47:18 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: Tokbind WG , "tls@ietf.org" Subject: Re: [TLS] [Unbearable] Early code point assignment requests for "Transport Layer Security (TLS) Extensions" registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 00:47:26 -0000 Hi All, (Adding the TLS wg list, just in case.) I think this is fine and IANA should allocate a codepoint as requested. Cheers, S. On 02/02/16 23:50, John Bradley wrote: > > The Tokbind WG would like to ask for an early allocation of an IANA > code point for the "TLS Extension for Token Binding Protocol > Negotiation" > (https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02 > ). > This document defines a new TLS extension "token_binding", which > needs to be added to the IANA "Transport Layer Security (TLS) > Extensions" registry. > > Please note that this document also seeks to establish a registry for > identifiers of Token Binding key parameters entitled "Token Binding > Key Parameters" under the "Token Binding Protocol" heading. This new > registry is not part of the early assignment request. > > At this point, authors do not expect major changes in the "TLS > Extension for Token Binding Protocol Negotiation" specification. > There are at least two prototype implementations of this > specification being worked on (by Google and Microsoft). An early > IANA code point assignment would facilitate implementation and > deployment experience prior to the publication of the RFC. > > Regards John Bradley > > > > _______________________________________________ Unbearable mailing > list Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearable > From nobody Thu Feb 4 08:15:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E1F61AC3AE for ; Wed, 3 Feb 2016 16:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 NrTXxCptcB2a for ; Wed, 3 Feb 2016 16:50:24 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E42791B37A0 for ; Wed, 3 Feb 2016 16:50:23 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id z13so33872322ykd.0 for ; Wed, 03 Feb 2016 16:50:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ve7jtb-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AMor43vykguC2boo2fMVhrnz3chB/wLPrGYhJ0ho3To=; b=iz8sq+aTa5O68PUV2tE56GMgdszqEoix8yYiP9zyxr8nzZEoho9Ho8YOgrkXN35LDW ehOt084l1AlInBZX5K39IBl36a6XzGV5V68GejwmpJaZJv/aQNgZjlZh1BDrH/MV5ZnG popeRh/WraLfpcI3Xe4dBv+SfPIK2Ft40ZBVY7FiKfFgVCznT2kAad1iuxxvE3CpBLhV 8eHodOlFH3gYKvNYH+8f0DhRL7WBO0/5+TXfn9zi+F8kk4zJQbszaM/VtW6bcmwf3kYN RkIcq8oeH1t2dADnI9s9jPQdAM+sIRM6LL2L8sFsD2tlW6t51qY5EJ7RLzwKWBSkk+j5 zVtw== 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:date :message-id:subject:from:to:cc:content-type; bh=AMor43vykguC2boo2fMVhrnz3chB/wLPrGYhJ0ho3To=; b=Ymy1EHx3G0rtOStWRuhxCKFQbRKzP0ybveiLwnkbWpZo6V7wq+j780+wqR82sD+xRY QTMNHJm9btNnLODzZ16Z8u2PbRt9kjSMvlhTKEgNXRzXGJtGRn/W2QPPydJHmNxMeYho GVgnWk5G5hx07BYozrA5NEPwDQMJvlR+x4Lr9AWKrtYmRnc1zz95Sh2ZOJf0MVto61xA GJnvWbt25f9rh4uNd+E20ClFuhZec4PxcGoAGui1Cyj6W78u9StAKJIjgaM65z+igz/L dMSs/iOy+o+NoobiMM3mfNH5AKt206COOEF0nKXNpwg0Bz/EXDM7O/lRy19ww1NJWtEM IX9Q== X-Gm-Message-State: AG10YOS5rgmpweqUJUnRiNyvCFR+ulKOZZsqFgWZE8iZVCQOOhr40qDOQNDw0TaFXhLq0VETcKRPBKeDWo61EA== MIME-Version: 1.0 X-Received: by 10.37.76.3 with SMTP id z3mr2362392yba.165.1454547023192; Wed, 03 Feb 2016 16:50:23 -0800 (PST) Received: by 10.37.207.5 with HTTP; Wed, 3 Feb 2016 16:50:22 -0800 (PST) Received: by 10.37.207.5 with HTTP; Wed, 3 Feb 2016 16:50:22 -0800 (PST) In-Reply-To: <56B29F96.9050107@cs.tcd.ie> References: <56B29F96.9050107@cs.tcd.ie> Date: Wed, 3 Feb 2016 21:50:22 -0300 Message-ID: From: John Bradley To: Stephen Farrell Content-Type: multipart/alternative; boundary=001a113e6b66a09d1f052ae71ee5 Archived-At: X-Mailman-Approved-At: Thu, 04 Feb 2016 08:15:53 -0800 Cc: Tokbind WG , iana@iana.org, "tls@ietf.org" Subject: Re: [TLS] [Unbearable] Early code point assignment requests for "Transport Layer Security (TLS) Extensions" registry X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 00:50:25 -0000 --001a113e6b66a09d1f052ae71ee5 Content-Type: text/plain; charset=UTF-8 Thanks. On Feb 3, 2016 9:47 PM, "Stephen Farrell" wrote: > > Hi All, > > (Adding the TLS wg list, just in case.) > > I think this is fine and IANA should allocate a codepoint as > requested. > > Cheers, > S. > > On 02/02/16 23:50, John Bradley wrote: > > > > The Tokbind WG would like to ask for an early allocation of an IANA > > code point for the "TLS Extension for Token Binding Protocol > > Negotiation" > > (https://tools.ietf.org/html/draft-ietf-tokbind-negotiation-02 > > ). > > This document defines a new TLS extension "token_binding", which > > needs to be added to the IANA "Transport Layer Security (TLS) > > Extensions" registry. > > > > Please note that this document also seeks to establish a registry for > > identifiers of Token Binding key parameters entitled "Token Binding > > Key Parameters" under the "Token Binding Protocol" heading. This new > > registry is not part of the early assignment request. > > > > At this point, authors do not expect major changes in the "TLS > > Extension for Token Binding Protocol Negotiation" specification. > > There are at least two prototype implementations of this > > specification being worked on (by Google and Microsoft). An early > > IANA code point assignment would facilitate implementation and > > deployment experience prior to the publication of the RFC. > > > > Regards John Bradley > > > > > > > > _______________________________________________ Unbearable mailing > > list Unbearable@ietf.org > > https://www.ietf.org/mailman/listinfo/unbearable > > > --001a113e6b66a09d1f052ae71ee5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks.

On Feb 3, 2016 9:47 PM, "Stephen Farrell&qu= ot; <stephen.farrell@cs.tcd= .ie> wrote:
<= br> Hi All,

(Adding the TLS wg list, just in case.)

I think this is fine and IANA should allocate a codepoint as
requested.

Cheers,
S.

On 02/02/16 23:50, John Bradley wrote:
>
> The Tokbind WG would like to ask for an early allocation of an IANA > code point for the "TLS Extension for Token Binding Protocol
> Negotiation"
> (https://tools.ietf.org/html/draft= -ietf-tokbind-negotiation-02
> <https://tools.ietf.org/html/dr= aft-ietf-tokbind-negotiation-02>).
> This document defines a new TLS extension "token_binding", w= hich
> needs to be added to the IANA "Transport Layer Security (TLS)
> Extensions" registry.
>
> Please note that this document also seeks to establish a registry for<= br> > identifiers of Token Binding key parameters entitled "Token Bindi= ng
> Key Parameters" under the "Token Binding Protocol" head= ing. This new
> registry is not part of the early assignment request.
>
> At this point, authors do not expect major changes in the "TLS > Extension for Token Binding Protocol Negotiation" specification.<= br> > There are at least two prototype implementations of this
> specification being worked on (by Google and Microsoft). An early
> IANA code point assignment would facilitate implementation and
> deployment experience prior to the publication of the RFC.
>
> Regards John Bradley
>
>
>
> _______________________________________________ Unbearable mailing
> list Unbearable@ietf.org > https://www.ietf.org/mailman/listinfo/unbearabl= e
>
--001a113e6b66a09d1f052ae71ee5-- From nobody Fri Feb 5 09:21:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B761B3BC6 for ; Fri, 5 Feb 2016 09:21:47 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NdWnoo51z4ZF for ; Fri, 5 Feb 2016 09:21:46 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::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 72D291B3BC5 for ; Fri, 5 Feb 2016 09:21:46 -0800 (PST) Received: by mail-qg0-x22d.google.com with SMTP id b35so72491344qge.0 for ; Fri, 05 Feb 2016 09:21:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=lW/YHArwRrPYgs2wt5DLB1boFCv9Vx8dbR5rwviEAk0=; b=Y3OIadMRF33JSP3SOPpKJCTm6qxuZupiXOyZjo2qVjiJtp6ur9AK9ny8nb7Wh0EIJ/ j/94AhCY6q7kCi8GjiJjjtiSMO30B7dvdofrtFGMCFs1IaWJMIOdo7oRtqGlSmzNjkfT d2t1K0WCr5nRgCJrRtvzLjSlOwRqRRao+xdqlBRvAyIkJdVliqTe2K5QyezZU8JoSO7A DOwnCu9/PUiBmHypCJnVo8XEKr9A9UqEzowe+BP6DkL5oxfmVOmZNJdth+whu4UKBiVw LRLL7ET5ws29k8a0WjBzMC0jcPajb2gWYbczMTlYsTd9/aC5BBm3VwGUxmgSV0zA85ys xqNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=lW/YHArwRrPYgs2wt5DLB1boFCv9Vx8dbR5rwviEAk0=; b=bRDHzh0D9FnCR55Z4mCYIBnmy/TG88qCiESQ1FwpSigR2B8YTqME5snihHA9Jr97oG KZUW0wrK6qsyUfUXBow7QXsCJ1RWv7J2w2m9yVj8k1ClLgjFVQza6sZ3SJ9IbM+bMrJ+ pkHD1q7ysCLJvH1jLVsu1jO3AY5vyq45RA28iiXmMfgf7j1LA6KoOHR1C//GMMxmyIlA z0s/piCZZYZRvu3y9WGjggSmyLLr720r+Ub4twbfqEnuMG5rafBf6tGNclFg95ZMLBeC GL/gJXUMv4YVS3Qyi9DxEjPQOk4xJvq+1IwmHEPUzJM5t9WsrVs/UFZJnESN7vOgL0Ax SVNQ== X-Gm-Message-State: AG10YORHGBhUiC6ORT8/K7J2gf00zvhrnCJKNTno6aWTWc3G+nD6qAK93/GKs18NxR5W2g== X-Received: by 10.140.169.9 with SMTP id p9mr19038270qhp.50.1454692905437; Fri, 05 Feb 2016 09:21:45 -0800 (PST) Received: from ?IPv6:2601:148:c000:48c8:9013:9345:289c:d243? ([2601:148:c000:48c8:9013:9345:289c:d243]) by smtp.gmail.com with ESMTPSA id 123sm8235392qhu.22.2016.02.05.09.21.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Feb 2016 09:21:44 -0800 (PST) To: tls@ietf.org References: <962c1d946dba48bf95d22f0aa5f77c8f@ustx2ex-dag1mb1.msg.corp.akamai.com> <1D8D93F4-7A7C-4875-927E-21E19AB5F942@gmail.com> <658f368606174b10af76d8c38cbe16b6@ustx2ex-dag1mb1.msg.corp.akamai.com> From: Michael StJohns Message-ID: <56B4DA2C.3040005@nthpermutation.com> Date: Fri, 5 Feb 2016 12:21:48 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Require deterministic ECDSA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 17:21:47 -0000 On 1/25/2016 7:41 PM, Bill Cox wrote: > I have low expectations for IoT vendors' TRNGs. When deadlines get > tight, good engineering on the TRNG is easy to drop. As long as they > whiten the output, it is very difficult to detect TRNG flaws, so there > is little incentive to put in much engineering. IIRC, the FIPS > standard requires vendors to be secretive about their TRNGs. They are > not allowed to give us access to the raw data from the entropy source, > and cannot show us schematics for their design, making it nearly > impossible to differentiate a well designed TRNG from an insecure one. Sorry for the late response on this one... You should take a quick look at NIST Draft SP800-90B, section 7.1 regarding how to do validation on entropy sources. While this is still in draft form and doesn't yet trigger requirements in the FIPS validation process, I would expect it will at some point. I would also expect that new designers are probably making sure that this type of interface is included in their products - to at least allow for the possibility of validation. Of course, if an IoT vendor isn't looking for FIPS validation (or some other such process that requires at least a little testing), all bets are off. Later, Mike From nobody Fri Feb 5 12:08:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE0B81ACDA9 for ; Fri, 5 Feb 2016 12:08:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.379 X-Spam-Level: X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=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 EA3L-zB-UZHr for ; Fri, 5 Feb 2016 12:08:00 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068361ACCDC for ; Fri, 5 Feb 2016 12:07:59 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id d63so140566949ioj.2 for ; Fri, 05 Feb 2016 12:07:59 -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 :content-type; bh=/59UuUf+fzwD29340lEYgCwndCc/rExtFF1bYTRivO4=; b=cxH8nPz4H9pH4gtQzW8Qlm+3uqWX+5dWZLP4MLv1aB2R2HhaAs+nd1IgIFOPEnTWbm OloJfDoio3FD3uKV1dcEMB14bxSRXjGlzt6AmRLVbvx3Ha+SIGYv223qAX8cpGeuc68i de1+ZSQs62k+89HggRGQpYoN/WXPcC1ox8FBc= 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:content-type; bh=/59UuUf+fzwD29340lEYgCwndCc/rExtFF1bYTRivO4=; b=DPUOnWh0FtpJUlry+Tk4Mgri/MWvtNo7kJL+3u/auqazr+V3DjHA67dXglu5f0hDa9 qHpbba73klnTrP3dzKlH050s9Dc+MbPqQG2ge6FR7TvqtBwdCqyu2XDp0vuTzJqM81bn yxRJKu1zCTouSztbTEnjkSSKMRkZF0LRXd85rpXkdgdzopHX4sj5KNVzxpKWlayBwxAb NyJY+hJN+O1Z2S1tFlxYQX0UZ3gy0zRXUMUZM7a8TUdaikZKM2DFAXGbGXA1fKUFHN5F Vf5fC8Ob78kfYEgjP6RxGdqdeGSolgXzQ/yiy2x0uE6xdV7Dm+vUi7t3YSCbVOGFidSn noZg== X-Gm-Message-State: AG10YOQYosI4yf4tMNZk/S+9d77EK4E+ZfC28o2qC8ProYWcD+43ypeBY2KJkPtBCC+g2pEvhEf3PARzNYgPYgKP X-Received: by 10.107.9.154 with SMTP id 26mr19845278ioj.62.1454702878982; Fri, 05 Feb 2016 12:07:58 -0800 (PST) MIME-Version: 1.0 References: <20160111183017.GA12243@roeckx.be> In-Reply-To: From: David Benjamin Date: Fri, 05 Feb 2016 20:07:49 +0000 Message-ID: To: Kurt Roeckx , tls@ietf.org Content-Type: multipart/alternative; boundary=001a113ea2b65b63f6052b0b6828 Archived-At: Subject: Re: [TLS] Deprecating TLS 1.0, 1.1 and SHA1 signature algorithms X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Feb 2016 20:08:02 -0000 --001a113ea2b65b63f6052b0b6828 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 11, 2016 at 6:17 PM David Benjamin wrote: > In terms of getting rid of TLS 1.0 and TLS 1.1 altogether, we're seeing > around 3% of connections using TLS 1.0 or TLS 1.1. That's quite high, and > it's likely that enterprise deployments are much worse. > > I started gathering numbers on ServerKeyExchange hashes back in November. > The code isn't on Chrome's stable channel yet, but earlier channels say a > bit over 5% of ServerKeyExchanges are signed with SHA-1, which is also > quite high. > > I also started probing servers in November and observed: > (a) Servers which always sign SHA-1. > Lest anyone get their hopes up, it turns out OpenSSL-based servers before 1.0.1j that use SNI (specifically those that call SSL_set_SSL_CTX in the SNI callback) ignore the signature_algorithms extension and only sign SHA-1. We'll be stuck with this one for a long while. 1.0.1j was only released 2014-10-15, and Linux distributions tend to be on older versions with backported security fixes to say nothing of folks that don't update at all. https://rt.openssl.org/Ticket/Display.html?id=3560 David > (b) Servers which sign SHA-1 *unless* signature_algorithms omits it. Then > they sign SHA-256!?!!? > (c) Servers which sign SHA-2 but fail if signature_algorithms omits SHA-1. > The ones I looked at were all from serving SHA-1 certificates, so probably > their SSL stack compares certs against sig_algs. > > (b) and (c) mean that getting a sense of the true impact will be > complicated until we finish getting SHA-1 certificates out of our system. I > have not dug into what's going on with groups (a) and (b) yet. > > This all is not to say we shouldn't phase these out. But I do not expect > it to be a speedy process for browsers. > > David > > On Mon, Jan 11, 2016 at 1:30 PM Kurt Roeckx wrote: > >> Hi, >> >> After the SLOTH paper, we should think about starting to deprecate >> TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS >> 1.2. >> >> As I understand it, they estimate that both TLS 1.2 with SHA1 and >> TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be >> broken. They all depend on the chosen prefix collision on SHA1, >> with the MD5 part in TLS 1.0 and 1.1 not adding much. >> >> It seems that disabling SHA1 in TLS 1.2 doesn't buy you anything >> unless you also disable TLS 1.0 and 1.1. >> >> >> Kurt >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --001a113ea2b65b63f6052b0b6828 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Jan 11= , 2016 at 6:17 PM David Benjamin <davidben@chromium.org> wrote:
In terms of getting rid of TLS 1.0 and TLS 1.1 altoge= ther, we're seeing around 3% of connections using TLS 1.0 or TLS 1.1. T= hat's quite high, and it's likely that enterprise deployments are m= uch worse.

I started gathering numbers on ServerKeyExchange hashes b= ack in November. The code isn't on Chrome's stable channel yet, but= earlier channels say a bit over 5% of ServerKeyExchanges are signed with S= HA-1, which is also quite high.

I also started probing s= ervers in November and observed:
(a) Servers which always sign SHA-1.

Lest anyone get their = hopes up, it turns out OpenSSL-based servers before 1.0.1j that use SNI (sp= ecifically those that call SSL_set_SSL_CTX in the SNI callback) ignore the = signature_algorithms extension and only sign SHA-1. We'll be stuck with= this one for a long while. 1.0.1j was only released 2014-10-15, and Linux = distributions tend to be on older versions with backported security fixes t= o say nothing of folks that don't update at all.

David
=
=C2=A0
= (b) Servers which sign SHA-1 *unless* signature_algorithms omits it. Then t= hey sign SHA-256!?!!?
(c) Servers which sign SHA-2 but fail if signature= _algorithms omits SHA-1. The ones I looked at were all from serving SHA-1 c= ertificates, so probably their SSL stack compares certs against sig_algs.
(b) and (c) mean that getting a sense of the true impact will be comp= licated until we finish getting SHA-1 certificates out of our system. I hav= e not dug into what's going on with groups (a) and (b) yet.

This= all is not to say we shouldn't phase these out. But I do not expect it= to be a speedy process for browsers.

David

On Mon,= Jan 11, 2016 at 1:30 PM Kurt Roeckx <kurt@roeckx.be> wrote:
Hi,

After the SLOTH paper, we should think about starting to deprecate
TLS 1.0 and TLS 1.1 and the SHA1 based signature algorithms in TLS
1.2.

As I understand it, they estimate that both TLS 1.2 with SHA1 and
TLS 1.0 and 1.1 with MD5|SHA1 currently require about 2^77 to be
broken.=C2=A0 They all depend on the chosen prefix collision on SHA1,
with the MD5 part in TLS 1.0 and 1.1 not adding much.

It seems that disabling SHA1 in TLS 1.2 doesn't buy you anything
unless you also disable TLS 1.0 and 1.1.


Kurt

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a113ea2b65b63f6052b0b6828-- From nobody Sat Feb 6 12:37:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD27C1B335F for ; Sat, 6 Feb 2016 12:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p9Zgrof5zIcV for ; Sat, 6 Feb 2016 12:37:04 -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 40B221B335C for ; Sat, 6 Feb 2016 12:37:03 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id p63so69243923wmp.1 for ; Sat, 06 Feb 2016 12:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-type; bh=s8MxE1Hrg6//+lCM2v0njuOwG38ntx3dU3JJc8EJ63U=; b=KD9d0HYw6WQMc/QzafM2nrYhgcKBiZII/wvcNS6EUnLhgQ1UttOVEX/MGvAwx2SriN RsUI5eC7Wrv2B0dcAh7z2IIWTEBhVFc1jnjeeMVLI/1XstDC1f+Grd2yASRpICLiFzjU BdBxBpdHlVcLxvfiQwkCW0JTXNS3rTDurKoJ9y8mifL117hhl+rmRUex9+rBuZk5HHX+ cX+b/YzDrZJ0oLxt1mp3BWQSzSo9eiX3i0t23ib4LvqwoR6UuccPSFTV87jp3K5ki5dA dw0I06N29M7zqeM2BIAFpIK0T+DOK2IA6p+qZ7D66Ft9NfCAswUDEfu/EWCt4JNMoZF2 QvIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-type; bh=s8MxE1Hrg6//+lCM2v0njuOwG38ntx3dU3JJc8EJ63U=; b=AtytI4KXOj8OT8vWiGumZUfGz86HqIfr2VM6t6Ff9b3ciSebaP0yVZbY2N0+YvLEPG 5WE83GJvu1DzXBBTjE4bK/n1RtSwpfmiNd2Bk+pp4KVdw6IX3sO2f25EWJBtA4YutS8I +Rozmq4hO2bEC319bT/O8Ihm9/rEDiRh9ZtQVoAStZoRgF7ALDKxs7XOwPPKyiD0zSnB 0EIpLLF5WNR+K13mdj5DqSAgvbjUGpCdwYyhCyUpsersjPhbnF7n+sqcWvocCKeIS7re tswvM7ZWrdo85VzmH4TFLTh5kOMMkvsJpFw57wlU2wdyBb4q9JXkECGspDJ2xh558iYQ EAiw== X-Gm-Message-State: AG10YORe6a5t4p9wwy9QGl6tsh8QxrsTa1qTG0SfObC9sFfV9euF3iPxRPazCEL55QQo0A== X-Received: by 10.194.173.65 with SMTP id bi1mr20034410wjc.110.1454791022623; Sat, 06 Feb 2016 12:37:02 -0800 (PST) Received: from [10.0.0.11] (bzq-79-182-36-67.red.bezeqint.net. [79.182.36.67]) by smtp.gmail.com with ESMTPSA id x186sm4681168wmg.19.2016.02.06.12.36.59 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 06 Feb 2016 12:37:01 -0800 (PST) References: <20160206202554.8543.90496.idtracker@ietfa.amsl.com> To: tls@ietf.org From: Yaron Sheffer X-Forwarded-Message-Id: <20160206202554.8543.90496.idtracker@ietfa.amsl.com> Message-ID: <56B65966.3020005@gmail.com> Date: Sat, 6 Feb 2016 22:36:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <20160206202554.8543.90496.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------060202030506040708080801" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Feb 2016 20:37:06 -0000 This is a multi-part message in MIME format. --------------060202030506040708080801 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit The draft describes using an opaque ticket (similar to a session resumption ticket) to pin the identity of a TLS server. The new version addresses several comments on this list, in particular regarding the message syntax, and requesting a comparison with TACK - thanks Dave and Daniel. Thanks, Yaron -------- Forwarded Message -------- Subject: New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt Date: Sat, 06 Feb 2016 12:25:54 -0800 From: internet-drafts@ietf.org To: Yaron Sheffer A new version of I-D, draft-sheffer-tls-pinning-ticket-01.txt has been successfully submitted by Yaron Sheffer and posted to the IETF repository. Name: draft-sheffer-tls-pinning-ticket Revision: 01 Title: TLS Server Identity Pinning with Tickets Document date: 2016-02-06 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-01.txt Status: https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/ Htmlized: https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-sheffer-tls-pinning-ticket-01 Abstract: Fake public-key certificates are an ongoing problem for users of TLS. Several solutions have been proposed, but none is currently in wide use. This document proposes to extend TLS with opaque tickets, similar to those being used for TLS session resumption, as a way to pin the server's identity. That is, to ensure the client that it is connecting to the right server even in the presence of corrupt certificate authorities and fake certificates. The main advantage of this solution is that no manual management actions are required. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------060202030506040708080801 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit The draft describes using an opaque ticket (similar to a session resumption ticket) to pin the identity of a TLS server. The new version addresses several comments on this list, in particular regarding the message syntax, and requesting a comparison with TACK - thanks Dave and Daniel.

Thanks,
    Yaron


-------- Forwarded Message --------
Subject: New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt
Date: Sat, 06 Feb 2016 12:25:54 -0800
From: internet-drafts@ietf.org
To: Yaron Sheffer <yaronf.ietf@gmail.com> 


A new version of I-D, draft-sheffer-tls-pinning-ticket-01.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:		draft-sheffer-tls-pinning-ticket
Revision:	01
Title:		TLS Server Identity Pinning with Tickets
Document date:	2016-02-06
Group:		Individual Submission
Pages:		16
URL:            https://www.ietf.org/internet-drafts/draft-sheffer-tls-pinning-ticket-01.txt
Status:         https://datatracker.ietf.org/doc/draft-sheffer-tls-pinning-ticket/
Htmlized:       https://tools.ietf.org/html/draft-sheffer-tls-pinning-ticket-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-sheffer-tls-pinning-ticket-01

Abstract:
   Fake public-key certificates are an ongoing problem for users of TLS.
   Several solutions have been proposed, but none is currently in wide
   use.  This document proposes to extend TLS with opaque tickets,
   similar to those being used for TLS session resumption, as a way to
   pin the server's identity.  That is, to ensure the client that it is
   connecting to the right server even in the presence of corrupt
   certificate authorities and fake certificates.  The main advantage of
   this solution is that no manual management actions are required.

                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------060202030506040708080801-- From nobody Sun Feb 7 21:21:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38FAE1A9113 for ; Sun, 7 Feb 2016 21:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 dnDUBqD583AE for ; Sun, 7 Feb 2016 21:21:04 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::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 6808E1A9114 for ; Sun, 7 Feb 2016 21:21:04 -0800 (PST) Received: by mail-lb0-x235.google.com with SMTP id bc4so76779749lbc.2 for ; Sun, 07 Feb 2016 21:21: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:date:message-id:subject:from:to :cc:content-type; bh=k8hLHGX388Vp51mmISc1X1UwXU1f8Eb6fC8qb9Tc5Tc=; b=VyiCAlXDDwtZnq80sy7M80thvqo0wAz9udMfNGbaJWK0u4nd/hOroSak1fyOUrtPTj KGSg0EMUn3R2aRKjHfJa0rzMrSsdIkY/fyq9xDaVhodRbxgeEjlaKC0QpRUV5LIKtr3p mWZUCfoii3qKeLd7oCcm8i1Tjsae5BwYQOlW3f0IKrs1XtyiwM0ybr41tN6+D2841x1T Sg+OO4GEKyuMdK9cnyXSINS2WHTF+94ccaCACezBI5DeaZNux71CBcHbiLEvbwu3Rkp2 OCXa75g1BmP/A43Z8LsQAbuvpUVwiyVZz45aA4mxeifYVbdrt+oXIzo4Sr9ppPefYoU5 xIgQ== 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:date :message-id:subject:from:to:cc:content-type; bh=k8hLHGX388Vp51mmISc1X1UwXU1f8Eb6fC8qb9Tc5Tc=; b=abr0ysODwixvOc1lzSHLMRDvEr4mfwDx3j4BQs3ZWOEiFPc3iBH/j/B9xtWmweQ3Lo mcBbYak4aefkik1ulS/TEycRShXJKzOKzfG6r8V7kYW+p3t0itymJpfdMmiUjQMr+yL+ SKeVnGrFn1UpDpIsbkPdLfvG6XIT9O9y9UfUvNU+PGNI//EQ3MoEI0tCP22qnO7Prmqu k+bxp1r+BiZYecjvt++Me+4xD70oN/koGLJ8hNYKMYH4uPxaUlCX7mbNTk5jXMBOWMXs tsrMwVGDBTOWu3NRBUbhEgh63lH2vJf0Q7pY1HcDpRfCrRSRk+PVXu4G1lhsnMlLzZVj oR4w== X-Gm-Message-State: AG10YOTkxJE37Cybk4+4XCHNaHOSzu+TNGzlIRWv7jrJfTqXAUTCsprjMUURTuf4TLBjCSML580RL6BQ+TYN4Q== MIME-Version: 1.0 X-Received: by 10.112.63.161 with SMTP id h1mr10351701lbs.61.1454908862501; Sun, 07 Feb 2016 21:21:02 -0800 (PST) Received: by 10.112.2.104 with HTTP; Sun, 7 Feb 2016 21:21:02 -0800 (PST) In-Reply-To: <56A8904D.10307@ericsson.com> References: <56A8904D.10307@ericsson.com> Date: Sun, 7 Feb 2016 21:21:02 -0800 Message-ID: From: Joseph Salowey To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3fe1eee3073052b3b5d67 Archived-At: Cc: avt@ietf.org Subject: Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 05:21:06 -0000 --001a11c3fe1eee3073052b3b5d67 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This document is relevant to the TLS working because it reserves a large portion of the TLS content type space. The values 0-19 and 64-255 cannot be used without checking for conflicts with SRTP-DTLS's wacky demultiplexing scheme. In TLS 1.3 we will move more encrypted content types which should limit the impact this unfortunate design on TLS evolution, but the working group should be aware of this. Cheers, Joe On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > AVTCORE and TLS, > > TLS WG, you are included in this WG last call, as this document affects > the TLS ContentType IANA registry. > > This email starts a two week WG last call, that ends on the 10th of > February. The intended status of this document is standards track (Propos= ed > Standard). > > The document can be retrieved here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Services, Media and Network features, Ericsson Research EAB/TXM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11c3fe1eee3073052b3b5d67 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This document is relevant to the TLS working because = it reserves a large portion of the TLS content type space.=C2=A0 The values= 0-19 and 64-255 cannot be used without checking for conflicts with SRTP-DT= LS's wacky demultiplexing scheme. =C2=A0 In TLS 1.3 we will move more e= ncrypted content types which should limit the impact this unfortunate desig= n on TLS evolution, but the working group should be aware of this. =C2=A0

Cheers,

Joe

On Wed, Jan 27, = 2016 at 1:39 AM, Magnus Westerlund <magnus.westerlund@ericsso= n.com> wrote:
AVTCORE and T= LS,

TLS WG, you are included in this WG last call, as this document affects the= TLS ContentType IANA registry.

This email starts a two week WG last call, that ends on the 10th of Februar= y. The intended status of this document is standards track (Proposed Standa= rd).

The document can be retrieved here:
https://datatracker.ietf.org/d= oc/draft-ietf-avtcore-rfc5764-mux-fixes/

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| = Phone=C2=A0 +46 10 7148287
F=C3=A4r=C3=B6gatan 6=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

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

--001a11c3fe1eee3073052b3b5d67-- From nobody Sun Feb 7 22:18:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 332F01A92BC; Sun, 7 Feb 2016 22:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] autolearn=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 a10kWDWn2_xo; Sun, 7 Feb 2016 22:18:03 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 431D41A92BA; Sun, 7 Feb 2016 22:18:00 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id z7so83246361yka.3; Sun, 07 Feb 2016 22:18:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=4AvcBTULt73lUC/NFqzjYOUBBgtiLHRZMQtgqH8v72o=; b=EwH8ix9AC9qJn0QwDlE5Y78vvOH2CsHEwzgrTFMP0JIlmK80SIJwWRH8jU/vskbszv VnaUBL8ulaIovxdkmTdB9hCCrhcT4u7b3pM1od4Ns6SIhmsrpPaItG5vnenincUqAL4y w27Gbk6Pj7WhikIVsUm0byfwp+or6vr/qP3WGqjkV7eahpMjCDFIl0A1gnG2uHD9hAJJ X7mXRvkGmUJgMrcysgoZjGlj+cioKZLirW7NC4TcF84kJe5xczzHmR0njseB9f7KlyS2 VQzBm0D/iXnCzyKk7INHY7KPQvcdPbP61F9x5O+C369OObyXAjMglaSL+tHc2aAf9WDW 5HJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=4AvcBTULt73lUC/NFqzjYOUBBgtiLHRZMQtgqH8v72o=; b=cGqDazvy/f1+RtX7j0BL1YuI0zACPTSb+FOGAvLD9ha6iIUd9q2v5oKkWmT710sAcT f66K0oOFSBBb/vjAgaMC4nnxuTDNjW4VLdIWWSvwlzBfNqJ8okJzbYIJCq3O8l4yz3ar 24rC7mA/938MwEf98fIjVmZMG3jyKcHnLZSWevGZQiYXg3D6PwH/qBao7cf2zdWw2O5s EY+zknoRrv2FK/zzBIL2u/6jjrGxbhA181fLVNBvSqPaqO3SoZkJi7Ocyvb4wJb/4cMH jllF7Q8d5nEjd6tysLTwgqwwMYCGgtYJnOcve+5ZFjLBhCmQ9eb/whrTlnJv8/8joKhV lRAg== X-Gm-Message-State: AG10YORWNTZNAIhIDg75PFdby9+QQDDezmkrXXMdFWOC+Yf7ez5A5lS3wnjyRYR3KHYByw== X-Received: by 10.37.21.5 with SMTP id 5mr13406796ybv.22.1454912279604; Sun, 07 Feb 2016 22:17:59 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id a7sm20035824ywf.55.2016.02.07.22.17.58 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 07 Feb 2016 22:17:59 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Mon, 8 Feb 2016 01:17:57 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56A8904D.10307@ericsson.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201602080117.57742.davemgarrett@gmail.com> Archived-At: Cc: avt@ietf.org Subject: Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 06:18:05 -0000 Permanently gobbling up the majority of the codespace feels like excessive force here. For TLS 1.3, the first byte will always be one of alert(21), handshake(22), or application_data(23), even for custom types. The stated type for TLSCiphertext has been frozen to application_data(23) with the actual type for the payload now in the encrypted fragment. (this is of course assuming we don't eventually drop the frozen type & version here, which now sounds unlikely if we're having to deal with design flaws like this) Even handshake records after the hellos will have an opaque_type of application_data(23), with the encrypted fragment.type containing the actual handshake(22) designation. All TLS 1.3+ packets will be detected with the RFC 5764 Section 5.1.2 algorithm even if new types are allocated in the proposed reserved ranges. Locking down the <1.2 registry seems fine, however 1.3+ should be able to do whatever it needs as its encrypted type is not going to get accidentally read & misinterpreted by anything. https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-5.2.2 https://tools.ietf.org/html/rfc5764#section-5.1.2 https://tools.ietf.org/html/draft-ietf-avtcore-rfc5764-mux-fixes-05#section-4 Dave On Monday, February 08, 2016 12:21:02 am Joseph Salowey wrote: > This document is relevant to the TLS working because it reserves a large > portion of the TLS content type space. The values 0-19 and 64-255 cannot > be used without checking for conflicts with SRTP-DTLS's wacky > demultiplexing scheme. In TLS 1.3 we will move more encrypted content > types which should limit the impact this unfortunate design on TLS > evolution, but the working group should be aware of this. > > > On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund > wrote: > > > AVTCORE and TLS, > > > > TLS WG, you are included in this WG last call, as this document affects > > the TLS ContentType IANA registry. > > > > This email starts a two week WG last call, that ends on the 10th of > > February. The intended status of this document is standards track (Proposed > > Standard). > > > > The document can be retrieved here: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ From nobody Mon Feb 8 10:36:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 807A41B3124 for ; Mon, 8 Feb 2016 10:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKNvfJsCClNx for ; Mon, 8 Feb 2016 10:36: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 4AB4A1B30DF for ; Mon, 8 Feb 2016 10:36:46 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C79DC3F4029 for ; Mon, 8 Feb 2016 18:36:44 +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 A76F33F4012 for ; Mon, 8 Feb 2016 18:36:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1454956604; bh=rdaKIBYNG52c2kJMHJb4oizi2bj8sTvU+UY2IT1JGcI=; l=2967; h=From:To:Date:From; b=xfyduKKkwMRM6kzKucNyJgCpndL55jqXMWMM49LZrVy48sadzPLG4398ogwuKalVP 0fNHMhLAotyiMJqAdYBeKbIPDwa/TrFyEo+OweDViNvlr3velROSkLs97NEUA2ambu ImEqtpEBF+UssExHywt+L5Gp/f/k+PwDSOoOu4lU= 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 A55B1202C for ; Mon, 8 Feb 2016 18:36:44 +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.1076.9; Mon, 8 Feb 2016 13:36:44 -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.1076.000; Mon, 8 Feb 2016 13:36:44 -0500 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: JPAKE Thread-Index: AdFin4mfxBQVLAQiSWSYc5Z1bcPNhA== Date: Mon, 8 Feb 2016 18:36:43 +0000 Message-ID: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.96] Content-Type: multipart/alternative; boundary="_000_6f81a71b264f47268ed42cb528cac17fusma1exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 18:36:48 -0000 --_000_6f81a71b264f47268ed42cb528cac17fusma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is anyone else using JPAKE? I found old I-D, but my search-engine-skillz m= ust be atrophied as I can't find any final RFC on it. It's currently "experimental" code in OpenSSL and we might drop it in the n= ext release. -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_6f81a71b264f47268ed42cb528cac17fusma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is anyone else using JPAKE?  I found old I-D, b= ut my search-engine-skillz must be atrophied as I can’t find any fina= l RFC on it.

 

It’s currently “experimental” code= in OpenSSL and we might drop it in the next release.

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_6f81a71b264f47268ed42cb528cac17fusma1exdag1mb1msgcorpak_-- From nobody Mon Feb 8 10:55:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04B5E1B318F for ; Mon, 8 Feb 2016 10:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buexNOEE4DIR for ; Mon, 8 Feb 2016 10:54:59 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA451B3189 for ; Mon, 8 Feb 2016 10:54:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4361; q=dns/txt; s=iport; t=1454957699; x=1456167299; h=reply-to:subject:references:to:from:message-id:date: mime-version:in-reply-to; bh=e9FHgBrLFmnsvyx55Zd1BxtHdT3aifqrXX2gPrGfjPU=; b=X/cC51OgXQ6jO8UCnuWI5IKWw94lQhwv3bxEoRaynHJCmn+J5Hnu6e/h FHKeb58RahfOh3+f2yU7Osji2eu/jEzqeii82c5V+Jq+SI2l+BiyI5L6A uzH7BXGO4eiIjepl6xnEJg6y5EpSsW60Mj7CY+aqpiFWEbJc0yVN1AEKL 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CvBAAg5LhW/xbLJq1egm6BHm2IW7MCF?= =?us-ascii?q?wENhR5KAoF7AQEBAQEBgQuEQgEBAgIBAQEqQQoRCxgJFg8JAwIBAgEVMAYBDAY?= =?us-ascii?q?CAQGIFw60fog/AQEBAQEBAQEBAQEBAQEBAQEBAQEBFYYShDeIbAWOG4hahUyIB?= =?us-ascii?q?IIlhnyFUo4+YoQCHi6IUwEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,417,1449532800"; d="scan'208,217";a="630325991" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2016 18:54:56 +0000 Received: from [10.86.247.63] ([10.86.247.63]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u18IstQ5003622; Mon, 8 Feb 2016 18:54:55 GMT References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" , "tls@ietf.org" From: Paul Duffy Organization: Cisco Systems Message-ID: <56B8E47E.1060809@cisco.com> Date: Mon, 8 Feb 2016 13:54:54 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------060906070808050500070704" Archived-At: Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: paduffy@cisco.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: Mon, 08 Feb 2016 18:55:01 -0000 This is a multi-part message in MIME format. --------------060906070808050500070704 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I believe Thread Group is using JPAKE? http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf Best that one of the Threaders confirm Cheers On 2/8/2016 1:36 PM, Salz, Rich wrote: > > Is anyone else using JPAKE? I found old I-D, but my > search-engine-skillz must be atrophied as I can’t find any final RFC > on it. > > It’s currently “experimental” code in OpenSSL and we might drop it in > the next release. > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz@jabber.at Twitter: RichSalz > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------060906070808050500070704 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
I believe Thread Group is using JPAKE?

http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf

Best that one of the Threaders confirm

Cheers


On 2/8/2016 1:36 PM, Salz, Rich wrote:

Is anyone else using JPAKE?  I found old I-D, but my search-engine-skillz must be atrophied as I can’t find any final RFC on it.

 

It’s currently “experimental” code in OpenSSL and we might drop it in the next release.

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz

 



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

--------------060906070808050500070704-- From nobody Mon Feb 8 11:29:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05E831B3236 for ; Mon, 8 Feb 2016 11:29:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=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 oLCqiWNBEQLi for ; Mon, 8 Feb 2016 11:29:37 -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 89FB01B2D7E for ; Mon, 8 Feb 2016 11:29:37 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E42B43F400A; Mon, 8 Feb 2016 19:29:36 +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 CCFF13F4008; Mon, 8 Feb 2016 19:29:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1454959776; bh=WuaJBWJtwJr3wACaqXPSYe1adPZvpc8pbj0ccSWl8F0=; l=247; h=From:To:Date:References:In-Reply-To:From; b=f1POo6nb+DrWCiQDK2Hm6im4Go5AzNCUS9y3X9y2Jyn9fAR8TE3mHWxRbvgdj988B qoRf5cPx/o6Of42/ekzZ09SVELKNNf/Rr0IPl9KhgzK8UjKl7rE87mzMIkuKWUEX8P QcRq8HCIHVXYucG1of0UPwIDLZI6qaR/oDXWH9CM= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B95682030; Mon, 8 Feb 2016 19:29:36 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Mon, 8 Feb 2016 14:29:36 -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.1076.000; Mon, 8 Feb 2016 14:29:36 -0500 From: "Salz, Rich" To: "paduffy@cisco.com" , "tls@ietf.org" Thread-Topic: [TLS] JPAKE Thread-Index: AdFin4mfxBQVLAQiSWSYc5Z1bcPNhAALJGYAAApGpHA= Date: Mon, 8 Feb 2016 19:29:35 +0000 Message-ID: <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> In-Reply-To: <56B8E47E.1060809@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.96] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 19:29:39 -0000 > http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissio= ning%20white%20paper_v2_public.pdf Thanks. A quick skim shows it's some variant/combo of jpake-like and EC (N= ISTP256) . But hopefully they'll speak up here.=20 From nobody Mon Feb 8 11:34:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F081B3236 for ; Mon, 8 Feb 2016 11:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvUiTIGC20A0 for ; Mon, 8 Feb 2016 11:34:00 -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 B87821B2E9F for ; Mon, 8 Feb 2016 11:34:00 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B753143341B for ; Mon, 8 Feb 2016 19:33:59 +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 93171433403 for ; Mon, 8 Feb 2016 19:33:59 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1454960039; bh=HpbqsijzYDvvowvOtGB9aScpjS/QQqxR5iaAaoLNmlg=; l=2959; h=To:References:From:Date:In-Reply-To:From; b=oqFAEfWIMrzsFPT4TQN54xLgOE9OAsrHLAtRShhC0YBl0/GrX8G5RP7z8mjsZ/hgp UWn8V5GbQYp6wGMP8d9dYsR0bBBr9v99frM+TYwxAN1fKqyZwY//Ew/Io3IltRlQsr 2iH6+qwMa9i6wVHd8qozVaAFuuTQ7Lzf40Y9IncM= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 5A127202D; Mon, 8 Feb 2016 19:33:59 +0000 (GMT) To: "Salz, Rich" , "tls@ietf.org" References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> From: Benjamin Kaduk Message-ID: <56B8EDA7.4050004@akamai.com> Date: Mon, 8 Feb 2016 13:33:59 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------060208030605070208090104" Archived-At: Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2016 19:34:02 -0000 This is a multi-part message in MIME format. --------------060208030605070208090104 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit On 02/08/2016 12:36 PM, Salz, Rich wrote: > > Is anyone else using JPAKE? I found old I-D, but my > search-engine-skillz must be atrophied as I can’t find any final RFC > on it. > > JPAKE was mentioned as an option in kitten's discussions of adding PAKE preauthentication mechanisms to kerberos, but the current draft-mccallum-kitten-krb-spake-preauth is (as the title would imply) using spake and not jpake. I'd have to dig into the archives to remember why we decided that spake was better, though. -Ben --------------060208030605070208090104 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 02/08/2016 12:36 PM, Salz, Rich wrote:

Is anyone else using JPAKE?  I found old I-D, but my search-engine-skillz must be atrophied as I can’t find any final RFC on it.



JPAKE was mentioned as an option in kitten's discussions of adding PAKE preauthentication mechanisms to kerberos, but the current draft-mccallum-kitten-krb-spake-preauth is (as the title would imply) using spake and not jpake.  I'd have to dig into the archives to remember why we decided that spake was better, though.

-Ben
--------------060208030605070208090104-- From nobody Tue Feb 9 04:05:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CEE71A88FE for ; Tue, 9 Feb 2016 04:05:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 xSBk2qZU-_1H for ; Tue, 9 Feb 2016 04:05:38 -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 DFD281A8986 for ; Tue, 9 Feb 2016 04:05:37 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id p63so20100127wmp.1 for ; Tue, 09 Feb 2016 04:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=l3b8nB95toSUpuBYGjsILfAr5asok7k4mdbAcW0bVP0=; b=KbdTtf9VGsXpJg5i54tF/VTb791YAq21MZJjnLow31C9tTtieJaFeAYUuoVL1ixjLx gHPfyepe39nEa7KREt1fPPWxvpgXEsNYogY4Xm3StPnnTRe5Bj7bijg5IxNXtVY9x2MX lefEHDiVAoBT1spkJDph1AvSrgBEyzdOWF4j8wiB5unf1y/q8lmkM3mfDdYPtf/R8ijA 7dPcdglnKJ7V6P8aL9syo2iRdwetqUgqL1avkdR1sXQWGC8SBg+4wGVMhWfaaEzm7LJj fySv+E3BVyLBB3glJX4/V5oe9bDb344pJp+wWmguBJoOLPWrviLlZAGP0qjY9NoehkOT jU0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=l3b8nB95toSUpuBYGjsILfAr5asok7k4mdbAcW0bVP0=; b=ePk2c+rHK60iOT5eXyaZpxnsWAO7Z0pdqk+d8TwGRfz7Grk95vhGbr+yf4Rg6kkjBz UZBp4w2E5+YxBK9U3FwafTKBEWrMdu8Zh6KbYbtEYFtBvUQQ7SJmMPYnp4vhK+/xo7zM QtKChdQwhqNpGOoB2eEAbEARmI0LF7WAp5DRXpOgrs8ruRlcpYzwzGBx4ozLU3RigF8x igp9cKZlrkXCplDpahH600QIyhFmr3xJqkIXf8XPb5opZC5jcxlN3gDgGC0DbgI1Mw42 vha0ZYFAY94hHF6as9knNYZijEtf6qZakFmMr9FUP6KJaXziVoRoLM5byBoj/MpCgd2n jIDA== X-Gm-Message-State: AG10YOTmF74dWdsxnuEWKKW4g0OvIkiCKRHwlpRVdtGqzjMe8kMUR1rudwTIamondq3bvlyDX9mac3bnSjJWeQ== MIME-Version: 1.0 X-Received: by 10.28.217.83 with SMTP id q80mr4281586wmg.15.1455019536467; Tue, 09 Feb 2016 04:05:36 -0800 (PST) Sender: robert.cragie@gmail.com Received: by 10.194.136.163 with HTTP; Tue, 9 Feb 2016 04:05:36 -0800 (PST) In-Reply-To: <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 9 Feb 2016 12:05:36 +0000 X-Google-Sender-Auth: QRPU2nzaMRoM0pkpuF9pnDR29Xk Message-ID: From: Robert Cragie To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11468c749cd009052b552265 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.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: Tue, 09 Feb 2016 12:05:43 -0000 --001a11468c749cd009052b552265 Content-Type: text/plain; charset=UTF-8 I can confirm the Thread Group is using an EC variant of JPAKE, which we have been using in interop tests for over a year now. I have had a short presentation ready to give to TLS WG for some time but I was told it wouldn't receive much interest because it is based on TLS 1.2 and the current focus is very much on 1.3. The aim is to get an informational RFC out shortly. Robert On 8 February 2016 at 19:29, Salz, Rich wrote: > > > > http://threadgroup.org/Portals/0/documents/whitepapers/Thread%20Commissioning%20white%20paper_v2_public.pdf > > Thanks. A quick skim shows it's some variant/combo of jpake-like and EC > (NISTP256) . But hopefully they'll speak up here. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11468c749cd009052b552265 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I can confirm the Thread Group is using an EC variant of J= PAKE, which we have been using in interop tests for over a year now. I have= had a short presentation ready to give to TLS WG for some time but I was t= old it wouldn't receive much interest because it is based on TLS 1.2 an= d the current focus is very much on 1.3. The aim is to get an informational= RFC out shortly.

Robert

On 8 February 2016 at 19:29, Salz, Ri= ch <rsalz@akamai.com> wrote:
http://threadgroup.org/Portals/0/documents/whitepapers/Thread%2= 0Commissioning%20white%20paper_v2_public.pdf

Thanks.=C2=A0 A quick skim shows it's some variant/combo of jpake-like = and EC (NISTP256) .=C2=A0 But hopefully they'll speak up here.

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

--001a11468c749cd009052b552265-- From nobody Mon Feb 15 11:02:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7A101ACD27 for ; Mon, 15 Feb 2016 11:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 nkhOEKpI_kFZ for ; Mon, 15 Feb 2016 11:02:30 -0800 (PST) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003: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 ADCF91AC407 for ; Mon, 15 Feb 2016 11:02:30 -0800 (PST) Received: by mail-ob0-x22f.google.com with SMTP id gc3so123925138obb.3 for ; Mon, 15 Feb 2016 11:02:30 -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:date:message-id:subject:from:to :cc:content-type; bh=WerW/4pNtJYaJwVYUM2f7oXEMdQ5JI07A3XECF+am5k=; b=nAGaGNOZcxWzC4xT0RDmigqMF9aKrBSKxIAnaTvifPdm0ORohNTOq2Yx0FPH8RZBqc TBpHhCt0rpogR+DrtBySGdzgDwOHYUlvbVNn7B8wzB/4SewKFd+pZ3Qc0acA97CFj9QH lfTzxTi1vXsrC3VRJX5VI176mfPAClfPaI15UlRa1LLasx5cTCmot7eUewhomYU3oAQM VoseZGP3uutXftjkzozJm8JvD80iZRG96UyYRlX0J2Czsku67kwbM9HCpwAd/MYpQvfn STguQKiaCWLFuXOmep5lVn9Nff3XWon5+TKjKIfSAoWsasUjJZtJYH04W4vgzEkt3Hbq pclw== 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:date :message-id:subject:from:to:cc:content-type; bh=WerW/4pNtJYaJwVYUM2f7oXEMdQ5JI07A3XECF+am5k=; b=ZsO+XeF7HlO7eTVcMwwhq5rj9i4FeB/CumUshmZ42MngBBweyWYB8yGWZriIi9EpDI /ZuGbGxPpkOfTmseaFq4qDasJtnHZCu/RwBJFtvwpmjeeRWFtyxeDrGn88kdPDmZidS0 jui2Ya9T50oq1o8VK+BZUSMuM8olbUf4A0AtP8jdEETupxQjsMHeuJqRDFhU6S09708a xqjUjDfOb+gkfGODGdZ/jI5rPHbMwWujlm2YE7u2ocR/lfw/dDGAusV9LQTQ49gCDOey xChbRicTKBKq+iZfntlP9eoYN0eKsl6kZJw5AwQ2ATyPkysjV/CwOTVDPy6lyR8jZvmx S0Kg== X-Gm-Message-State: AG10YORs4A9bjY4J9oh/5FvtCIwnDBTahEXCC+Ot8exQNT9Y7Qc15tCWmQY6QKGKeXW5lOgAivH6M012DTlWJA== MIME-Version: 1.0 X-Received: by 10.202.190.196 with SMTP id o187mr13209747oif.105.1455562950027; Mon, 15 Feb 2016 11:02:30 -0800 (PST) Received: by 10.76.170.1 with HTTP; Mon, 15 Feb 2016 11:02:29 -0800 (PST) In-Reply-To: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Mon, 15 Feb 2016 09:02:29 -1000 Message-ID: From: Brian Smith To: robert.cragie@gridmerge.com Content-Type: multipart/alternative; boundary=001a113dc55695c7a7052bd3a89b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 19:02:31 -0000 --001a113dc55695c7a7052bd3a89b Content-Type: text/plain; charset=UTF-8 Robert Cragie wrote: > I was told it wouldn't receive much interest because it is based on TLS > 1.2 and the current focus is very much on 1.3. The aim is to get an > informational RFC out shortly. > I'm looking forward to the RFC and I would be happy to offer feedback on it before or after the first public draft is published. BTW, if someone tells you something won't receive much interest, it doesn't mean it won't receive much interest. It more likely means *they* don't want it to receive much interest. I think you might be surprised how much interest there actually is. Cheers, Brian --001a113dc55695c7a7052bd3a89b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Robe= rt Cragie <robert.cragie@gridmerge.com> wrote:
=
I was told it wouldn't = receive much interest because it is based on TLS 1.2 and the current focus = is very much on 1.3. The aim is to get an informational RFC out shortly.

I'm looking forward to the RFC and = I would be happy to offer feedback on it before or after the first public d= raft is published.

BTW, if someone tells you somet= hing won't receive much interest, it doesn't mean it won't rece= ive much interest. It more likely means *they* don't want it to receive= much interest. I think you might be surprised how much interest there actu= ally is.

Cheers,
Brian
--001a113dc55695c7a7052bd3a89b-- From nobody Mon Feb 15 11:54:18 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E33A1ACD48 for ; Mon, 15 Feb 2016 11:54:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb2A4LgX3Xc8 for ; Mon, 15 Feb 2016 11:54:15 -0800 (PST) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A6D31ACD38 for ; Mon, 15 Feb 2016 11:54:15 -0800 (PST) Received: by mail-yk0-x231.google.com with SMTP id z7so64271531yka.3 for ; Mon, 15 Feb 2016 11:54:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=5D285jRJyomeW+zlvlo/yZvp2WAZkePtLYcJDBLNgXc=; b=dVOvooLyu6dt/WxDVlxJmNP2Ik0bMpkyUoF/DJmWiAYpyoW0AWCGqakASOliYjGLkN w5RJXigT5+iPU29naXXyNSa0SbANLcrD/aQRyJx+A2PhDIdA5jINP3BqM/z6eBIKzwL3 0hopU6IOLL1reDhSUlYcEXJY7ICdU20ko5MuLQAEGbQXsJZqsceqla/oYNtGGsxrXUQW pEFD7TlmvFwNjc3ZGu8A+GfV2ed2sh/XN20PNrc4RM4VyvwBj5dQtMPTIT9a68OcQfj/ U8awnzd0/8lIbUWP3B8Mr45QM7YXISS1GWVR5txQ6/NqFDxHsqdatk0ZiAOQYZnaidar UlZg== 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:date :message-id:subject:from:to:cc:content-type; bh=5D285jRJyomeW+zlvlo/yZvp2WAZkePtLYcJDBLNgXc=; b=Yq7uo/0leUStmWFVDUJHCCouUQpKxpll/hul5SfztZlWDuD9JEFQdWhNWdJTl0Jrjm QxcxQ+H139WB+xjZi2gvK6OklBLwS2QFqcMXwxio7ZbLkwn6VyLDLQkkyzsjYQWrB4DP KhlzwQJ+nbHSrOwDOz9alSY54lBOBo+pKkWejZWnqPd/ggxSYVjiOY522Nh108Ni9o77 sm0epV+DAvQvYgd2yzCFL9hsPjiGLXLnqZXhwbpRVCxnAbrUTIpo4XYX7sbTlP8Q11iu 6JOYgM2jAIxDmpoYjPvYJ4aOf8ygD0Ee4wv5soifXBx4LP5vrjgeApglPFwEObSFRXaz zN+Q== X-Gm-Message-State: AG10YOTMX8FlENjC5cYzFzZ4sQzOEUsVVoV4CBSpWshFJuPkxt3F4bN8KFL8L8G9tiWabIAmReUaW6jkgPan7g== MIME-Version: 1.0 X-Received: by 10.37.81.137 with SMTP id f131mr10002636ybb.54.1455566054289; Mon, 15 Feb 2016 11:54:14 -0800 (PST) Received: by 10.13.216.138 with HTTP; Mon, 15 Feb 2016 11:54:14 -0800 (PST) In-Reply-To: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Mon, 15 Feb 2016 11:54:14 -0800 Message-ID: From: Watson Ladd To: Brian Smith Content-Type: multipart/alternative; boundary=001a113dd1fe9cfdcd052bd46148 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 19:54:17 -0000 --001a113dd1fe9cfdcd052bd46148 Content-Type: text/plain; charset=UTF-8 On Feb 15, 2016 11:02 AM, "Brian Smith" wrote: > > Robert Cragie wrote: >> >> I was told it wouldn't receive much interest because it is based on TLS 1.2 and the current focus is very much on 1.3. The aim is to get an informational RFC out shortly. > > > I'm looking forward to the RFC and I would be happy to offer feedback on it before or after the first public draft is published. > > BTW, if someone tells you something won't receive much interest, it doesn't mean it won't receive much interest. It more likely means *they* don't want it to receive much interest. I think you might be surprised how much interest there actually is. At the time this work was being done JPAKE had a rather sorry excuse for a security proof. It's only recently that a solid one has been created. At the same time SRP did not receive much usage when included in OpenSSL, and with an RFC describing it. PAKE in SSL has always been a solution in search of a problem. > > Cheers, > Brian > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113dd1fe9cfdcd052bd46148 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 15, 2016 11:02 AM, "Brian Smith" <brian@briansmith.org> wrote: >
> Robert Cragie <robert.cragie@gridmerge.com> wrote:
>>
>> I was told it wouldn't receive much interest because it is bas= ed on TLS 1.2 and the current focus is very much on 1.3. The aim is to get = an informational RFC out shortly.
>
>
> I'm looking forward to the RFC and I would be happy to offer feedb= ack on it before or after the first public draft is published.
>
> BTW, if someone tells you something won't receive much interest, i= t doesn't mean it won't receive much interest. It more likely means= *they* don't want it to receive much interest. I think you might be su= rprised how much interest there actually is.

At the time this work was being done JPAKE had a rather sorr= y excuse for a security proof. It's only recently that a solid one has = been created. At the same time SRP did not receive much usage when included= in OpenSSL, and with an RFC describing it. PAKE in SSL has always been a s= olution in search of a problem.

>
> Cheers,
> Brian
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

--001a113dd1fe9cfdcd052bd46148-- From nobody Mon Feb 15 14:32:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8FF81A1A04 for ; Mon, 15 Feb 2016 14:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJL8d3oKLeuy for ; Mon, 15 Feb 2016 14:32:34 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 7A7911A1A02 for ; Mon, 15 Feb 2016 14:32:34 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id hb3so60958945igb.0 for ; Mon, 15 Feb 2016 14:32: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:content-type; bh=tW+G60DVqacrBerm/BgDQcNK3/1aEEEo+pmcELdwk70=; b=Vnit1P1fGzHeqB+7NF+fP7HKnxgEmWgmZFqbEnQ4H1CPiFIni9HwdbDya5emtzodIQ 0A5pCENGhxjmlN4Ce6Q0XAcdjE66IQEgnYI7NCbGXJhBx5gGkpyr+9yVElsFszzzIGRQ wzGC22jfEt8G3jjvjTxmKsHsSZQKcLCXSrGPzHHZhaDB8ciX0wWF1il009o5o+cSwC/s shVxEaMx0xkCV8YWobmHpnk1Pes8kr+eLueeMW+R8pGlZji3iaS/aCaATv0YCvP0uizE 5Myk9tEnw2CO3Ag9u7xfFpjJEdIhwY9c3Tj6DAztQrlVJV/SDuiOoH4VBw9z4cP9PdTL T2Qg== 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-type; bh=tW+G60DVqacrBerm/BgDQcNK3/1aEEEo+pmcELdwk70=; b=m2Edp1r8qh+FwGgWWdMnmqSoZilvXhf3e3YBfJiooQsx8ynPJdyeUvKbNO1NLdm5dx tcCUVm02kvjZ8mn0hCISKtS1CbLStiyOqcEjbY94ahPvkh3dkE2xYYSkc7u6Ur8Q6oA4 yqAJOC/ZNXL81325maS/jVlawBzY977dFUFUnxQfGPNBIiJvnJS7FdgNMvYHP2GzWGGA 6DxYrmtCgW5NiFoOUwFxfN7rdACNBG1FREGwu5dp1PBnAjnIGTn/1H30qCPsf1RWddB5 1ZMuD7MJexP+UhxTNTydMFNeYQuzg7N6H0Swf+1St895Odb00fL7JN9ITnrtVG8PUAxU LNog== X-Gm-Message-State: AG10YOR/3jLzLPcyOqw7WUulqwKB/qjqxFvW7+ZdUvvjUSRzB1PxNqEXhagYRf214a0PIMldNHV1w+OFGOMhJA== X-Received: by 10.50.64.146 with SMTP id o18mr14114134igs.51.1455575553890; Mon, 15 Feb 2016 14:32:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.124.201 with HTTP; Mon, 15 Feb 2016 14:32:14 -0800 (PST) In-Reply-To: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> From: Tony Arcieri Date: Mon, 15 Feb 2016 14:32:14 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=047d7bea43fcd56282052bd69740 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Feb 2016 22:32:36 -0000 --047d7bea43fcd56282052bd69740 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 15, 2016 at 11:54 AM, Watson Ladd wrote: > PAKE in SSL has always been a solution in search of a problem. > Browsers do not have UI elements compatible with PAKE (unless someone cares to bring up the basic auth dialog, in which case I'd simply suggest please don't) Brian Warner's "Magic Wormhole" use case seems like something of a killer app for PAKE, but that's clearly a non-SSL context. PAKE in SSL seems to be in need of new browser standards which are probably unlikely to happen. I think "passwordless" standards like FIDO UAF/U2F which offer a better user experience are far more likely to see browser support. --047d7bea43fcd56282052bd69740 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 15, 2016 at 11:54 AM, Watson Ladd <watsonbladd@gmail.com&g= t; wrote:

PAKE in SSL has always been a solution in search o= f a problem.

Browsers do not have UI elem= ents compatible with PAKE (unless someone cares to bring up the basic auth = dialog, in which case I'd simply suggest please don't)
Brian Warner's "Magic Wormhole" use case seems l= ike something of a killer app for PAKE, but that's clearly a non-SSL co= ntext.

PAKE in SSL seems to be in need of new = browser standards which are probably unlikely to happen. I think "pass= wordless" standards like FIDO UAF/U2F which offer a better user experi= ence are far more likely to see browser support.
--047d7bea43fcd56282052bd69740-- From nobody Mon Feb 15 16:34:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7961B2A78 for ; Mon, 15 Feb 2016 16:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 Eo4-ftZMn0ZU for ; Mon, 15 Feb 2016 16:33:58 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D1C61B2A68 for ; Mon, 15 Feb 2016 16:33:58 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id g62so130131196wme.0 for ; Mon, 15 Feb 2016 16:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=jEypUSi9wQRPWrgdxVCPeQ9pRjFIWIgOzOWIySuGVsg=; b=JWnQ+3esUDGXeu22xEVjfpKEzEhE8jaCuCPN2tZY/u91fW1QAaXYcsah39r6jkhnMO EsnnQaKn9XiufgQcheSrpFG+G8jJS/UOM/hjnJOxHK7ZA3lCPbtEvCdAORBN6hq56Zr4 1C1FXIX1lQJrILeNqwTm2VD2y/V25162gzt01GJXS+EEtCAu1lA+0l1XRe1w7Zo/1C9L LQ1i7VN5P9yuRTzOhOWfyiP+jk0x+toytNMtjeq95dtmTv9TCltbb9dsr5uknLLqt/mV LDBoFtmnvQ2Szb0ZCJDFGSX8hHmhXBtH3aq22pX2XxAoypogtzfwfD7gT2IDI8d5EO0X ml7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=jEypUSi9wQRPWrgdxVCPeQ9pRjFIWIgOzOWIySuGVsg=; b=mlev+3Y00wrI0TmlkJeyDBbLb8SQ70tX9p88BpmPreHbMRZbnDw0JqWBBdlsZ2JJMt 0WLKK07BYSwzyNeYstJuOLdtE87nYQr4SvZvrtSPbmYioRjEgi0AnuQC6k+mLvRvlJQl S9e4AhzUYWOK1nUfXaNPo/WPdbhVZ/bOBIzn8AiqjdAIKcxa/whN4fDd093fVGvccLa0 kPXJdb+ANXbaGnhNfiRx/VqkPsQD2Cxi9p0rAlSowHEGhkuh2sOqbxJXtKQXaTkzhcvb U9+FJIViOHqp6ScNIWGYEid090ubxdr9JQjpdWNVV2ItY+ojdJmRf9I8n7QnxcxNKHI2 Gebw== X-Gm-Message-State: AG10YOQnrzgxMzdTxFAm6I+2LJw3TOvaiFbgL02JMe5Lz8hL7lg8ssX/8l3sHSW7Czs7LGhqp6dPR+CJ/FkO+Q== MIME-Version: 1.0 X-Received: by 10.194.81.103 with SMTP id z7mr18606688wjx.25.1455582836835; Mon, 15 Feb 2016 16:33:56 -0800 (PST) Sender: robert.cragie@gmail.com Received: by 10.194.136.163 with HTTP; Mon, 15 Feb 2016 16:33:56 -0800 (PST) In-Reply-To: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 16 Feb 2016 00:33:56 +0000 X-Google-Sender-Auth: ciBPX1rp5dZpmWlMsA7JnFvIanE Message-ID: From: Robert Cragie To: Tony Arcieri Content-Type: multipart/alternative; boundary=047d7bf0d1d6ee4e03052bd8497b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.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: Tue, 16 Feb 2016 00:34:00 -0000 --047d7bf0d1d6ee4e03052bd8497b Content-Type: text/plain; charset=UTF-8 The big assumption here is that SSL/TLS is used solely in browsers. That is not how it is being used in Thread, for example, and indeed in other similar technologies. In Thread, it is used for local device authentication and authorisation. These use cases clearly benefit from a PAKE, i.e. getting deriving a shared cryptographic from a weaker shared password. Robert On 15 February 2016 at 22:32, Tony Arcieri wrote: > On Mon, Feb 15, 2016 at 11:54 AM, Watson Ladd > wrote: > >> PAKE in SSL has always been a solution in search of a problem. >> > Browsers do not have UI elements compatible with PAKE (unless someone > cares to bring up the basic auth dialog, in which case I'd simply suggest > please don't) > > Brian Warner's "Magic Wormhole" use case seems like something of a killer > app for PAKE, but that's clearly a non-SSL context. > > PAKE in SSL seems to be in need of new browser standards which are > probably unlikely to happen. I think "passwordless" standards like FIDO > UAF/U2F which offer a better user experience are far more likely to see > browser support. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --047d7bf0d1d6ee4e03052bd8497b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The big assumption here is that SSL/TLS is used solely in = browsers. That is not how it is being used in Thread, for example, and inde= ed in other similar technologies. In Thread, it is used for local device au= thentication and authorisation. These use cases clearly benefit from a PAKE= , i.e. getting deriving a shared cryptographic from a weaker shared passwor= d.

Robert

On 15 February 2016 at 22:32, Tony Arcieri &l= t;bascule@gmail.com<= /a>> wrote:
On Mon= , Feb 15, 2016 at 11:54 AM, Watson Ladd <watsonbladd@gmail.com>= wrote:

PAKE in SSL has always been a solution in search of a problem.<= /p>

Browsers do not have UI elements c= ompatible with PAKE (unless someone cares to bring up the basic auth dialog= , in which case I'd simply suggest please don't)

Brian Warner's "Magic Wormhole" use case seems like so= mething of a killer app for PAKE, but that's clearly a non-SSL context.=

PAKE in SSL seems to be in need of new browse= r standards which are probably unlikely to happen. I think "passwordle= ss" standards like FIDO UAF/U2F which offer a better user experience a= re far more likely to see browser support.

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


--047d7bf0d1d6ee4e03052bd8497b-- From nobody Mon Feb 15 16:39:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5331B29A3 for ; Mon, 15 Feb 2016 16:39:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPJVKTZVggnS for ; Mon, 15 Feb 2016 16:39:26 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 C72D31A8A54 for ; Mon, 15 Feb 2016 16:39:26 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id 5so66956623igt.0 for ; Mon, 15 Feb 2016 16:39:26 -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-type; bh=vW02KdLtQ1rE2UFDhRfyPwVXXqBGAEkK/ex6Cv52v3Y=; b=09O9WTS6PsbQoKTgBBB5LZUO3oOdt13BDbixI+aLPYpMFGqrp3NZV94YhdcXGlaWFq YMKJOfQXRACNJaIjrZCaCKRA1g+6QwbyhB8Mu5habHiVwP2Z4rSvv77vIcM5MRkciDWb svOTv72CbuFNNMNqxqmmsf1efKFxSW0qjYevyblzFdT2g/5eiUBbfUmVU9sn50rkZouy MAswPliugA887843aeHhJZ43nxZ1ytkYbPmVLf4yuSNPd/P8QxcRbRbYVD1FIwPzqnKO qO91HxBJx9c1aIh+TEDR1SLTiQ2R2EZUAmwlLnq19UU2rzKlgZpVXkxfPiPdleZ4W7Wj p59w== 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-type; bh=vW02KdLtQ1rE2UFDhRfyPwVXXqBGAEkK/ex6Cv52v3Y=; b=eSdPJsaln4jpTrNW4otfAoYVlhF3ktFhMwg3mTYekDGtp4DwJ/ToxJUz+Cqi49f1gl 0z0PBA1afV+TNM71/nruMT7bsleKX+jpZkk4Ynh2bqLsdeE1u1A1rmyvx2CpRi6XIFCB IakYahFYIQs2tJIQirRybfQQ6/67rpamoL7N7iAYvdEhTRsff9nM0we/5TpwxvQG6wtz pmvhGKFBxiSeZfVc4g+YisDMqsohC/cx/PKfypO1ExC8Ua0+scpIJzMnqZg4pHAvI+Xc 24QseGVGJakWquprD/tZQ0PDYid98/fip63VqYwaJS7tEd0L3C4o9c4BGi1uFJ6/rZzN lgog== X-Gm-Message-State: AG10YOQY3h8ytrZVQIh6IytORGe4vb/vQwjBLNLrxidJMZyLI+ZmY5my9NrpEK390aeyVNmwLFaTnPQgP7OCbA== X-Received: by 10.50.160.11 with SMTP id xg11mr14526923igb.51.1455583166305; Mon, 15 Feb 2016 16:39:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.124.201 with HTTP; Mon, 15 Feb 2016 16:39:06 -0800 (PST) In-Reply-To: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> From: Tony Arcieri Date: Mon, 15 Feb 2016 16:39:06 -0800 Message-ID: To: robert.cragie@gridmerge.com Content-Type: multipart/alternative; boundary=001a1135e238919e7a052bd85da8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 00:39:28 -0000 --001a1135e238919e7a052bd85da8 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie wrote: > The big assumption here is that SSL/TLS is used solely in browsers. > In literally every one of the non-browser SSL/TLS contexts I use today, I do not use passwords (preferring client certs instead). The main place I'd actually be interested in using a PAKE in a generalized transport context would be an IPSEC/IKE context (in addition to a client cert as a second factor). -- Tony Arcieri --001a1135e238919e7a052bd85da8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 15, 2016 at 4:33 PM, Robert Cragie <robert.cragie@gridme= rge.com> wrote:
The big assumption here is that SSL/TLS is used solely in browsers.

In literally every one of the non-brow= ser SSL/TLS contexts I use today, I do not use passwords (preferring client= certs instead). The main place I'd actually be interested in using a P= AKE in a generalized transport context would be an IPSEC/IKE context (in ad= dition to a client cert as a second factor).

-- <= br>
Tony Arcieri
--001a1135e238919e7a052bd85da8-- From nobody Tue Feb 16 13:26:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AF651A1F73 for ; Tue, 16 Feb 2016 13:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=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 e4XJIvkaaXf4 for ; Tue, 16 Feb 2016 13:25:58 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD0D1B2AE3 for ; Tue, 16 Feb 2016 13:25:57 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8C49120002D; Tue, 16 Feb 2016 21:25:56 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 7696C200029; Tue, 16 Feb 2016 21:25:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1455657956; bh=Q1J5CH2Grjb23WDTPAJt3DUn8tP9LA/0JQQrbizZnhA=; l=132; h=From:To:CC:Date:References:In-Reply-To:From; b=QpkapUV6W5IoHWakRConaPEyTkApdhnIJobNivICngWLYKxgrJtClssMY20zYzaok U82X/s1a/pih/w3ZmcEieE2IxqKkLEZ7HY2osvmxg7qqw7LYQPxY8W47kW70m3mis0 BaOUnI2MKShBBwUzuIqN1KUzAk9O9zliw+Z4ZQv4= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 72AF71E07C; Tue, 16 Feb 2016 21:25:56 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 16 Feb 2016 15:25:56 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1076.000; Tue, 16 Feb 2016 15:25:56 -0600 From: "Salz, Rich" To: Watson Ladd , Brian Smith Thread-Topic: [TLS] JPAKE Thread-Index: AdFin4mfxBQVLAQiSWSYc5Z1bcPNhAALJGYAAApGpHAAG9D6AAE8TtmAAAHOrgAAKOExEA== Date: Tue, 16 Feb 2016 21:25:56 +0000 Message-ID: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.40] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2016 21:26:01 -0000 PiBQQUtFIGluIFNTTCBoYXMgYWx3YXlzIGJlZW4gYSBzb2x1dGlvbiBpbiBzZWFyY2ggb2YgYSBw cm9ibGVtLg0KDQpJIGtpbmRhIGFncmVlIHdpdGggdGhpcy4NCg== From nobody Tue Feb 16 20:05:46 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EEB21AD37C for ; Tue, 16 Feb 2016 20:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4sGSeMi4QTHS for ; Tue, 16 Feb 2016 20:05:42 -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 26B081AD36F for ; Tue, 16 Feb 2016 20:05:42 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id e63so4029591ywc.3 for ; Tue, 16 Feb 2016 20:05:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qcaJkPxSVxCcNNAvauKo2xCT8xrnljTKtB8Pn9oRMQ4=; b=US1dDNZGw/3rb2dSLH9+hMX6NHsaDSMS8djO7h4Uy1pfRkQ5kEgJjKWTtnFwOw9CeI SwQHwSAaoAXcrh7Y4mdbdRp5HrKQO8MNDJsW31UZ/ZewRhYEmAXnkPNMB5/p6MlKsG8I rIXVPpAiXeMnB3w7HrtQE6EAnsDU7tk4l5E6K5Gl3zySW4c5EMTbaJMpUetdYwGA2smu cdDiK9xude179fH86I+nWemG0IBo2zxMJv5PDRNtztTkq2suLgD8+VUDkk7676bSWK3y 9iCo9bllQK2FRmwFEaUtTFN996a1Whf4liqwRXhHoXt0Q48TpRf51Hx1d1mcob+Isi6r Tv3A== 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:date :message-id:subject:from:to:cc:content-type; bh=qcaJkPxSVxCcNNAvauKo2xCT8xrnljTKtB8Pn9oRMQ4=; b=BIvNu9zfgu0Ng0oZFc1kucpZX5XmsuGRIZFXYpi4ijKal0VjR2JDkY/OZjo9SAHM2N qvO9uA5A6OVTiNzkie3AvIF9Gc4YCsDiNincz96ah8pQ4uRvytC4Wld+tAlN8pMIKzLm gBJGAZdfpih+UPbvsH1RSKPaQ/Q2rNHbnSF7U4/FeTmpVxHJeUW/I7wGx+EJvfebd6X+ axpvcHMDLapvQGH+s0TN2zLKgXpumnzfMyGYpKLXuAkDa3fx5SkMS/UBcYDjnAqn7PwP SHIgx4v6HuW+M4s/8rlU3Q0iuYItjfmQTTwQB08mIRn3O8Q3JBYjT9A0W0G8SSWplh8x yN2g== X-Gm-Message-State: AG10YORuns+OBtHutWOzK24oN/WbH5tPoqaArwB6bDDuRgf1e9kmaWyyXoOirTD9BHYT8KYsCta1zkwrL8KQkw== MIME-Version: 1.0 X-Received: by 10.13.229.71 with SMTP id o68mr14617253ywe.326.1455681941334; Tue, 16 Feb 2016 20:05:41 -0800 (PST) Received: by 10.13.216.138 with HTTP; Tue, 16 Feb 2016 20:05:41 -0800 (PST) In-Reply-To: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 16 Feb 2016 20:05:41 -0800 Message-ID: From: Watson Ladd To: Robert Cragie Content-Type: multipart/alternative; boundary=94eb2c07ef4a050300052bef5d35 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 04:05:44 -0000 --94eb2c07ef4a050300052bef5d35 Content-Type: text/plain; charset=UTF-8 On Feb 15, 2016 4:33 PM, "Robert Cragie" wrote: > > The big assumption here is that SSL/TLS is used solely in browsers. That is not how it is being used in Thread, for example, and indeed in other similar technologies. In Thread, it is used for local device authentication and authorisation. These use cases clearly benefit from a PAKE, i.e. getting deriving a shared cryptographic from a weaker shared password. There is no reason not to use keys here and present short fingerprints to users, unless I am missing something. > > Robert > > On 15 February 2016 at 22:32, Tony Arcieri wrote: >> >> On Mon, Feb 15, 2016 at 11:54 AM, Watson Ladd wrote: >>> >>> PAKE in SSL has always been a solution in search of a problem. >> >> Browsers do not have UI elements compatible with PAKE (unless someone cares to bring up the basic auth dialog, in which case I'd simply suggest please don't) >> >> Brian Warner's "Magic Wormhole" use case seems like something of a killer app for PAKE, but that's clearly a non-SSL context. >> >> PAKE in SSL seems to be in need of new browser standards which are probably unlikely to happen. I think "passwordless" standards like FIDO UAF/U2F which offer a better user experience are far more likely to see browser support. >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > --94eb2c07ef4a050300052bef5d35 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 15, 2016 4:33 PM, "Robert Cragie" <robert.cragie@gridmerge.com> wrote:
>
> The big assumption here is that SSL/TLS is used solely in browsers. Th= at is not how it is being used in Thread, for example, and indeed in other = similar technologies. In Thread, it is used for local device authentication= and authorisation. These use cases clearly benefit from a PAKE, i.e. getti= ng deriving a shared cryptographic from a weaker shared password.

There is no reason not to use keys here and present short fi= ngerprints to users, unless I am missing something.

>
> Robert
>
> On 15 February 2016 at 22:32, Tony Arcieri <bascule@gmail.com> wrote:
>>
>> On Mon, Feb 15, 2016 at 11:54 AM, Watson Ladd <watsonbladd@gmail.com> wr= ote:
>>>
>>> PAKE in SSL has always been a solution in search of a problem.=
>>
>> Browsers do not have UI elements compatible with PAKE (unless some= one cares to bring up the basic auth dialog, in which case I'd simply s= uggest please don't)
>>
>> Brian Warner's "Magic Wormhole" use case seems like = something of a killer app for PAKE, but that's clearly a non-SSL contex= t.
>>
>> PAKE in SSL seems to be in need of new browser standards which are= probably unlikely to happen. I think "passwordless" standards li= ke FIDO UAF/U2F which offer a better user experience are far more likely to= see browser support.
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org=
>> https://www.ietf.org/mailman/listinfo/tls
>>
>

--94eb2c07ef4a050300052bef5d35-- From nobody Tue Feb 16 20:35:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9C111B2B24 for ; Tue, 16 Feb 2016 20:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGf9UldbzpzC for ; Tue, 16 Feb 2016 20:34:57 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DD31B2B12 for ; Tue, 16 Feb 2016 20:34:57 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id z135so22471124iof.0 for ; Tue, 16 Feb 2016 20:34:57 -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-type; bh=+ZSBlYpZO6F69rPnCY/6sEC3iyjggTlMsxpukI4Qvxc=; b=G1OLqMyGU8IxrRGwlw/2evBo2JlqAKJGSVKeb9fznvPTHw+3U6O6+SpRN1rhDr6dUY Sq3N4//tsIpn/i23+kDiVH0vlcQjBzK+lm0q9nUVLczTpHzH0Rinxk9IJ8lrMOGSLuy3 xrkYyXcKhB9Dur2+9M53UhGLCq1uoC2cgMpyUzEIvTTf97dmVYPIpnR902l3b7iyz/9x cN1AU6XfQslZgoPfUCS7cvMeGV8JunHpPYAPHI3twusLRSRjjIpxZtzrBmuv1H0pbIx7 AGdQeV4B0VtI1YqrFQnPpptLdl+nRm7qKTXkOuua8CysD3SSXiu+2pBG/+2Tjw4kJrlD HlVA== 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-type; bh=+ZSBlYpZO6F69rPnCY/6sEC3iyjggTlMsxpukI4Qvxc=; b=lHZ07og/ophUSL3eFuaZ5I1lWwKjs16lA8YgFGd6lZaKO+KTC8SEtxPU4u+1ARnZlh 8hwsj95JTmfvurTlo8O3PLfLeY+se4cK9LEh/ZaHJ9e5MyrsG3/2kCEJ69mVrk38L5vl 8KnrnRyTP1swkzAjTTnpsKAWh3BKt0i6/lIj1/X1p8hWZHMcAoq0HfPru1GzNxJcetbx Gb22kzSROOLA4tTJWM5H5SNRE1jh/4/HCK70uIgxD1mfJide80jB5fSHV/99VcEb7o8X 9s+wsIDOO8rIDzh7IvhNZrb7noQgF6+jt6VGo1rPwMgihPcnIHnNYkQcseclBvGSiYYd wMmg== X-Gm-Message-State: AG10YOSI3udXQkscPbvPSczzl2hyrKtv32DV3YjVWWnsc/RNc3OYPptWqvDQ+CDUo4dnIKJvvptipUU1WZoBNA== X-Received: by 10.107.134.12 with SMTP id i12mr1237229iod.74.1455683696558; Tue, 16 Feb 2016 20:34:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.124.201 with HTTP; Tue, 16 Feb 2016 20:34:37 -0800 (PST) In-Reply-To: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> From: Tony Arcieri Date: Tue, 16 Feb 2016 20:34:37 -0800 Message-ID: To: Robert Cragie Content-Type: multipart/alternative; boundary=001a113ecb76a389bf052befc502 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 04:34:59 -0000 --001a113ecb76a389bf052befc502 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie wrote: > In Thread, it is used for local device authentication and authorisation. > These use cases clearly benefit from a PAKE, i.e. getting deriving a shared > cryptographic from a weaker shared password. > The better way to solve this problem is a device-specific "keychain", which possibly loops in some sort of secure enclave for decrypting secrets, and can authorize secret decryption based on the requesting app, derive a strong master secret from a weak password/pin (possibly using a PUF for anti-tamper). This is becoming a standard feature of the OSes on most devices humans actually physically interact with, e.g. most smartphones, tablets, and any OS you'd find on a laptop. If you have this sort of keychain system, you can provision secrets on-the-fly, e.g. origin-bound certificates. Now you don't need PAKE. --001a113ecb76a389bf052befc502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Feb 15, 2016 at 4:33 PM, Robert Cragie <robert.cragie@gridme= rge.com> wrote:
In Thread, it is used for local device authentication and authorisati= on. These use cases clearly benefit from a PAKE, i.e. getting deriving a sh= ared cryptographic from a weaker shared password.
The better way to solve this problem is a device-specific &quo= t;keychain", which possibly loops in some sort of secure enclave for d= ecrypting secrets, and can authorize secret decryption based on the request= ing app, derive a strong master secret from a weak password/pin (possibly u= sing a PUF for anti-tamper). This is becoming a standard feature of the OSe= s on most devices humans actually physically interact with, e.g. most smart= phones, tablets, and any OS you'd find on a laptop.

If you have this sort of keychain system, you can provision secrets o= n-the-fly, e.g. origin-bound certificates. Now you don't need PAKE.=C2= =A0
--001a113ecb76a389bf052befc502-- From nobody Tue Feb 16 22:45:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A94411B2D29 for ; Tue, 16 Feb 2016 22:45:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5kxei0Vl8JLM for ; Tue, 16 Feb 2016 22:45:24 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 31B3B1B2C28 for ; Tue, 16 Feb 2016 22:45:24 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 531D010224074; Tue, 16 Feb 2016 22:45:23 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Tue, 16 Feb 2016 22:45:23 -0800 (PST) Message-ID: <9352e83d67d8a90a4a26f575127e43b1.squirrel@www.trepanning.net> In-Reply-To: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Tue, 16 Feb 2016 22:45:23 -0800 (PST) From: "Dan Harkins" To: "Tony Arcieri" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 06:45:25 -0000 On Tue, February 16, 2016 8:34 pm, Tony Arcieri wrote: > On Mon, Feb 15, 2016 at 4:33 PM, Robert Cragie > > wrote: > >> In Thread, it is used for local device authentication and authorisation. >> These use cases clearly benefit from a PAKE, i.e. getting deriving a >> shared >> cryptographic from a weaker shared password. >> > > The better way to solve this problem is a device-specific "keychain", > which > possibly loops in some sort of secure enclave for decrypting secrets, and > can authorize secret decryption based on the requesting app, derive a > strong master secret from a weak password/pin (possibly using a PUF for > anti-tamper). This is becoming a standard feature of the OSes on most > devices humans actually physically interact with, e.g. most smartphones, > tablets, and any OS you'd find on a laptop. What?!? How is that "better"? Having a "keychain" that loops in some vague "secure enclave" that makes authorization decisions based on some app deriving a "strong master secret from a weak password/pin" sounds complicated, has more moving parts and more possibility of things going wrong. If there's some password/pin involved then the protocol should not depend on whether it's weak or not. Period. That means PAKE. Regarding JPAKE, it's support in OpenSSL is in the apps directory, not the ssl directory. That is, there is no TLS ciphersuite that supports it and that means no app can use it (except through system() calls or some such ugliness). TLS-pwd is defined as a TLS ciphersuite though. Dan. > If you have this sort of keychain system, you can provision secrets > on-the-fly, e.g. origin-bound certificates. Now you don't need PAKE. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Feb 16 22:52:40 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1661AC3D4 for ; Tue, 16 Feb 2016 22:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYCLNYGxpuoJ for ; Tue, 16 Feb 2016 22:52:38 -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 192E81A92EB for ; Tue, 16 Feb 2016 22:52:37 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id l127so26838933iof.3 for ; Tue, 16 Feb 2016 22:52: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:content-type; bh=HSas+JQSiErUFL3jY2vImgCW0AAGzi8X9HipkaEIghU=; b=mZTx/Q6HEbK/sARFaZjm1GroGd4y7U4XjvE9/ON7BTye0hHjI4gsnxbRjnHlNUf9ma xw2nsXJEUPrPph4NNgSkJ8g/WsEkFgm1RDRKzL4944M3sGeDOkuB7BbXqdmRnqXtZnu7 39qmsb9Ua19HBDRjRmPxrA3dG0sO68XW3lxTfcUJEGEolBuGBvKmkpKTrZCeGABkx7UU zYAFWt0BjQcWovjVFSuyRBwWGivo41i4wO89Xph5ekRHu74sX4GuXtNeLtwyfux36MgO Z0ROyI0qpAkzls788rN7RztyFcZJhEhOi11ZWCdUD2JkjB7JK1Ez4wBO3XyeEB7JB/nv Gs5w== 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-type; bh=HSas+JQSiErUFL3jY2vImgCW0AAGzi8X9HipkaEIghU=; b=P6ZrlJah20sTu/9E50+1NQgsyAM4eCyK98hCIcunOZ0Q2xJUODIYtW8+MMkas61emj 4ORmYIOUDJoSOwq/eK+ganTZ41gDNvEY/vAZfkRiQndvwdkDV62jIq+DHkG15Ln2KMDC 5zVV+CFADFEIDkkMN5Cxx3BCksP6iAc+tcR7aDwclCUcvFsD/wc1vTsilgtcJ/bVz2jL gSQIy+XjaUtnavzkGeK2mB51MjbHX4+A2senM1/yT17Ga9ayckn65y/nZaU1guyPW7Fl nQkSXuETwEYSuXbxYFPfCgmeEfCBdhdnsLP7N3hyFF4d4ulCrXDtgxm613fSdZk8G5zs AqUg== X-Gm-Message-State: AG10YORYuyTeTzNCemSd5agtOVy+uGEYbF+405rDt87OkR7PxA0tx9ktNBrbd6+NgeOw70PtXAA/1WH/RApb4w== X-Received: by 10.107.134.12 with SMTP id i12mr1710873iod.74.1455691957368; Tue, 16 Feb 2016 22:52:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.124.201 with HTTP; Tue, 16 Feb 2016 22:52:17 -0800 (PST) In-Reply-To: <9352e83d67d8a90a4a26f575127e43b1.squirrel@www.trepanning.net> References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> <9352e83d67d8a90a4a26f575127e43b1.squirrel@www.trepanning.net> From: Tony Arcieri Date: Tue, 16 Feb 2016 22:52:17 -0800 Message-ID: To: Dan Harkins Content-Type: multipart/alternative; boundary=001a113ecb76057d8f052bf1b2b9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 06:52:40 -0000 --001a113ecb76057d8f052bf1b2b9 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 16, 2016 at 10:45 PM, Dan Harkins wrote: > What?!? How is that "better"? Having a "keychain" that loops in some > vague "secure enclave" that makes authorization decisions based on some > app deriving a "strong master secret from a weak password/pin" sounds > complicated Microsoft: https://technet.microsoft.com/en-us/library/mt621546(v=vs.85).aspx Matt Green: https://twitter.com/matthew_d_green/status/699777680728842240 Apple: https://www.apple.com/business/docs/iOS_Security_Guide.pdf (see also: Matt Green) Hardware interlocks around authentication allow various anti-brute force, exponential backoff, and device wiping security measures. They also allow you to unlock a "full entropy" cryptographic key with some low entropy mechanism like a PIN without the former being deterministically derived from the latter. I personally believe the future of authentication is having a weak credential which unlocks a strong credential on something you have. This approach to authentication is generally described as "something you have and something you know" -- Tony Arcieri --001a113ecb76057d8f052bf1b2b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 16, 2016 at 10:45 PM, Dan Harkins <dharkins@lounge.org> wrote:
What?!? How is that "better"? Ha= ving a "keychain" that loops in some
vague "secure enclave" that makes authorization decisions based o= n some
app deriving a "strong master secret from a weak password/pin" so= unds
complicated


Hardware interl= ocks around authentication allow various anti-brute force, exponential back= off, and device wiping security measures. They also allow you to unlock a &= quot;full entropy" cryptographic key with some low entropy mechanism l= ike a PIN without the former being deterministically derived from the latte= r.

I personally believe the future of authenticati= on is having a weak credential which unlocks a strong credential on somethi= ng you have. This approach to authentication is generally described as &quo= t;something you have and something you know"

--
Tony Arcieri
--001a113ecb76057d8f052bf1b2b9-- From nobody Wed Feb 17 11:03:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1BE71B2D59 for ; Wed, 17 Feb 2016 11:03:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 lykKzLTukops for ; Wed, 17 Feb 2016 11:03:51 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id A512B1B2D58 for ; Wed, 17 Feb 2016 11:03:51 -0800 (PST) Received: (qmail 27396 invoked by uid 0); 17 Feb 2016 19:03:49 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 17 Feb 2016 19:03:49 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id Ke3i1s00q2UhLwi01e3l1H; Wed, 17 Feb 2016 19:03:46 -0700 X-Authority-Analysis: v=2.1 cv=bej4Do/B c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=k2-isdDcx0cA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=d2DZj1HXscTZENafW1gA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=YlrOMwp/Tfpm7WFr2WXOsBkE2ChnW6xIRXErkLBlTa8=; b=KF8rSn3NTubnwbPw/flWQcmbyFD2qv5A4/19lyoJ2bZknh+gvX5SRWh2DAJgDcJkHoescxT8BbYZzd/QC6NXIevVnbR23SY8f2/mw++ixu72uwTABiX4r+2xSCHp690s; Received: from [70.197.0.172] (port=9330 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aW7O5-0006wR-8l for tls@ietf.org; Wed, 17 Feb 2016 12:03:45 -0700 To: IETF TLS WG From: =JeffH Message-ID: <56C4C40C.5090508@KingsMountain.com> Date: Wed, 17 Feb 2016 11:03:40 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.0.172 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [TLS] -tls13-11: "directional keys" ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 19:03:52 -0000 In -tls13-11 section 7.2 [1] there is this.. 7.2. Updating Traffic Keys and IVs Once the handshake is complete, ... [...] Once traffic_secret_N+1 and its associated traffic keys have been computed, implementations SHOULD delete traffic_secret_N. Once the directional keys are no longer needed, they SHOULD be deleted as well. ..and it isn't clear to me what is meant by "directional keys" in the paragraph above (that is the only occurance of the term I find)? is the term meant as a forward reference to this table in S 7.3 and thus to the notion of "client write key" and "server write key" ? +------------------+--------------------+ | Key Type | Purpose | +------------------+--------------------+ | Client Write Key | "client write key" | | | | | Server Write Key | "server write key" | [...] +------------------+--------------------+ thx, =JeffH [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-7.2 From nobody Wed Feb 17 11:25:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDE11B2B49 for ; Wed, 17 Feb 2016 11:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 BCeW3PZ5Ynvv for ; Wed, 17 Feb 2016 11:25:26 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 3CFEF1B2C2A for ; Wed, 17 Feb 2016 11:25:22 -0800 (PST) Received: (qmail 31878 invoked by uid 0); 17 Feb 2016 19:25:21 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 17 Feb 2016 19:25:21 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id KXRG1s0072UhLwi01XRKH0; Wed, 17 Feb 2016 12:25:20 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=k2-isdDcx0cA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=S7tXiXOyQuEJdAvWXyEA:9 a=KWmwj1_14gNWFqCh:21 a=hRyezeV-0VDCxkmD:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=YNiY4YOvtzPR6mjS6eL9GWGS5YFw3hugA7vorEyBgKM=; b=q1Pc4plNM5VaaJQIjwNUjKHoJ4jiep/5+ZjE4ynPmmV/QnQrIuSOG0tZOZ50x3kvsmf5vC0orjrWn8EJQ5aPwVSdx0UvZyJFelFmZ1irsOb+1OdJrIS18dsnU7tfaQby; Received: from [70.197.0.172] (port=9327 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aW7iv-000147-1r for tls@ietf.org; Wed, 17 Feb 2016 12:25:17 -0700 To: IETF TLS WG From: =JeffH Message-ID: <56C4C918.4070606@KingsMountain.com> Date: Wed, 17 Feb 2016 11:25:12 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.0.172 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 19:25:27 -0000 Hi, RFC5705 section 4 "Exporter Definition" [1] states.. The exporter takes three input values: o a disambiguating label string, o a per-association context value provided by the application using the exporter, and o a length value. If no context is provided, it then computes: PRF(... )[length] If context is provided, it computes: PRF(... )[length] ..i.e., RFC5705 directly utilizes the TLS PRF (pseudo-random function) from TLS {1.0, 1.1, 1.3}. Since the PRF() is no longer defined in TLS 1.3, RFC5705 is incompatible with TLS 1.3, yes? Also, draft-ietf-tls-tls13-11 seems to contain a built-in keying material exporter (KME) in S 7.1 step 8 [2].. 7.1. Key Schedule [...] 8. exporter_secret = HKDF-Expand-Label(master_secret, "exporter master secret", handshake_hash, L) [...] ..i.e., does the above step "8." effectively define the TLS 1.3 keying material exporter? thanks, =JeffH [1] https://tools.ietf.org/html/rfc5705#section-4 [2] https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-7.1 From nobody Wed Feb 17 11:28:42 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2541B2DAB for ; Wed, 17 Feb 2016 11:28:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tPYmNsho1YsV for ; Wed, 17 Feb 2016 11:28:39 -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 F351C1B2D9F for ; Wed, 17 Feb 2016 11:28:38 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1B69342372E; Wed, 17 Feb 2016 19:28:38 +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 0032A42372D; Wed, 17 Feb 2016 19:28:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1455737318; bh=bAD5T5n67V2TR0lwjIsdNgtubvuONTUSKxHstt73yFg=; l=1217; h=To:References:From:Date:In-Reply-To:From; b=Ba8keSxM6akvENg1yZ2VDqu1cHd1NMuhGHwd2o5AUZqpW2FIkkuO3m20ZGQmAVtpm PUg4TchLJkCc1JspbKP5c9c09o7RmDytNxOKz0YuESaWrjrpdZqkKsfzuD/T4+ddab mn3RHX/3aXDuum5d0OEBkq5EwW9pAwWYc821EK3w= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BFF1A202A; Wed, 17 Feb 2016 19:28:37 +0000 (GMT) To: =JeffH , IETF TLS WG References: <56C4C40C.5090508@KingsMountain.com> From: Benjamin Kaduk Message-ID: <56C4C9E5.9050206@akamai.com> Date: Wed, 17 Feb 2016 13:28:37 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C4C40C.5090508@KingsMountain.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] -tls13-11: "directional keys" ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 19:28:41 -0000 On 02/17/2016 01:03 PM, =JeffH wrote: > In -tls13-11 section 7.2 [1] there is this.. > > 7.2. Updating Traffic Keys and IVs > > Once the handshake is complete, ... > > [...] > > Once traffic_secret_N+1 and its associated traffic keys have been > computed, implementations SHOULD delete traffic_secret_N. Once the > directional keys are no longer needed, they SHOULD be deleted as > well. > > > ..and it isn't clear to me what is meant by "directional keys" in the > paragraph above (that is the only occurance of the term I find)? > > is the term meant as a forward reference to this table in S 7.3 and thus > to the notion of "client write key" and "server write key" ? > Yes. -Ben > +------------------+--------------------+ > | Key Type | Purpose | > +------------------+--------------------+ > | Client Write Key | "client write key" | > | | | > | Server Write Key | "server write key" | > [...] > +------------------+--------------------+ > > > thx, > > =JeffH > > [1] https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-7.2 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Feb 17 12:23:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A87B1A87DB for ; Wed, 17 Feb 2016 12:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xmskMzkPIeBA for ; Wed, 17 Feb 2016 12:23:49 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 683E91A0439 for ; Wed, 17 Feb 2016 12:23:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 0F9E4911; Wed, 17 Feb 2016 22:23:47 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id D6kSQmJ78N71; Wed, 17 Feb 2016 22:23:46 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id B163F2313; Wed, 17 Feb 2016 22:23:46 +0200 (EET) Date: Wed, 17 Feb 2016 22:23:43 +0200 From: Ilari Liusvaara To: =JeffH Message-ID: <20160217202342.GA8163@LK-Perkele-V2.elisa-laajakaista.fi> References: <56C4C918.4070606@KingsMountain.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <56C4C918.4070606@KingsMountain.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 20:23:51 -0000 On Wed, Feb 17, 2016 at 11:25:12AM -0800, =JeffH wrote: > Hi, > > RFC5705 section 4 "Exporter Definition" [1] states.. > > The exporter takes three input values: > > o a disambiguating label string, > > o a per-association context value provided by the application using > the exporter, and > > o a length value. > > If no context is provided, it then computes: > > PRF(... > )[length] > > If context is provided, it computes: > > PRF(... > )[length] > > > ..i.e., RFC5705 directly utilizes the TLS PRF (pseudo-random function) > from TLS {1.0, 1.1, 1.3}. Since the PRF() is no longer defined in TLS > 1.3, RFC5705 is incompatible with TLS 1.3, yes? > > Also, draft-ietf-tls-tls13-11 seems to contain a built-in keying material > exporter (KME) in S 7.1 step 8 [2].. > > 7.1. Key Schedule > > [...] > > 8. exporter_secret = HKDF-Expand-Label(master_secret, > "exporter master secret", > handshake_hash, L) > [...] > > > ..i.e., does the above step "8." effectively define the TLS 1.3 keying > material exporter? > Well, it isn't clear to me what TLS 1.3 exporters should do. Presumably the "master secret" used for calculations is exporter_secret. However, just replacing the PRF in definition with the standard TLS 1.3 PRF (HKDF) would leave those exporters using randoms, which aren't explicitly used anywhere in TLS 1.3. -Ilari From nobody Wed Feb 17 14:25:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54A201B3009 for ; Wed, 17 Feb 2016 14:25:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 TdqfzIGzdFYG for ; Wed, 17 Feb 2016 14:25:06 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c: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 4FA181B2FD4 for ; Wed, 17 Feb 2016 14:25:06 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id g62so48865603wme.0 for ; Wed, 17 Feb 2016 14:25:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xAqJdCQMFxYuEDBAQn53jJdwHCFitpP6Ixl1XjDw24o=; b=Cox3EL75eGuIvLIS6x/bqZNPk925vt7TtU4D21LXtj1BvMT/s0CuVETWO6tYrrfeG+ uwyUhy5J4v7yK9DnOnF2WahAjmUx9g1gU4cRaKIFbdKSFTuG6nfbuV8rHHbW5qkFiT1V XAFGshIIW1rFF41xsIhML+0coMM94tK+6dOYsVoRhNGOZSrMsRh5f5eYPvuwLhyeOAII XSBrpOo7P5irJhcBeSF03R3h5MXG93qga9DpuHbWjrQBeudz3rQNHWcJ6iBxMQK6ydwL wUuwFxAGEoSecQ5tXRg1RLpN+eCAQhQJqqiV+Q7zI4Q7QPnLn1NslWkhOdQFHpk9uao5 X/4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:sender:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=xAqJdCQMFxYuEDBAQn53jJdwHCFitpP6Ixl1XjDw24o=; b=jKLiSxb/JWs6H4dxeB+opc/28QqTxzwtvTIUbnQR/rPXAa+rTNVhtgrlr92p6ZpNSG 7vjtQdCrpZzhFAM/HQUeK9bi/6hn2hLzTKz+OhiEk8RDF9HLi4ttGWmGkB5JFkhpGHqw rEGovgszRGErh5ZkrSDmTYaOE0TZD7CnuKaniH5RKPG/7jI0ghm4U0tN9dUX+s+P7ISt ts6DLbhqWoRU+1NWxrOeVI7AEyN6iPIjeEct9QTFLCYBP1wcA9+VuGNFfEMxwykckVGg XZxSDcRYaa8iASVXT8Oi3bjHvdf5FDvHCfzXWPN2T7199jHrzF3PVsaYa96F28/UJfrH 2rPg== X-Gm-Message-State: AG10YOSnf3IyB7qnIeS3fu8nqudzKXJj0zH4m1KZM+If6AF0IEcfsRXMevrf9Rhhj/cuTcroaUP3o/oPEOflWg== MIME-Version: 1.0 X-Received: by 10.194.63.144 with SMTP id g16mr4967471wjs.149.1455747904901; Wed, 17 Feb 2016 14:25:04 -0800 (PST) Sender: robert.cragie@gmail.com Received: by 10.194.136.163 with HTTP; Wed, 17 Feb 2016 14:25:04 -0800 (PST) In-Reply-To: References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@usma1ex-dag1mb1.msg.corp.akamai.com> <9352e83d67d8a90a4a26f575127e43b1.squirrel@www.trepanning.net> Date: Wed, 17 Feb 2016 22:25:04 +0000 X-Google-Sender-Auth: PflsI-vQxkQSIu6BSxXzAnmMysQ Message-ID: From: Robert Cragie To: Tony Arcieri Content-Type: multipart/alternative; boundary=047d7ba978c0c11ce7052bfeb8a4 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2016 22:25:13 -0000 --047d7ba978c0c11ce7052bfeb8a4 Content-Type: text/plain; charset=UTF-8 A few points to some of the comments: 1) Thread devices are not typically smartphones and PCs. They are class 1 constrained devices according to RFC7228, i.e. thermostats and light switches etc. 2) Device certs. and short fingerprints are indeed used in similar systems to Thread (e.g. ZigBee IP) 3) There is an experimental version of TLS using EC-JPAKE. This will be written up in an informational RFC as stated 4) Typically the device requiring network access has a burned in passphrase which is entered into a local commissioning device, establishing a secured session and high entropy shared secret, which is subsequently used for delivering network parameters authorising network admission. Any PAKE would have done really however the decision was made to use EC-JPAKE. This method may not be appropriate in all scenarios but provides a common, simple interoperable mechanism for consumer devices. Robert On 17 February 2016 at 06:52, Tony Arcieri wrote: > On Tue, Feb 16, 2016 at 10:45 PM, Dan Harkins wrote: > >> What?!? How is that "better"? Having a "keychain" that loops in some >> vague "secure enclave" that makes authorization decisions based on some >> app deriving a "strong master secret from a weak password/pin" sounds >> complicated > > > Microsoft: > https://technet.microsoft.com/en-us/library/mt621546(v=vs.85).aspx > Matt Green: https://twitter.com/matthew_d_green/status/699777680728842240 > Apple: https://www.apple.com/business/docs/iOS_Security_Guide.pdf (see > also: Matt Green) > > Hardware interlocks around authentication allow various anti-brute force, > exponential backoff, and device wiping security measures. They also allow > you to unlock a "full entropy" cryptographic key with some low entropy > mechanism like a PIN without the former being deterministically derived > from the latter. > > I personally believe the future of authentication is having a weak > credential which unlocks a strong credential on something you have. This > approach to authentication is generally described as "something you have > and something you know" > > -- > Tony Arcieri > --047d7ba978c0c11ce7052bfeb8a4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A few points to some of the comments:

1= ) Thread devices are not typically smartphones and PCs. They are class 1 co= nstrained devices according to RFC7228, i.e. thermostats and light switches= etc.
2) Device certs. and short fingerprints are indeed used in = similar systems to Thread (e.g. ZigBee IP)
3) There is an experim= ental version of TLS using EC-JPAKE. This will be written up in an informat= ional RFC as stated
4) Typically the device requiring network acc= ess has a burned in passphrase which is entered into a local commissioning = device, establishing a secured session and high entropy shared secret, whic= h is subsequently used for delivering network parameters authorising networ= k admission. Any PAKE would have done really however the decision was made = to use EC-JPAKE. This method may not be appropriate in all scenarios but pr= ovides a common, simple interoperable mechanism for consumer devices.
=

Robert



On 17 February 2016 at 0= 6:52, Tony Arcieri <bascule@gmail.com> wrote:
On Tue, Feb 16, 2016 at 10:45 PM, Dan Har= kins <dharkins@lounge.org> wrote:
What= ?!? How is that "better"? Having a "keychain" that loop= s in some
vague "secure enclave" that makes authorization decisions based o= n some
app deriving a "strong master secret from a weak password/pin" so= unds
complicated


Hardware interlocks around = authentication allow various anti-brute force, exponential backoff, and dev= ice wiping security measures. They also allow you to unlock a "full en= tropy" cryptographic key with some low entropy mechanism like a PIN wi= thout the former being deterministically derived from the latter.

I personally believe the future of authentication is having= a weak credential which unlocks a strong credential on something you have.= This approach to authentication is generally described as "something = you have and something you know"

--
Tony Arcieri

--047d7ba978c0c11ce7052bfeb8a4-- From nobody Wed Feb 17 17:12:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02D4E1B3011 for ; Wed, 17 Feb 2016 17:11:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 ywfA98jMtCbM for ; Wed, 17 Feb 2016 17:11:53 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 8C71F1A90B3 for ; Wed, 17 Feb 2016 17:11:15 -0800 (PST) Received: (qmail 11190 invoked by uid 0); 18 Feb 2016 01:11:12 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy2.mail.unifiedlayer.com with SMTP; 18 Feb 2016 01:11:12 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id KdB21s0112UhLwi01dB59j; Wed, 17 Feb 2016 18:11:11 -0700 X-Authority-Analysis: v=2.1 cv=FuSWoQbq c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=k2-isdDcx0cA:10 a=jFJIQSaiL_oA:10 a=NoINrHdCMseySWQHzgMA:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=q0VhSjQj24RCHEEBQ5eU7AaCt8E77ssbF278lfIlS7k=; b=j++YfyTHRGvU7nOb2U95LzVX4MkdmjKYYILD9xwsHAYNAV2PhBGGYHQ6EzN8ZXeP7lWQYG4qrVfpAc31UihlfWtEmSgvqQzJE/fe+E1f7sb5Kb4Lunve6w1F/T8PfNgD; Received: from [70.197.0.172] (port=9340 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aWD7X-0003my-SJ for tls@ietf.org; Wed, 17 Feb 2016 18:11:03 -0700 To: IETF TLS WG From: =JeffH Message-ID: <56C51A23.8020101@KingsMountain.com> Date: Wed, 17 Feb 2016 17:10:59 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.0.172 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [TLS] -tls13-11: client ephemeral, server ephemeral, static secret, ephemeral secret ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 01:11:59 -0000 Hi, perhaps I'm missing various somethings, but I'm having trouble figuring out _how_ the Static Secret (SS) and Ephemeral Secret (ES) are actually derived... Given this chunk of -tls13-11.. ### 7.1. Key Schedule The TLS handshake establishes secret keying material which is then used to protect traffic. This keying material is derived from the two input secret values: Static Secret (SS) and Ephemeral Secret (ES). The exact source of each of these secrets depends on the operational mode (DHE, ECDHE, PSK, etc.) and is summarized in the table below: +-----------------+------------------------+------------------------+ | Key Exchange | Static Secret (SS) | Ephemeral Secret (ES) | +-----------------+------------------------+------------------------+ | (EC)DHE (full | Client ephemeral w/ | Client ephemeral w/ | | handshake) | server ephemeral | server ephemeral | | | | | | (EC)DHE (w/ | Client ephemeral w/ | Client ephemeral w/ | | 0-RTT) | server static | server ephemeral | | | | | | PSK | Pre-Shared Key | Pre-shared key | | | | | | PSK + (EC)DHE | Pre-Shared Key | Client ephemeral w/ | | | | server ephemeral | +-----------------+------------------------+------------------------+ ### ..where do "client ephemeral" & "server ephemeral" come from -- i.e., which section(s) of the spec define their provenance? searching -tls13-11's text for those phrases yields hits in only that thar above table :( however, I note the following in the preceding section 6.2.. ### 6.2. Handshake Protocol Overview [...] Ephemeral Secret (ES): A secret which is derived from fresh (EC)DHE shares for this connection. Keying material derived from ES is intended to be forward secret (with the exception of pre-shared key only modes). Static Secret (SS): A secret which may be derived from static or semi-static keying material, such as a pre-shared key or the server's semi-static (EC)DH share. [...] ... If DH is in use, this will contain a "key_share" extension with the server's ephemeral Diffie-Hellman share which MUST be in the same group as one of the shares offered by the client. The server's KeyShare and the client's KeyShare corresponding to the negotiated key exchange are used together to derive the Static Secret and Ephemeral Secret (in this mode they are the same). [Section 6.3.2.3] ### So, is "server ephemeral" in S 7.1 actually referring to "the server's ephemeral Diffie-Hellman share" in S 6.2 ? Is "client ephemeral" in S 7.1 referring to "the client's KeyShare" in S 6.2 ? The above S 6.2 text seems to indicate that Section 6.3.2.3 defines how the server's KeyShare and the client's KeyShare are used to derive the Static Secret and Ephemeral Secret, but I am not able discern such a definition (unlike the clear definitions for xSS, xES, etc in S 7.1). thanks, =JeffH From nobody Wed Feb 17 19:50:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 921D61B3368 for ; Wed, 17 Feb 2016 19:50:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.358 X-Spam-Level: * X-Spam-Status: No, score=1.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, LONGWORDS=2.035] autolearn=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 ICtG1UlXO24L for ; Wed, 17 Feb 2016 19:50:14 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671531B3389 for ; Wed, 17 Feb 2016 19:50:14 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id e63so30667332ywc.3 for ; Wed, 17 Feb 2016 19:50:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to:content-type; bh=3oiOC3ykC9xPdyDYqUQBYYv60RiDuG/0gEw/cC3xePI=; b=ZjfFzIjoptAwF6Dw/Y81SVNbCVpKgXRQUyaHU4/zF8HIPpyKLkIryBRc7MMWD7Nikg fukYouNAlC45CxX0LNeuOuWAapPI2rvekawbCnb4w6WCl+jk6CDayV/NKA09JMEYMQ/j Ih5ilwcEE9d748v3DZwxHTBFdfjiqURuOwtmeXGkDQZWs1XzTBZwGHeAKk4ejPr0kdrk MtetgCnzpAuwJFYxXKPxhytHSY6aMEhrqURWOvk4JBunfDKVRFIBfMQQkcBIY+9E70Te z0oOxBR4s01R4FI4s9RcmSIBQLTOV9KRHdMdMKiQQmVQtb4QcFqF3tIMl9gxcWoGEWeJ f61w== 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 :content-type; bh=3oiOC3ykC9xPdyDYqUQBYYv60RiDuG/0gEw/cC3xePI=; b=WsywcFQR3sqTpdoojYvt2XnTGC23rDaynPbaIr0dnTHRoDKzYAw0bhDqw5kHwOTCB3 S8eOTsp3kUGvOTGC7921913dQFLRc9w86lzh6FDFrtdNYEWZ/39w/nA54D2SQxsHWC9W oDmtglMZXiXzHdx192KLYNCoXl/lAONEVuAdh4HPoiQrwgdGJkyuvv/xjnlIIrPOCOBN c17u4df2Jimqhwb+pgf5iNmHR5x8FIUbDuloL8rhD7RY1ehti4b6f1X5Pd3a9sfjXMXi 1eVgyA/Dx5+3N2sf+VgGyZxS6oBy5kZrZo9V3+CNqh9fZDEryudTBt8mHuQg2LNZG/yP iRPA== X-Gm-Message-State: AG10YOT8GrawvD8iIt1vwcvrJPXQvGieFvTDTqzFplPX+0BPoNpLmxsYaKMFp12scjxy8PrA2Cc6AtJKNIylYA== X-Received: by 10.129.38.135 with SMTP id m129mr2982636ywm.155.1455767413765; Wed, 17 Feb 2016 19:50:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Wed, 17 Feb 2016 19:49:33 -0800 (PST) From: Eric Rescorla Date: Wed, 17 Feb 2016 20:49:33 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a1141618c92eaf3052c0343ec Archived-At: Subject: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 03:50:16 -0000 --001a1141618c92eaf3052c0343ec Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi folks, TL;DR. I propose that we should not change keys between the handshake and application traffic keys. DETAILS As we try to finalize the drafts and implementations are starting to emerge, it's worth looking for opportunities to simplify. This is the first of several messages suggesting areas where we may have made things too general/complicated and now that we can look at simplifying. The following suggestion comes out of conversations with Karthik Bhargavan, Antoine Delignat-Lavaud, Cedric Fournet, Christian Huitema, Markus Kohlweiss, Martin Thomson, Santiago Zanella and others. The general idea is that there is no strong security reason to change change keys between handshake and traffic in the same phase (e.g., between the 1-RTT handshake and traffic keys, so we should simplify by not doing so.) This is something that implementers have asked for, especially for DTLS (so you don't need to have three contexts in one flight) and we have resisted, nominally for security reasons but really over concerns about analysis. There are three basic security reasons why one might want to change keys: - To add additional secret information. - To bind in additional context. - For PFS. None of these apply at the handshake/traffic transition: We don=E2=80=99t h= ave any more secret material at this point in TLS 1.3 (SS and ES are both known at the time that the handshake keys must be generated.) It is not necessary to bind in the additional context to the traffic keys (though see below about resumption) because it is tied to the keys via the Finished messages. We know how to do security proofs for this (those exist for 1.2). There=E2=80=99s no reason to have differen= t PFS for the handshake versus the application traffic. We can simplify matters by adopting a schedule more like the following: Key Class Input Handshake Context Specific Secrets /Transcript Keys ---------------------------------------------------------------------------= ------ 0-RTT Keys SS ClientHello + client write keys ServerConfiguration + client finished key= s ServerCertificate + CertificateRequest 1-RTT Keys SS, ES ClientHello, client/server write keys ServerHello client/server finished keys Final Keys SS, ES Complete transcript through client finished exporter master secret resumption master secret [Maybe traffic_secret_1] Note that it is very important that the Resumption Master Secret include the server certificate (otherwise you get Triple Handshake) but you shouldn'tt need that for the initial handshake traffic keys. This is clearly simpler and also has the advantage that you do fewer expansions with different combinations of transcript messages. It's a very simple change to the specification and to implementations. It also allows a somewhat simpler key schedule (see the next message in this series). There are two potential objections here: - It=E2=80=99s a change, how do we know it=E2=80=99s OK? - Doesn=E2=80=99t this make analysis harder? There are intuitive reasons to believe that it is OK (this is very similar to what TLS 1.2 does with the resumption secret being derived as with Extended Master Secret), and there are teams actively adapting their analysis to verify that they are OK. Obviously, it might not be OK and we should not finalize this change until we have some analysis. I'll let Karthik, Cedric, etc. speak to the progress on that and perhaps we can discuss more at TRON. There is a sense in which it makes analysis harder in that the cryptographic (as opposed to symbolic) proofs are better adapted to assuming that the keys being output by the handshake are never used for any handshake purpose. However, there are techniques for making this work with plausible assumptions about how TLS will use the keys (mainly that only TLS will be allowed to send traffic with the TLS internal keys and that everything else will only get access to Exported keys) [1]. One more important note: for DHE-PSK mode, it is important to have the traffic encrypted under both SS and ES (I.e., both PSK and DHE) but that=E2=80=99s not presently true for the handshake data (which is only encrypted under ES). So, this will also require at least some change to the key schedule to accommodate that. However, those changes are relatively straightforward. Comments, please. -Ekr [1] Another alternative here would be to generate separate keys for handshake and application traffic but do so at the same time, so that there is only one derivation stage. This simplifies the specification and implementation somewhat, but not as much as having handshake and application traffic. --001a1141618c92eaf3052c0343ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

TL;DR.
I= propose that we should not change keys between the handshake
and= application traffic keys.

DETAILS
As we= try to finalize the drafts and implementations are starting to
e= merge, it's worth looking for opportunities to simplify. This is the
first of several messages suggesting areas where we may have made
things too general/complicated and now that we can look at
simplifying. The following suggestion comes out of conversations with
Karthik Bhargavan, Antoine Delignat-Lavaud, Cedric Fournet, Christi= an
Huitema, Markus Kohlweiss, Martin Thomson, Santiago Zanella an= d
others.

The general idea is that there= is no strong security reason to change
change keys between hands= hake and traffic in the same phase (e.g.,
between the 1-RTT hands= hake and traffic keys, so we should simplify by
not doing so.) = =C2=A0This is something that implementers have asked for,
especia= lly for DTLS (so you don't need to have three contexts in one
flight) and we have resisted, nominally for security reasons but
really over concerns about analysis.

There are th= ree basic security reasons why one might want to change
keys:

- To add additional secret information.
- T= o bind in additional context.
- For PFS.

None of these apply at the handshake/traffic transition: We don=E2=80=99t = have
any more secret material at this point in TLS 1.3 (SS and ES= are both
known at the time that the handshake keys must be gener= ated.) It is
not necessary to bind in the additional context to t= he traffic keys
(though see below about resumption) because it is= tied to the keys
via the Finished messages. We know how to do se= curity proofs
for this (those exist for 1.2).=C2=A0 There=E2=80= =99s no reason to have different
PFS for the handshake versus the= application traffic.

We can simplify matters by a= dopting a schedule more like the following:


Key Class =C2=A0 =C2=A0 Input =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 H= andshake Context =C2=A0 =C2=A0 =C2=A0 =C2=A0 Specific
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Secrets =C2=A0 =C2=A0 =C2=A0 =C2=A0 = /Transcript =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Keys
--------------------------------------------------------------------------= -------
0-RTT Keys =C2=A0 =C2=A0SS =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0ClientHello + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= client write keys
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ServerCon= figuration + =C2=A0 =C2=A0client finished keys
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0ServerCertificate +
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0CertificateRequest

1-RTT Keys =C2=A0 = =C2=A0SS, ES =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ClientHello, =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0client/server write keys
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 ServerHello =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 client/server finished keys


<= div>Final Keys =C2=A0 =C2=A0SS, ES =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Comple= te transcript
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 through client fini= shed =C2=A0 exporter master secret
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 resumption master secret
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 [Maybe traffic_secret_1]
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
Note that it is very important that the Resumption Master Secre= t
include the server certificate (otherwise you get Triple Handsh= ake)
but you shouldn'tt need that for the initial handshake t= raffic keys.

This is clearly simpler and also has = the advantage that you do fewer
expansions with different combina= tions of transcript messages. It's
a very simple change to th= e specification and to implementations.
It also allows a somewhat= simpler key schedule (see the next message
in this series).

There are two potential objections here:
- I= t=E2=80=99s a change, how do we know it=E2=80=99s OK?
- Doesn=E2= =80=99t this make analysis harder?

There are intui= tive reasons to believe that it is OK (this is very
similar to wh= at TLS 1.2 does with the resumption secret being derived
as with = Extended Master Secret), and there are teams actively adapting
th= eir analysis to verify that they are OK. Obviously, it might not be
OK and we should not finalize this change until we have some analysis.
I'll let Karthik, Cedric, etc. speak to the progress on that a= nd
perhaps we can discuss more at TRON.

= There is a sense in which it makes analysis harder in that the
cr= yptographic (as opposed to symbolic) proofs are better adapted to
assuming that the keys being output by the handshake are never used
<= div>for any handshake purpose. However, there are techniques for making
this work with plausible assumptions about how TLS will use the keys=
(mainly that only TLS will be allowed to send traffic with the T= LS
internal keys and that everything else will only get access to=
Exported keys) [1].

One more important = note: for DHE-PSK mode, it is important to have the
traffic encry= pted under both SS and ES (I.e., both PSK and DHE) but
that=E2=80= =99s not presently true for the handshake data (which is only
enc= rypted under ES). So, this will also require at least some change
to the key schedule to accommodate that. However, those changes are
<= div>relatively straightforward.

Comments, please.<= /div>
-Ekr


[1] Another alternat= ive here would be to generate separate keys for
handshake and app= lication traffic but do so at the same time, so that
there is onl= y one derivation stage. This simplifies the specification
and imp= lementation somewhat, but not as much as having handshake
and app= lication traffic.





--001a1141618c92eaf3052c0343ec-- From nobody Thu Feb 18 04:09:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06081B3E8F for ; Thu, 18 Feb 2016 04:09:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.706 X-Spam-Level: X-Spam-Status: No, score=-0.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, J_CHICKENPOX_72=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 jSEKN-CwjUR1 for ; Thu, 18 Feb 2016 04:09:28 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id B8A0C1B3E9F for ; Thu, 18 Feb 2016 04:09:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 5583958E; Thu, 18 Feb 2016 14:09:25 +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 Y1dQYKGmBX2N; Thu, 18 Feb 2016 14:09:24 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id D16412313; Thu, 18 Feb 2016 14:09:24 +0200 (EET) Date: Thu, 18 Feb 2016 14:09:21 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160218120920.GA8620@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.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 12:09:30 -0000 On Wed, Feb 17, 2016 at 08:49:33PM -0700, Eric Rescorla wrote: > Hi folks, > > TL;DR. > I propose that we should not change keys between the handshake > and application traffic keys. > > The general idea is that there is no strong security reason to change > change keys between handshake and traffic in the same phase (e.g., > between the 1-RTT handshake and traffic keys, so we should simplify by > not doing so.) This is something that implementers have asked for, > especially for DTLS (so you don't need to have three contexts in one > flight) and we have resisted, nominally for security reasons but > really over concerns about analysis. > > There are three basic security reasons why one might want to change > keys: > > - To add additional secret information. > - To bind in additional context. > - For PFS. > > None of these apply at the handshake/traffic transition: We don’t have > any more secret material at this point in TLS 1.3 (SS and ES are both > known at the time that the handshake keys must be generated.) It is > not necessary to bind in the additional context to the traffic keys > (though see below about resumption) because it is tied to the keys > via the Finished messages. We know how to do security proofs > for this (those exist for 1.2). There’s no reason to have different > PFS for the handshake versus the application traffic. > > We can simplify matters by adopting a schedule more like the following: > > > Key Class Input Handshake Context Specific > Secrets /Transcript Keys > --------------------------------------------------------------------------------- > 0-RTT Keys SS ClientHello + client write keys > ServerConfiguration + client finished keys > ServerCertificate + > CertificateRequest > > 1-RTT Keys SS, ES ClientHello, client/server write > keys > ServerHello client/server > finished keys > > > Final Keys SS, ES Complete transcript > through client finished exporter master > secret > resumption master > secret > [Maybe > traffic_secret_1] Hmm... If there was master secret that was derived from SS, ES and hash(ClientHello1...ServerHello) and then encryption keys, exporter keys and resumption keys were derived from that, the result would be very simple to analyze for GDHE-CERT (without CFG), GDHE-PSK and PSK. GDHE-CERT with CFG and other similar schemes are harder case. In that case, attacks can peneratrate all the way to ClientFinished. > Note that it is very important that the Resumption Master Secret > include the server certificate (otherwise you get Triple Handshake) > but you shouldn'tt need that for the initial handshake traffic keys. Eh, if using baseline GDHE-CERT without CFG and having master secret like previous, I don't see how (except if going by misleading statement in EMS RFC abstract). However, given that things can go definitely wrong if *client* certificate isn't included and attacks all the way to ClientFinished can happen if SS is nontrivially used, it is probably the simplest and the most conservative to take it as Hash(ClientHello1...ClientFinished), which also happens to include server certificate.... > There is a sense in which it makes analysis harder in that the > cryptographic (as opposed to symbolic) proofs are better adapted to > assuming that the keys being output by the handshake are never used > for any handshake purpose. However, there are techniques for making > this work with plausible assumptions about how TLS will use the keys > (mainly that only TLS will be allowed to send traffic with the TLS > internal keys and that everything else will only get access to > Exported keys) [1]. One thing to note is that TLS 1.3 record type/length hiding makes encrypted handshake and application data records distinct. -Ilari From nobody Thu Feb 18 06:33:11 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E3BB1ACDA7 for ; Thu, 18 Feb 2016 06:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_22=0.6, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 pJ9ArIFQ9RuZ for ; Thu, 18 Feb 2016 06:33:07 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 789E41ACD4D for ; Thu, 18 Feb 2016 06:32:47 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id r207so21599756ykd.2 for ; Thu, 18 Feb 2016 06:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=dz67KGbpEyiTFGCpWLfYpuq8mTllhFfPU9FI4rrRNEc=; b=Z0oKjTrUXbupkiDpY91NpQ2svD3lEPcMgkj1+E9gCKmWSafN8htDL2h9gCpCJ3yeD4 rBHMFnCbN7hWlTlsQK62hMYEh4DSUXzgXUTsIQpiNVAoJtYyAWPKacf5mwb4XmzMRxBK MS4Fa9rI/CeuWqrkfmLwPRiAvPQ8Yo1ycpxvR7jbq6s2HLjQauCh9vqn89PmKaJAv812 pFRH029pWo/IjzQs3imxrsILaECCxzFtuGewYGPkjNacmYUHATHQie2SDLbFqmO3a9TP VRipOdAaMUZ0QJooQ4LpUFFeUE7v97WC/8QgoQ8ikHcDt8z0bk45z15mR2PxIycgO294 E30w== 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:date :message-id:subject:from:to:cc:content-type; bh=dz67KGbpEyiTFGCpWLfYpuq8mTllhFfPU9FI4rrRNEc=; b=mwhQjmgJ7nr2qckEOJIWFb+ND+NR/Cznf1OLeNQ+tzz3jf/AERhIfOuBoHZ1gbRXsb XVFlY64IbrVEVaTHcho+hnoY1aYuKz1lmoeXb6/qyVxuT+e3LSkQYo258MQwBHr10cKN qWee7ucvG5Ouq4Et6S0C1cfMdUTnIog4RFFFl0WuVOeGHyZbnkgyBvsZS3A8m2hdXBYB hO9VQy4DfAN27VefepV9OZmixFqCGQAmhLqrQcBkECFwAe9UtHZx+VoXqKKpVJ3XtGpS f0OldpclN6Dup6KrbeGUoTbpre4+xiPPpdGeQnC7ESedSBehGYB9U/t6akZsmLrfYQhO xx5g== X-Gm-Message-State: AG10YOQe/5e22YiZBV/ElD6m22uPaJYKYP/AXw7E7JtOCXITwHpzZMt3dVC44AX3jLvLPzsOGkQ4wwXY/7HPpisK MIME-Version: 1.0 X-Received: by 10.37.14.213 with SMTP id 204mr1687435ybo.70.1455805966737; Thu, 18 Feb 2016 06:32:46 -0800 (PST) Received: by 10.37.115.130 with HTTP; Thu, 18 Feb 2016 06:32:46 -0800 (PST) In-Reply-To: References: Date: Thu, 18 Feb 2016 06:32:46 -0800 Message-ID: From: Wan-Teh Chang To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:33:09 -0000 On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla wrote: > > TL;DR. > I propose that we should not change keys between the handshake > and application traffic keys. Hi Eric, I'm not sure if I understand your one-sentence summary, because "change keys between the foo and bar keys" is hard to understand. Are you proposing that we should use the same keys to encrypt handshake messages and application data? Wan-Teh Chang From nobody Thu Feb 18 06:55:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E7C1ACED3 for ; Thu, 18 Feb 2016 06:55:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6] autolearn=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 HE8pxS4UuVKj for ; Thu, 18 Feb 2016 06:55:01 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA261ACEE3 for ; Thu, 18 Feb 2016 06:55:00 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id g127so42072768ywf.2 for ; Thu, 18 Feb 2016 06:55: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:content-type; bh=YvM8fGrHNUgxkHzEfW9kNxS6gCt92gzjRcib9vPz49Q=; b=DaoInk6PqUrDGIRwtynGuZxPpMPfwbXSb9Uy2fLwPqv/CIt8Nw1RWgRM7Tef8BpR4v rB7yIQlavvPTi7mL20JKL+du3E3Tv5ysyNvxeOH4ZNYVfg70xDjYXJ0t4clJ+HmpPDcc QvFtU6d+77cHM7+JThxf82kGi5OH+zJagc70ZMoa3DQMcUwPQDCclzJTS5YnhlN2e9O2 q/FRRf4S2bxw4WCfWEA84Fppcn+ShKZLW/AarRWq0FLCn/2F6hDoMf8x2rqCJg/WDDuf Zv/Q+XFx1+IuQPj8WSQ2fUlj0PWmDCiSJppJbG7tyQt2kSa2nQgMH9pviyInEPr54cLZ W0Ng== 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-type; bh=YvM8fGrHNUgxkHzEfW9kNxS6gCt92gzjRcib9vPz49Q=; b=Ui6HUg9Y84TnHQf2zUDNRelOjRa+V0YGtQiAq+eutMFVAJWBKgsVosHPyW8kXPETVa uX6KOy4Q4oSOwtmLykX8oH/MmFuOaDqxuYsfU5oEL8H5ys1ItVbnHWctK0eU82HQfWnL JeOLOO+9m26/205XhIG7d/Ny6fP/+RZStrckQ0LtHHLX6onygl5mvoua3LI0+elln8PC iGW/Lez+lY2/E/TJ/GSaCzHHNo/iG3mnpGrLXT/yG7DlbN6zLV2ycdIsGi5vjOmsX7gU trMoBjWRX9XrjC78Pa7ar+0JrM1Q3UX5QodXpFsiebhbvu0F1SuprwBHcb6CQPcYbBtn bvdA== X-Gm-Message-State: AG10YOQ9x/9lA+weNY+MI4M81WmWbNGXxseMxK1LWlFO/ue2RIAapy7h8INbOHJsTlRZ+j7eV3CIXE7JgjNp/g== X-Received: by 10.13.221.132 with SMTP id g126mr5145701ywe.231.1455807299511; Thu, 18 Feb 2016 06:54:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 18 Feb 2016 06:54:20 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 18 Feb 2016 07:54:20 -0700 Message-ID: To: Wan-Teh Chang Content-Type: multipart/alternative; boundary=94eb2c0613b8f31e19052c0c8c95 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 14:55:04 -0000 --94eb2c0613b8f31e19052c0c8c95 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 18, 2016 at 7:32 AM, Wan-Teh Chang wrote: > On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla wrote: > > > > TL;DR. > > I propose that we should not change keys between the handshake > > and application traffic keys. > > Hi Eric, > > I'm not sure if I understand your one-sentence summary, because > "change keys between the foo and bar keys" is hard to understand. Are > you proposing that we should use the same keys to encrypt handshake > messages and application data? Yes, precisely. -Ekr --94eb2c0613b8f31e19052c0c8c95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Feb 18, 2016 at 7:32 AM, Wan-Teh Chang <wtc@google.com>= wrote:
On Wed, Feb 17, = 2016 at 7:49 PM, Eric Rescorla <ekr@rtfm= .com> wrote:
>
> TL;DR.
> I propose that we should not change keys between the handshake
> and application traffic keys.

Hi Eric,

I'm not sure if I understand your one-sentence summary, because
"change keys between the foo and bar keys" is hard to understand.= Are
you proposing that we should use the same keys to encrypt handshake
messages and application data?

Yes, precise= ly.

-Ekr
--94eb2c0613b8f31e19052c0c8c95-- From nobody Thu Feb 18 07:34:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524EE1B2A81 for ; Thu, 18 Feb 2016 07:34:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wDCBte7XMnee for ; Thu, 18 Feb 2016 07:34:10 -0800 (PST) Received: from excelsior.roeckx.be (excelsior.roeckx.be [195.234.45.115]) (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 E61E81B2A83 for ; Thu, 18 Feb 2016 07:34:08 -0800 (PST) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 70420A8A001A; Thu, 18 Feb 2016 15:34:06 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 3AE531FE059B; Thu, 18 Feb 2016 16:34:06 +0100 (CET) Date: Thu, 18 Feb 2016 16:34:06 +0100 From: Kurt Roeckx To: Robert Cragie Message-ID: <20160218153405.GA28386@roeckx.be> References: <6f81a71b264f47268ed42cb528cac17f@usma1ex-dag1mb1.msg.corp.akamai.com> <56B8E47E.1060809@cisco.com> <66bf48ba45694438a7d2e170a9862266@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] JPAKE X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 15:34:12 -0000 On Tue, Feb 16, 2016 at 12:33:56AM +0000, Robert Cragie wrote: > The big assumption here is that SSL/TLS is used solely in browsers. That is > not how it is being used in Thread, for example, and indeed in other > similar technologies. In Thread, it is used for local device authentication > and authorisation. These use cases clearly benefit from a PAKE, i.e. > getting deriving a shared cryptographic from a weaker shared password. So when looking at things that might use JPAKE, Thread was one of the things that came up. But if you then go look, it seems to be using EC-JPAKE. Kurt From nobody Thu Feb 18 08:46:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 037FD1B2D61 for ; Thu, 18 Feb 2016 08:46:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=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 e1EPvqn7UvPO for ; Thu, 18 Feb 2016 08:46:43 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::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 07DC91B2C29 for ; Thu, 18 Feb 2016 08:46:13 -0800 (PST) Received: by mail-lb0-x236.google.com with SMTP id bc4so32018573lbc.2 for ; Thu, 18 Feb 2016 08:46:13 -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:content-type; bh=0WGKMXrUgTll8ImzDpKRqs9I1rr4n1nnWWzEh+P//rA=; b=hds9T2tsYmTqbvthJpMX3JxIutfTrwPoa9YPCs+1WeCMC4CZWA8GachFaEYOp1RZrK QfdeDU1LB5JplRb3N42sqhZmoBJy+QYuJr89eobORTMeM9DglhtD+yOi5xBpi0g2TEOU WZg+dxr6dJTS/GTfTmqBEn72zRXLAZA1znlHpzig1Q6i9cpaCByDnv5CIbL/fiZFLpwO zyfCztsN9fBqsRCpicCwjW6mRMBKjDchaQr++zDS+vkJMbYkg9JKvsAXLw6cd6pxsuR9 fZaWPUzB8KpotsojkeQ89Ma0Fr1g6x2XrNHR4KMSMANUbcdV5DvOMs8l7gJ6OwGFcXTN cFsQ== 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:content-type; bh=0WGKMXrUgTll8ImzDpKRqs9I1rr4n1nnWWzEh+P//rA=; b=CUV77OuRvwlvMjqqCK24JgJ68GbnxqKBnlLP554Rxt+EnchLOTHyWBE31g9lSIWKW5 9Vn4sWgkH5gOw6bDk3YM5SPktIRWQk6+opAAG1vUW4ZziG9Z2T1ZnUISf2eP6hG+8Nsa u5hxejMabhh5gPbHJF9D2wxnzrsryP3ZIiu/vYu3OXj5J+heqSLWvit2E/h2ijXf1ktr Tul2/2Oyosc5QBW6g5zpRlIPJjAc9yCjguk+ZDbAYaLQf/dmAd2BwaUeRZ1+Sb/4NF9R huMDsIzi9tINXelocgjGzeOeFcfZcXX5h2tAerTsCatWuBJ7zWbp9yTte6TrcVjsqlyQ gyBQ== X-Gm-Message-State: AG10YOSZ/icg8Ulgbfb9ltVhUWvV9ZPPRgAH9Y/AMfTGHPCoRSNFWhquNTpzo449tXHwGzRmX/e7rREftZFP9Q== X-Received: by 10.112.73.69 with SMTP id j5mr3077297lbv.124.1455813972079; Thu, 18 Feb 2016 08:46:12 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Thu, 18 Feb 2016 08:45:42 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Thu, 18 Feb 2016 11:45:42 -0500 X-Google-Sender-Auth: bnZ0erb0EENW-7vQupZyJQarT5w Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c28252aa3c29052c0e1ae0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 16:46:46 -0000 --001a11c28252aa3c29052c0e1ae0 Content-Type: text/plain; charset=UTF-8 I want to point out that the benefits of using the application key output by the handshake protocol also for handshake traffic protection are not clear cut. I cannot comment at the level of implementation simplification that motivates this change but I can comment on the cryptographic implications of this change. Yes, TLS 1.3, can probably be proved secure even with this key merge, but it is a proof of a *weaker* guarantee. When the application key is not used during the exchange you can claim that the handshake protocol provide *generic* key exchange security. Here "generic" means that you can use the key with *any* application that requires a secret shared key. In contrast, using the application key during the key exchange process itself can still guarantee security for a *specific* application but not in general. That is, we can now prove security for the specific application of this key to protecting TLS record layer traffic (achieved via TLS message type separation). But if you want to take that same key and use it for a variant of the protocol or in a different application [1] then you need to go and re-analyze [2] the protocol with that specific application in mind. Given the history of weaknesses in TLS I would prefer a more conservative design. TLS evolves and is used in places and ways not contemplated by the designers. For example, no one contemplated originally that people will use a MAC value or a session key as collision-resistant identifiers for sessions but people did. Models and requirements need to be strengthened over time, not weakened. The merge of handshake and application key is a weakening. Finally, a side effect of this change is that it limits the generality of the protocol. Till now the protocol was ready for an immediate variant where the server uses a Diffie-Hellman certificate. It would require a minimal adaptation of the current specification where the CertificateVerify message is omitted and an entry in the key derivation table is added. But to encrypt the DH certificate you'd need to derive a key from g^xy only (which is not the case for the application key). The DH variant is not currently contemplated but one that can be handy in the future (it is a simpler protocol than what we have now and can have benefits in a "post-quantum transition"). Hugo PS: I wrote more about this topic here https://www.ietf.org/mail-archive/web/tls/current/msg13625.html (it was in the context of the need to encrypt the Finished message but the issue I was commenting on was the same as here, namely, the re-use of the application key during the handshake) [1] Given the wide availability of TLS implementations, it makes sense for different applications to use the TLS handshake as their key-exchange protocol. Fortunately, there is the exporter key that is still secure in the stronger generic sense and can be used for that purpose. Even then, I would expect people to use the application key as the natural session key, or be tied to TLS in a way that requires using the same application key. And, in any case, changes to the record layer protocol would require a re-assessment of security in the combined handshake-record protocol. [2] The analysis of a protocol that breaks the generic and modular security principles is doable but more complex and needs to be re-assessed with changes to the application protocol. On Thu, Feb 18, 2016 at 9:54 AM, Eric Rescorla wrote: > > On Thu, Feb 18, 2016 at 7:32 AM, Wan-Teh Chang wrote: > >> On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla wrote: >> > >> > TL;DR. >> > I propose that we should not change keys between the handshake >> > and application traffic keys. >> >> Hi Eric, >> >> I'm not sure if I understand your one-sentence summary, because >> "change keys between the foo and bar keys" is hard to understand. Are >> you proposing that we should use the same keys to encrypt handshake >> messages and application data? > > > Yes, precisely. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c28252aa3c29052c0e1ae0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I want to point ou= t that the benefits of using the application key output by the
=
= handshake protocol also for handshake traffic protection are not clear cut.= =C2=A0
I cannot comment at the level of implementation simplifi= cation that motivates
<= font face=3D"verdana, sans-serif">this change but I can comment on the cryp= tographic implications of this change.

Yes, TL= S 1.3, can probably be proved secure even with this key merge, but it is
a proof of a *weaker* guarantee. When the application key is not = used during=C2=A0
the exchange you can claim that the handshake= protocol provide *generic* key
exchange security. Here "g= eneric" means that you can use the key with=C2=A0
*any*=C2= =A0application that r= equires a secret shared key. In contrast, using the
applicatio= n key during the key exchange process itself can still guarantee
prove security for the specific application of this key to= protecting TLS record
= layer traffic (achieved via TLS message = type separation). But if you want to
take that same key and use= it for a variant of the protocol or in a different
applicatio= n [1] then you need to go and re-analyze [2] the protocol with that<= /div>
specific application in mind.

Given the = history of weaknesses in TLS I would prefer a more conservative
design. TLS evolves and is used in places and ways not contemplated by the=
designers. For example, no one contemplated originally that pe= ople will use a
MAC value or a session key as collision-resista= nt identifiers for sessions but
people did. Models and requirem= ents need to be strengthened over time, not
weakened. The merge= of handshake and application key is a weakening.

Finally, a side effect of this change is that it limits the generality = of the
protocol. Till now the protocol was ready for an immedia= te variant where the
server uses a Diffie-Hellman certificate. = It would require a minimal adaptation
of the current specificat= ion where the CertificateVerify message is omitted and
an entry= in the key derivation table is added. But to encrypt the DH certificate
you'd need to derive a key from g^xy only (which is not the c= ase for the
application key). The DH variant is not currently = contemplated but one that can
be handy in the future (it is a s= impler protocol than what we have now and can
have benefits in = a "post-quantum transition").=C2=A0

=
= Hugo

<= font face=3D"verdana, sans-serif">PS: I wrote more about this topic here=C2= =A0
https://www.ietf.org/mail-archive/web/tls/current/msg13625= .html
(it was in the context o= f the need to=C2=A0en= crypt the Finished message but the issue=C2=A0
I was commentin= g on was the same as=C2=A0here, namely, the re-use of the application=C2=A0
key dur= ing the handshake)

[1] Given the wide av= ailability of TLS implementations, it makes sense for
different= applications to use the TLS handshake as their key-exchange protocol.
Fortunately, there is the exporter key that is still secure in the = stronger
generic sense and can be used for that purpose. Even t= hen, I would expect
people to use the application key as the na= tural session key, or be tied to TLS
in a way that requires usi= ng the same application key. And, in any case, changes
to the r= ecord layer protocol would require a re-assessment of security in the
combined handshake-record protocol.

[2]= The analysis of a protocol that breaks the generic and modular security
principles is doable but more complex and needs to be re-assessed= with changes=C2=A0
to the application protocol.


On Thu, Fe= b 18, 2016 at 9:54 AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Thu, Feb 18, 2016 at 7:32 A= M, Wan-Teh Chang <wtc@google.com> wrote:
On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla <ekr@rtfm.com> wrote: >
> TL;DR.
> I propose that we should not change keys between the handshake
> and application traffic keys.

Hi Eric,

I'm not sure if I understand your one-sentence summary, because
"change keys between the foo and bar keys" is hard to understand.= Are
you proposing that we should use the same keys to encrypt handshake
messages and application data?

Yes, = precisely.

-Ekr

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


--001a11c28252aa3c29052c0e1ae0-- From nobody Thu Feb 18 09:47:32 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 F38AE1B29D4; Thu, 18 Feb 2016 09:45:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160218174544.31749.33135.idtracker@ietfa.amsl.com> Date: Thu, 18 Feb 2016 09:45:44 -0800 Archived-At: X-Mailman-Approved-At: Thu, 18 Feb 2016 09:47:30 -0800 Cc: tls@ietf.org, turners@ieca.com, tls-chairs@ietf.org Subject: [TLS] tls - New Meeting Session Request for IETF 95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 17:45:45 -0000 A new meeting session request has just been submitted by Sean Turner, a Chair of the tls working group. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: spt Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: tokbind tcpinc stir saag rtcweb opsawg httpauth httpbis dane cfrg cose jose acme trans uta capport curdle Second Priority: sacm oauth sidr i2nsf Special Requests: Please avoid LURK BOF. --------------------------------------------------------- From nobody Thu Feb 18 13:06:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF8A51A0369 for ; Thu, 18 Feb 2016 13:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=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 dnN-n7txV8Pg for ; Thu, 18 Feb 2016 13:06:05 -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 033A21A90DB for ; Thu, 18 Feb 2016 13:06:05 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id h129so51478960ywb.1 for ; Thu, 18 Feb 2016 13:06:04 -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:content-type; bh=PqJ7sytmQ5ElsUh0mM9YQ+U+zNcZubstlq7yQli6eRc=; b=lo3x+vCULIV8fHnESAqSVg0Yd2IfBcn7UqaMKzDISjdx5DDl92hTY7/bz82W7qWD+x 11vdesocu5fXfo+1l92Xvvrr7I5ybJb6XrUL2H4zPzPiNP8bx1ZLjBGvHNAwtOuU9Eni ls3V599/m90ixfnk+QZ8BPME0tUNSehsCWDoc5K+Yr0/BAszGgWP70bs23iTmuIMzICX 0KDqfeIVR3hRLzVhEwjj0th+0ICxwWI1OQeOpF3clTx0ihztduC+ApW6ReqwRYDB4uY4 58ZPeZg+aVPEydKW3P17BWhyrmGi/Z1n2TFNzx68jAiOXwh3rr7tmMPUY1cDVduK1g2w LAzw== 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 :content-type; bh=PqJ7sytmQ5ElsUh0mM9YQ+U+zNcZubstlq7yQli6eRc=; b=L713j3DzDh0lQGYZ6/H1TV+Y7AJYrxbTuRKQAr+4f8JymHClGR/ynuXn3fKgvqHAau vSLetaWr/vzTz8Mq6C0A4LNAvtU7t5wFJ50JECcG0UJ75rAA/WUokHPVVH3cKJxfRHxD Zvdnd+0FkJjk3ayGyqvf9PxU3YPff/GgLVF/HmKs/R8ptTTs9v0x5BnONtKmJl/0Nrx6 gYGbEdwR51DbZkAlWIwSLZ9NH5vte+E5++EzvveusGPwwcdCAFNtEZkgF7Cc4e+sHS8e PkRxB1xIndlLTQ1S1DLp4WdcB5e8F02KZdNRqI6hkM5NgxYdZSXfuJhbH1Ga120jBm3S VFSQ== X-Gm-Message-State: AG10YOSOiCxfvniFSEAIRt47Bny37BViP2nh0XpH/SxYBLnKrOH+WuU3dFmIywj1HHgyfnVwhMm4h9A0NMnRCA== X-Received: by 10.129.46.15 with SMTP id u15mr5532657ywu.129.1455829564246; Thu, 18 Feb 2016 13:06:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 18 Feb 2016 13:05:24 -0800 (PST) From: Eric Rescorla Date: Thu, 18 Feb 2016 14:05:24 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11414df0081211052c11bc90 Archived-At: Subject: [TLS] Proposal: Simplified Key Schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2016 21:06:12 -0000 --001a11414df0081211052c11bc90 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi folks, TL;DR. Let's simplify the key schedule. DETAILS This is the second in a series of proposed simplifications to TLS 1.3 based on implementation experience and analysis once the protocol starts to harden. The following suggestion comes out of conversations with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud, Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanella and others. The current key schedule is elegant but it is actually more than we need in that it allows SS to be known either before or after ES. If we assume (as is always true in the current TLS 1.3 modes) that SS is known before or at the same time as ES, then we can design a simpler scheme which looks more like a ladder. Something like: 0 | SS -> HKDF [ClientHello + Context] | \ | \ v v X1 0-RTT Traffic Keys * | | v ES -> HKDF [ClientHello, ServerHello] | \ | \ v v X2 1-RTT Traffic Keys * | | v 0 -> HKDF [ClientHello...ClientFinished] | | v RMS, EMS As should be apparent, this key schedule is well-suited to the simplified key change schedule in my previous message. Note 1: It might be attractive to not even bother with the first stage if you aren't doing 0-RTT. It's not necessary then. However, this is just an optimization. Also, if you don't want to extract an RMS or an EMS you can skip the last stage (this is compatible). Note 2: The IKM for the final HKDF is 0, but in principle we could use it to add some sort of new keying material, for instance g^xs if we were using static DH certificates (see below). In line with Hugo's message earlier today, the major argument against this design is that it is more oriented towards a signature-based system, which TLS 1.3 is today, than towards a DH certificate-based system. To elaborate on this a bit, in a DH certificate-based system, the server authenticates by proving knowledge of g^xs (and hence s). In the current TLS 1.3 design you can do this trivially by replacing the signature in the server CertificateVerify with a MAC over the transcript (using g^xs as the key) [again, analysis needed.] This is straightforward and doesn't require rearchitecting the protocol really at all. However, this (as with the current signature-based mode) does not provide confidentiality of the connection if y is later revealed. As Hugo has noted several times, if you mix both g^xy and g^xs into the traffic keys, then you are protected if either y or s is leaked, which gives you somewhat stronger security properties with a DH cetificate The current key schedule accommodates that by allowing for SS to come before *or* after ES, but the simplified schedule does not quite so easily. With that said, TLS 1.3 doesn=E2=80=99t support *any* pure static DH design now and will do so even less well if we remove the key change as discussed above. There are at least three ways forward to incorporate them in future: - Just do as I suggest above. - Define a new DH cipher suite that adds an additional key change. This would allow us only to have the key change complexity in that mode. - Replace the 0 in the above schedule with g^xs and then define that the key for KeyUpdate is actually coming out of the final HKDF. Any of those seem like they wouldn=E2=80=99t be too hard to do, if and when we start having a lot of demand for DH certificates. Please discuss. -Ekr * Note that as I indicated in my previous message, it is possible to generate multiple sets of keys at the same stage, if that is necessary to handle the analysis concerns. --001a11414df0081211052c11bc90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi folks,

TL;DR.
L= et's simplify the key schedule.


DETAILS
This is the second in a series of proposed simplificatio= ns to TLS 1.3
based on implementation experience and analysis onc= e the protocol
starts to harden.=C2=A0 The following suggestion c= omes out of conversations
with Richard Barnes, Karthik Bhargavan,= Antoine Delignat-Lavaud,
Cedric Fournet, Markus Kohlweiss, Marti= n Thomson, Santiago Zanella and
others.

= The current key schedule is elegant but it is actually more than we
need in that it allows SS to be known either before or after ES. If we
assume (as is always true in the current TLS 1.3 modes) that SS is=
known before or at the same time as ES, then we can design a sim= pler
scheme which looks more like a ladder. Something like:
=

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SS -> HKDF [ClientHello= + Context]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0\
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 X1 =C2=A0 0-RTT Tra= ffic Keys *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ES= -> HKDF [ClientHello, ServerHello]
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0\
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 | =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0v
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 X2 =C2=A0 =C2=A01-RTT Traffic Keys *
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 -> HKDF [Clien= tHello...ClientFinished]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RMS, EMS

As sho= uld be apparent, this key schedule is well-suited to the
simplifi= ed key change schedule in my previous message.

Not= e 1: It might be attractive to not even bother with the first stage
if you aren't doing 0-RTT. It's not necessary then.=C2=A0 Howeve= r, this is
just an optimization. Also, if you don't want to e= xtract an RMS or an
EMS you can skip the last stage (this is comp= atible).

Note 2: The IKM for the final HKDF is 0, = but in principle we could use
it to add some sort of new keying m= aterial, for instance g^xs if we
were using static DH certificate= s (see below).


In line with Hugo= 9;s message earlier today, the major argument against
this design= is that it is more oriented towards a signature-based
system, wh= ich TLS 1.3 is today, than towards a DH certificate-based
system.= To elaborate on this a bit, in a DH certificate-based system,
th= e server authenticates by proving knowledge of g^xs (and hence
s)= . In the current TLS 1.3 design you can do this trivially by
repl= acing the signature in the server CertificateVerify with a MAC
ov= er the transcript (using g^xs as the key) [again, analysis needed.]
This is straightforward and doesn't require rearchitecting the
=
protocol really at all. However, this (as with the current
s= ignature-based mode) does not provide confidentiality of the
conn= ection if y is later revealed.

As Hugo has noted s= everal times, if you mix both g^xy and g^xs into
the traffic keys= , then you are protected if either y or s is leaked,
which gives = you somewhat stronger security properties with a DH
cetificate Th= e current key schedule accommodates that by allowing for
SS to co= me before *or* after ES, but the simplified schedule does not
qui= te so easily.=C2=A0

With that said, TLS 1.3 doesn= =E2=80=99t support *any* pure static DH design
now and will do so= even less well if we remove the key change as
discussed above. T= here are at least three ways forward to incorporate
them in futur= e:

- Just do as I suggest above.
- Defin= e a new DH cipher suite that adds an additional key change.
=C2= =A0 This would allow us only to have the key change complexity in
=C2=A0 that mode.
- Replace the 0 in the above schedule with g^x= s and then define that
=C2=A0 the key for KeyUpdate is actually c= oming out of the final HKDF.

Any of those seem lik= e they wouldn=E2=80=99t be too hard to do, if and when
we start h= aving a lot of demand for DH certificates.

Please = discuss.

-Ekr

* Note that= as I indicated in my previous message, it is possible to
gen= erate multiple sets of keys at the same stage, if that is necessary
to handle the analysis concerns.






--001a11414df0081211052c11bc90-- From nobody Thu Feb 18 17:04:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F7E1A871E for ; Thu, 18 Feb 2016 17:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6] autolearn=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 Xxj0UtaRYRRy for ; Thu, 18 Feb 2016 17:04:45 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9950E1A871B for ; Thu, 18 Feb 2016 17:04:45 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id g127so56006942ywf.2 for ; Thu, 18 Feb 2016 17: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:from:date:message-id:subject:to:content-type; bh=E7KZCaKsrxIRdYo0NOiqLFhVRMo17zFm+ycC/EiB1TA=; b=FniVcWrhlqpndsOeDyuNT44en3K62iSrAZJUrPDFcx8p5R/M9jtSE6O3NruEpwm7jS bjnf1v83BtY94U+15VAuospCoV2YwfOta1yi6SEKfdioKkjr54cyfYnFliNo9f13zeQ6 1KHcxOsi32AXV8MmTMaLYYqfCUKw3tCegrhrhkAUkrWjdUAeYk8LRfYlzk64nrpqzQ0A v7amKIOI39ClIjHXpItbsFwFHCh7E23TERes4x/CJyUV6LnrbENGXOAS4HEc8nV6HJAd miZqebMkmg/GzjorZ9lm31/MYileQ4iIEfaJOcypU8a4SBgT9+EAxVodazM6QZnkoLdL EiPA== 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 :content-type; bh=E7KZCaKsrxIRdYo0NOiqLFhVRMo17zFm+ycC/EiB1TA=; b=jMN15KLL+bCaVOF9+rJ6WjYcWgzJ8hLYQuI1gdcVBZJPWP5ePe9WYUBfldTh5Lq2dg yNEwmgUdGqJpVBas81dUPXbps/frWhkCSxvXdya/gnIV/ZJaJ/HkVu1LJfzHIVaueeZq tA/bhQw7z0do90mlBs6AljmNUn1Yrb7TwiefdoC13sLjSVWS1TJfX0JlP+nNICw6jUeR FryramprZOCVc0E8OmFxfgCmvE/ZBG+ymgT640wy7NmAYf+xHoPfBdVoSB4u7tA5EWTt eYfv1viZgxe965ksM/zZlEhpjMv511zgvSTEL3+Ab0+6BeUfvdLE/vQjatULjBviQvyV Iq4Q== X-Gm-Message-State: AG10YOREtPRU/PWQLDWltaF8qyUhSSmr6Ezq3Sp/5M0BR3gKrYaJwcERYMUOMIT8tdYgJ3lik8ENPMVi//GlCQ== X-Received: by 10.129.79.209 with SMTP id d200mr5966787ywb.115.1455843884916; Thu, 18 Feb 2016 17:04:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 18 Feb 2016 17:04:05 -0800 (PST) From: Eric Rescorla Date: Thu, 18 Feb 2016 18:04:05 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114bbc969c10b4052c1511b8 Archived-At: Subject: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 01:04:47 -0000 --001a114bbc969c10b4052c1511b8 Content-Type: text/plain; charset=UTF-8 TL;DR. Should we remove the semi-static DHE 0-RTT mode and just leave the PSK and PSK-DHE 0-RTT modes? DETAIL This is the last in the series of messages about changes to consider. TLS 1.3 currently supports two 0-RTT modes: - A semi-static Diffie-Hellman mode in which the server provides a long-term DH share and the data is protected under the client's ephemeral DH share and the server's long-term DH share. - A PSK mode in which the client and server establish a shared key in handshake #1 and then they use that to encrypt 0-RTT data in handshake #2. And of course you can use tickets. [Note that this isn't as completely specified as one might like, but as there is agreement that this should work, we need to fully specify it. I'm working on implementing it now and this should help flush out issues.] A number of people have independently observed that semi-static DHE for 0-RTT is not clearly better than DHE-PSK for 0-RTT and suggested that we limit 0-RTT to PSK and DHE-PSK [0], so I figured it was something we should disuss. Obviously this is a significant simplification, while still a big improvement over TLS 1.2-style resumption because it allows PFS and 0-RTT. Aside from simplicity, there are two major other considerations here: PFS and public "priming". PFS In the semi-static mode, the 0-RTT client data is encrypted under g^xs and the server's application data and any 1-RTT client app data is encrypted under both g^xy and g^xs, so you get PFS for any 1-RTT data but not for 0-RTT data, because as long as the server has s floating around, there is a risk that the attacker can attack the server, recover s, and decrypt any of the 0-RTT data. In PSK-DHE mode, the 0-RTT data is encrypted under the shared resumption master secret (r) and then the 1-RTT data is encrypted under both r and g^xy, so you get PFS for any 1-RTT data but not for 0-RTT data, because as long as the server has s floating around, there is a risk that the attacker can attack the server, recover s, and decrypt any of the 0-RTT data. If we assume that the server uses tickets, then r isn't stored but encrypted under some master key m. They key point is that in both cases the server has a long-term key floating around which is a risk to PFS. But the concerns are basically the same for m and s, so you can pretty much keep them around with the same kind of lifetime. As Adam Langley points out, the *client* has to store a long-term secret (r) in the DHE-PSK mode and if that is compromised, then an attacker can decrypt the 0-RTT data and potentially mount an active attack on future connections. This is a pretty qualitatively lower risk from compromise of the server's long-term DHE key. PUBLISHED CONFIGURATIONS The semi-static mode in principle allows the server to publish its configuration (i.e., it's semi-static key), e.g., via DNS, which the client can then use for 0-RTT handshakes on first contact. However, recent conversations (especially with the guys from Cloudflare) have convinced me that this probably isn't useful: DNS TXT record penetration rates are really bad and all the other proposed mechanisms are also pretty problematic. For the few protocols where I was thinking that this sort of priming was attractive, it turns out not to work well or to have other easier workarounds. WHAT ARE THE OPTIONS 1. Simply leave things as-is. 2. Just remove 0-RTT semi-static DHE 3. Remove 0-RTT semi-static DHE *and* 0-RTT client auth (on the theory that tickets let you carry it across connections). Obviously #3 is the biggest change, but also the biggest simplification. Both #2 and #3 are basically subsets of the existing protocol. In addition, if we decide to make this change, we should probably consider having some way for the client to indicate 0-RTT PSK-DHE but force the server to do a signature (thus proving possession of the signature key). I can think of a number of ways to design this easily, however. In terms of the way forward, if we can agree on a general strategy, I'll work up proposed text. Thanks, -Ekr [0] I've heard this suggested at one time or another by Watson Ladd, Cloudflare, and the INRIA/MSR Cambridge group. --001a114bbc969c10b4052c1511b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TL;DR.
Should we remove the semi-static DHE= 0-RTT mode and just leave
the PSK and PSK-DHE 0-RTT modes?
=


DETAIL
This is the last in the= series of messages about changes to consider.

TLS= 1.3 currently supports two 0-RTT modes:

- A semi-= static Diffie-Hellman mode in which the server provides
=C2=A0 a = long-term DH share and the data is protected under the client's
=C2=A0 ephemeral DH share and the server's long-term DH share.
=
=C2=A0=C2=A0
- A PSK mode in which the client and server est= ablish a shared
=C2=A0 key in handshake #1 and then they use that= to encrypt 0-RTT
=C2=A0 data in handshake #2. And of course you = can use tickets.
=C2=A0 [Note that this isn't as completely s= pecified as one might
=C2=A0 like, but as there is agreement that= this should work, we
=C2=A0 need to fully specify it. I'm wo= rking on implementing it now
=C2=A0 and this should help flush ou= t issues.]

A number of people have independently o= bserved that semi-static DHE
for 0-RTT is not clearly better than= DHE-PSK for 0-RTT and suggested
that we limit 0-RTT to PSK and D= HE-PSK [0], so I figured it was
something we should disuss. Obvio= usly this is a significant
simplification, while still a big impr= ovement over TLS 1.2-style
resumption because it allows PFS and 0= -RTT.


Aside from simplicity, there = are two major other considerations
here: PFS and public "pri= ming".

PFS
In the semi-static mode,= the 0-RTT client data is encrypted under g^xs
and the server'= ;s application data and any 1-RTT client app data is
encrypted un= der both g^xy and g^xs, so you get PFS for any 1-RTT data
but not= for 0-RTT data, because as long as the server has s floating
aro= und, there is a risk that the attacker can attack the server,
rec= over s, and decrypt any of the 0-RTT data.

In PSK-= DHE mode, the 0-RTT data is encrypted under the shared
resumption= master secret (r) and then the 1-RTT data is encrypted
under bot= h r and g^xy, so you get PFS for any 1-RTT data
but not for 0-RTT= data, because as long as the server has s floating
around, there= is a risk that the attacker can attack the server,
recover s, an= d decrypt any of the 0-RTT data. If we assume that
the server use= s tickets, then r isn't stored but encrypted under
some maste= r key m.

They key point is that in both cases the = server has a long-term key
floating around which is a risk to PFS= . But the concerns are basically
the same for m and s, so you can= pretty much keep them around with the
same kind of lifetime.

As Adam Langley points out, the *client* has to store= a long-term
secret (r) in the DHE-PSK mode and if that is compro= mised, then an
attacker can decrypt the 0-RTT data and potentiall= y mount an active
attack on future connections. This is a pretty = qualitatively lower
risk from compromise of the server's long= -term DHE key.


PUBLISHED CONFIGURAT= IONS
The semi-static mode in principle allows the server to publi= sh its
configuration (i.e., it's semi-static key), e.g., via = DNS, which the
client can then use for 0-RTT handshakes on first = contact. However,
recent conversations (especially with the guys = from Cloudflare) have
convinced me that this probably isn't u= seful: DNS TXT record
penetration rates are really bad and all th= e other proposed mechanisms
are also pretty problematic. For the = few protocols where I was
thinking that this sort of priming was = attractive, it turns out not to
work well or to have other easier= workarounds.


WHAT ARE THE OPTIONS<= /div>
1. Simply leave things as-is.
2. Just remove 0-RTT semi= -static DHE
3. Remove 0-RTT semi-static DHE *and* 0-RTT client au= th
=C2=A0 =C2=A0(on the theory that tickets let you carry it acro= ss connections).

Obviously #3 is the biggest chang= e, but also the biggest simplification.
Both #2 and #3 are basica= lly subsets of the existing protocol.

In addition,= if we decide to make this change, we should probably
consider ha= ving some way for the client to indicate 0-RTT PSK-DHE but
force = the server to do a signature (thus proving possession of the
sign= ature key). I can think of a number of ways to design this easily,
however.

In terms of the way forward, if we can = agree on a general strategy,
I'll work up proposed text.

Thanks,
-Ekr


[0] I've heard this suggested at one time or another by
<= div>Watson Ladd, Cloudflare, and the INRIA/MSR Cambridge group.
<= br>
--001a114bbc969c10b4052c1511b8-- From nobody Thu Feb 18 19:20:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 109281A9103 for ; Thu, 18 Feb 2016 19:20:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=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 jcP29AuQc8PE for ; Thu, 18 Feb 2016 19:20:36 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 173241A90FE for ; Thu, 18 Feb 2016 19:20:36 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id bc4so39868504lbc.2 for ; Thu, 18 Feb 2016 19:20:35 -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:content-type; bh=tJDOmPZ5lhMc1g1+IO6kFlH2TfunmjtlsDXuS1yhTQY=; b=kDLhNvyDTe+p6wtEVRsI+XJIXKYc/ROsiMV0AA7FMK1DH69t7l4geKqPZ3hnor6LPl xPZMxJfFYyk3fux1q72b/CM/0rDGKuVo51AIgxPU8lOCKY4g2otOlpEKeR32uyFNecus XB/ox7ByTKOlZdyfSx9BkHIdbBiZWU0QLoJAgaqPrHyhbzj1B5vXFxiI79mJz/6VzvO5 LP2NA+AnfhCDsr40ojjaXf1p61dV9lRDLSQfu6A5hl0Dn1OnjHM7BtSPhQlkcwi8Q5ip omVE6DBxizRjnNhMWYhwl7bzsXzuwkk2Bdds9/1J31cmxhfLuMCzGQbgFxu8EO9Srr6V +iZw== 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:content-type; bh=tJDOmPZ5lhMc1g1+IO6kFlH2TfunmjtlsDXuS1yhTQY=; b=ON5Qqwoi983ioHXjVcBLR4Jc8KDZlFCXUuqnMiEfvJk3ef+fku2UF4oUx521OCSi6/ 8eiE1Eyq9BtdUWmRfW0JalGeGVrxApmNy9RkAuqxXeLJyGkTncVKtXZCTrnAlp2Ip+Co lO422hxgltbawCmFsuSvzhipbNihkBQoU4/c9ydU2Mv0/EyDhGF5Pixgu7kFUYzdLkLK vfRDdD4mOOJYBdoOaJUTtZ8Jo9TEKEabAMejPsATGgsxDzq62a5F5gnvL1leMNYI6ikD wkd1K50BkkbZ4U2L0bGAFIU92728D26dYJXcECTSze0BgLcUNvgKk/2UVKqQ3WwKWXru Q8YQ== X-Gm-Message-State: AG10YOQFcoEVECnmHUDYJ8PIoCstFJKhkZ7utYMUmgCjuC+/i0VtRPQIGHM1wfLSRubHyCvWMO/dGqlkYcrvHg== X-Received: by 10.112.168.5 with SMTP id zs5mr4708477lbb.56.1455852034248; Thu, 18 Feb 2016 19:20:34 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Thu, 18 Feb 2016 19:20:04 -0800 (PST) In-Reply-To: References: From: Hugo Krawczyk Date: Thu, 18 Feb 2016 22:20:04 -0500 X-Google-Sender-Auth: ecDiD4ggAxfb3AeDHZb6X7l0H-s Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c2409a58d651052c16f777 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: Simplified Key Schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 03:20:40 -0000 --001a11c2409a58d651052c16f777 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree that once you remove the requirement to derive a key from g^xy (=3D= ES) for protecting a static DH key then the KDF scheme can be simplified as shown (or even further - see below). Note that this is (almost) exactly the original KDF scheme of OPTLS as I presented in Dallas https://www.ietf.org/proceedings/92/slides/slides-92-tls-4.pdf See slide 4 for the KDF scheme and slide 3 for the key names; it can be confusing as what I call ES (for Ephemeral-Static, or g^xs) is now called SS and what I call EE (for Ephemeral-Ephemeral, or g^xy) is now called ES. Also note that I simplified the presentation in these slides by referring t= o both HKDF-extract and HKDF-expand by PRF. Anyway, from here you can see that the last HKDF in your scheme (with 0 salt) is not needed. You can derive the RMS, EMS keys directly from the second HKDF (as siblings of 1-RTT Traffic Keys). Am I missing something? If the third HKDF is only to accommodate a DH-cert variant then I don't think it's worth it (if in that variant we will need a special key derivation step anyway then no need to plan for it now). If this third HKDF is needed for other reasons let me know. What I do miss in this scheme is the derivation of the Finished keys. I hop= e you do not intend to use the application key for this! I also want to stress, for the record, that this simplification has nothing to do with using the application keys for handshake protection. That "optimization" is orthogonal to this KDF simplification and hopefully will be reverted (*)= . (*) You may say I'm a dreamer, But I may not be the only one :-) Hugo PS: I have a disagreement with you in terms of the protocol now being "signature based". Yes there are signatures in the protocol but not all modes use them and they are not always needed. In my eyes the logic of the protocol is best seen as DH-based with authentication occurring through the server Finished MAC (with a key derived from SS which can take the values of g^xs, g^xy or PSK). That is common to *all* modes, including 0-RTT and PSK which do not build on signatures. This is how the protocol was built originally and that structure remains in spite of the added signatures. On Thu, Feb 18, 2016 at 4:05 PM, Eric Rescorla wrote: > Hi folks, > > TL;DR. > Let's simplify the key schedule. > > > DETAILS > This is the second in a series of proposed simplifications to TLS 1.3 > based on implementation experience and analysis once the protocol > starts to harden. The following suggestion comes out of conversations > with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud, > Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanella and > others. > > The current key schedule is elegant but it is actually more than we > need in that it allows SS to be known either before or after ES. If we > assume (as is always true in the current TLS 1.3 modes) that SS is > known before or at the same time as ES, then we can design a simpler > scheme which looks more like a ladder. Something like: > > 0 > | > SS -> HKDF [ClientHello + Context] > | \ > | \ > v v > X1 0-RTT Traffic Keys * > | > | > v > ES -> HKDF [ClientHello, ServerHello] > | \ > | \ > v v > X2 1-RTT Traffic Keys * > | > | > v > 0 -> HKDF [ClientHello...ClientFinished] > | > | > v > RMS, EMS > > As should be apparent, this key schedule is well-suited to the > simplified key change schedule in my previous message. > > Note 1: It might be attractive to not even bother with the first stage > if you aren't doing 0-RTT. It's not necessary then. However, this is > just an optimization. Also, if you don't want to extract an RMS or an > EMS you can skip the last stage (this is compatible). > > Note 2: The IKM for the final HKDF is 0, but in principle we could use > it to add some sort of new keying material, for instance g^xs if we > were using static DH certificates (see below). > > > In line with Hugo's message earlier today, the major argument against > this design is that it is more oriented towards a signature-based > system, which TLS 1.3 is today, than towards a DH certificate-based > system. To elaborate on this a bit, in a DH certificate-based system, > the server authenticates by proving knowledge of g^xs (and hence > s). In the current TLS 1.3 design you can do this trivially by > replacing the signature in the server CertificateVerify with a MAC > over the transcript (using g^xs as the key) [again, analysis needed.] > This is straightforward and doesn't require rearchitecting the > protocol really at all. However, this (as with the current > signature-based mode) does not provide confidentiality of the > connection if y is later revealed. > > As Hugo has noted several times, if you mix both g^xy and g^xs into > the traffic keys, then you are protected if either y or s is leaked, > which gives you somewhat stronger security properties with a DH > cetificate The current key schedule accommodates that by allowing for > SS to come before *or* after ES, but the simplified schedule does not > quite so easily. > > With that said, TLS 1.3 doesn=E2=80=99t support *any* pure static DH desi= gn > now and will do so even less well if we remove the key change as > discussed above. There are at least three ways forward to incorporate > them in future: > > - Just do as I suggest above. > - Define a new DH cipher suite that adds an additional key change. > This would allow us only to have the key change complexity in > that mode. > - Replace the 0 in the above schedule with g^xs and then define that > the key for KeyUpdate is actually coming out of the final HKDF. > > Any of those seem like they wouldn=E2=80=99t be too hard to do, if and wh= en > we start having a lot of demand for DH certificates. > > Please discuss. > > -Ekr > > * Note that as I indicated in my previous message, it is possible to > generate multiple sets of keys at the same stage, if that is necessary > to handle the analysis concerns. > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c2409a58d651052c16f777 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
= I agree that once you remove the require= ment to derive a key from g^xy (=3DES)
for protecting a static DH key then= the KDF scheme can be simplified as shown
(or even further - see below).<= /font>

Note that this is (almost) exactly the original KDF scheme of OPTLS = as I
presented in Dallas
https://www.ietf.org/proceedin= gs/92/slides/slides-92-tls-4.pdf
See slide 4 for the KDF scheme and sl= ide 3 for the key names; it can be
confusing as what I call ES (for Epheme= ral-Static, or g^xs) is now called=C2=A0
SS and what I call EE (for Epheme= ral-Ephemeral, or g^xy) is now called ES.
Also note that I simplified the = presentation in these slides by referring to
both HKDF-extract and HKDF-ex= pand by PRF.

Anyway, from here you can see that the last HKDF in you= r scheme (with 0 salt)
is not needed. You can derive the RMS, EMS keys di= rectly from the second HKDF
(as siblings of 1-RTT Traffic Keys). Am I miss= ing something?
If the third HKDF is only to accommodate a DH-cert variant = then I don't think
it's worth it (if in that variant we will need= a special key derivation step=C2=A0
anyway then no need to plan for it no= w). =C2=A0
If this third HKDF is needed for other reasons let me know.
What I do miss in this scheme is the derivation of the Finished keys. I= hope
you do not intend to use the application key for this!
<= div class=3D"gmail_default">
<= /div>
I also= want to stress, for the record, that this simplification has nothing to
d= o with using the application keys for handshake protection. That "opti= mization"
is orthogonal to this KDF simplification and hopefully will= be reverted (*).

(*) You may say I'm a dreamer, But I may not b= e the only one :-)

Hugo

PS: I have a disagreement with you in= terms of the protocol now being=C2=A0
"signature based". Yes th= ere are signatures in the protocol but not all modes
use them and they are= not always needed. In my eyes the logic of the protocol
is best seen as D= H-based with authentication occurring through the server
Finished MAC (wit= h a key derived from SS which can take the values of g^xs,
g^xy or PSK). T= hat is common to *all* modes, including 0-RTT and PSK which do
=
not build o= n signatures. This is how the protocol was built originally and
that struc= ture remains in spite of the added signatures.


On Thu, Feb 18, 2016 at 4:05 P= M, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

TL;DR.
Let's simplify the key schedule.


DETAILS
This is the second in a series of proposed simpl= ifications to TLS 1.3
based on implementation experience and anal= ysis once the protocol
starts to harden.=C2=A0 The following sugg= estion comes out of conversations
with Richard Barnes, Karthik Bh= argavan, Antoine Delignat-Lavaud,
Cedric Fournet, Markus Kohlweis= s, Martin Thomson, Santiago Zanella and
others.

The current key schedule is elegant but it is actually more than we=
need in that it allows SS to be known either before or after ES.= If we
assume (as is always true in the current TLS 1.3 modes) th= at SS is
known before or at the same time as ES, then we can desi= gn a simpler
scheme which looks more like a ladder. Something lik= e:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SS -> HKDF [C= lientHello + Context]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0\
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0v
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 X1 =C2=A0 0= -RTT Traffic Keys *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0ES -> HKDF [ClientHello, ServerHello]
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0v
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 X2 =C2=A0 =C2=A01-RTT Traffic Keys *
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 -> HKDF [C= lientHello...ClientFinished]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RMS, EMS

As= should be apparent, this key schedule is well-suited to the
simp= lified key change schedule in my previous message.

Note 1: It might be attractive to not even bother with the first stage
if you aren't doing 0-RTT. It's not necessary then.=C2=A0 Ho= wever, this is
just an optimization. Also, if you don't want = to extract an RMS or an
EMS you can skip the last stage (this is = compatible).

Note 2: The IKM for the final HKDF is= 0, but in principle we could use
it to add some sort of new keyi= ng material, for instance g^xs if we
were using static DH certifi= cates (see below).


In line with Hug= o's message earlier today, the major argument against
this de= sign is that it is more oriented towards a signature-based
system= , which TLS 1.3 is today, than towards a DH certificate-based
sys= tem. To elaborate on this a bit, in a DH certificate-based system,
the server authenticates by proving knowledge of g^xs (and hence
s). In the current TLS 1.3 design you can do this trivially by
= replacing the signature in the server CertificateVerify with a MAC
over the transcript (using g^xs as the key) [again, analysis needed.]
This is straightforward and doesn't require rearchitecting the
protocol really at all. However, this (as with the current
signature-based mode) does not provide confidentiality of the
= connection if y is later revealed.

As Hugo has not= ed several times, if you mix both g^xy and g^xs into
the traffic = keys, then you are protected if either y or s is leaked,
which gi= ves you somewhat stronger security properties with a DH
cetificat= e The current key schedule accommodates that by allowing for
SS t= o come before *or* after ES, but the simplified schedule does not
quite so easily.=C2=A0

With that said, TLS 1.3 do= esn=E2=80=99t support *any* pure static DH design
now and will do= so even less well if we remove the key change as
discussed above= . There are at least three ways forward to incorporate
them in fu= ture:

- Just do as I suggest above.
- De= fine a new DH cipher suite that adds an additional key change.
= =C2=A0 This would allow us only to have the key change complexity in
<= div>=C2=A0 that mode.
- Replace the 0 in the above schedule with = g^xs and then define that
=C2=A0 the key for KeyUpdate is actuall= y coming out of the final HKDF.

Any of those seem = like they wouldn=E2=80=99t be too hard to do, if and when
we star= t having a lot of demand for DH certificates.

Plea= se discuss.

-Ekr

* Note t= hat as I indicated in my previous message, it is possible to
= generate multiple sets of keys at the same stage, if that is necessary
to handle the analysis concerns.


<= div>




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


--001a11c2409a58d651052c16f777-- From nobody Thu Feb 18 21:44:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E4D1A908B for ; Thu, 18 Feb 2016 21:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4aSh0Bfyfykh for ; Thu, 18 Feb 2016 21:44:25 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 899A81A8FD6 for ; Thu, 18 Feb 2016 21:44:25 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id u9so30965859ykd.1 for ; Thu, 18 Feb 2016 21:44:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=fG4EoT4u/h5o6bbTKBErOadFFiJn7MrDhpPcMUdxjdY=; b=vs1wjDybk4ZwBUmEs+fjqaXHQi6MYa+fo4zeZ80PelURPVsHM95GvresPzjdXm09x1 +lRv/ittGj4e9QDMpb5zR7Bg+NQBG183jCpKB7Sa/MQGteKCU5EVsFOPOTrh/gdfMTA6 oU9AJ6W7bBLu4Caw5CXpAn7qJWl/sxf8w7CMrwjH1Crpeac9qB6KJ+MDV5GQuwW2HNWA QZlsW4PrdkhVHLZoOxZx1jOcwhLqcL26DeNEUmiwLSB1PX7Wg+Xm2C6O3hC68Dd1gJki OyutoMOiCi9ixlDvPnb5v7Tq7pYSL1gcJiD1xMERQjcQ3DMhsf/WMRGjmtKAq6uXpvEN izJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=fG4EoT4u/h5o6bbTKBErOadFFiJn7MrDhpPcMUdxjdY=; b=DhNkFVEMG4j2Awb0BXYJHvOBXQFkBx1CH969M/UKiz4CRc3bNqzXxHTYL9lB7PQkY2 A+vZmGx2i+BtPkzYXM6iu2fQklLwLJ5tE37dFzp1YveFv5jlBU5LFXBst4i17MI8ydXg ecYWcOh3ro6cYg3QgXr7fI61SOLLw12RlxlPTnl5eMc3C9tMuKPONKef8sd3I59hYV2Z PuIpXYnyl5M77ZBH5izwfG422DcoqHDHT/9TkCA4mpuoBrq2sqefv+QC1uCzTZbwWqNJ cvHweZkVcUtvGwnLOE92Rcf+D/0DxaI1vQNcihTt4sFSrpb0DgbUNYZ1gqXlRyhRLtOn VM5g== X-Gm-Message-State: AG10YOSvodS0Xa4jlL2W98kLcJjQZXieiFfawVY8h4yATMMKixdQw9XXnXgLaJodVy9ZAg== X-Received: by 10.37.94.215 with SMTP id s206mr95606ybb.119.1455860664824; Thu, 18 Feb 2016 21:44:24 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id i142sm7508681ywg.12.2016.02.18.21.44.24 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 18 Feb 2016 21:44:24 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Fri, 19 Feb 2016 00:44:22 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201602190044.23065.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 05:44:27 -0000 On Thursday, February 18, 2016 08:04:05 pm Eric Rescorla wrote: > PUBLISHED CONFIGURATIONS > The semi-static mode in principle allows the server to publish its > configuration (i.e., it's semi-static key), e.g., via DNS, which the > client can then use for 0-RTT handshakes on first contact. However, > recent conversations (especially with the guys from Cloudflare) have > convinced me that this probably isn't useful: DNS TXT record > penetration rates are really bad and all the other proposed mechanisms > are also pretty problematic. For the few protocols where I was > thinking that this sort of priming was attractive, it turns out not to > work well or to have other easier workarounds. > > WHAT ARE THE OPTIONS > 1. Simply leave things as-is. Nobody has enough of a reason to have support for DNS records that can do this, yet. Adding it here could change the situation over time. More importantly, some major sites/services might even want to just cut out the middle-ware and dump 0RTT configs into a client synced list of some sort, akin to how some handle HPKP. Not the most elegant of systems, but it would let clients that use such a list have out-of-the-box 0RTT to major high-traffic sites. Ad hoc systems would also be able to preload for 0RTT for their services easily (e.g. make an app & include 0RTT config cache with it). Even for clients merely getting their config via a first connection, we might be more likely to be able to cache for DHE safely longer than just for PSK for every client. I think it's a feature worth keeping. Dave From nobody Thu Feb 18 21:57:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7CD71A6FD9 for ; Thu, 18 Feb 2016 21:57:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 3sW1kH-WRVYk for ; Thu, 18 Feb 2016 21:57:05 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001:c06::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A66081A6FC2 for ; Thu, 18 Feb 2016 21:57:05 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id g203so99128933iof.2 for ; Thu, 18 Feb 2016 21:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s/MSPH2HcEhB55+IndqbRvsC5UieWHRNPDLPTT6q0Uo=; b=YbHDghXHJCJehQoAMSWk3+aDrQsh/zUEmeT52WBPvTNEQUDZwUOsjmNdYtHQxZrj1H r+yoON0sSzdzuECDhzA5WKk4lIn96s4TCPNYsYqqNcQODSpvHPZfG5kVmxBVzhbDtrwN L8iYAz/TxHB8/frH+bZA1AeNsQEkigPvCG6Hsd0NXF9rjunYyKRyy6x3REKu/TKg1jSY +WpVrUUQa4PhhN6WPxbh+0RbDqj/Se0rT9YlQ8h3Uvom/ihqqVgvrXPosOAa/lLgQkfE 6NqMJ9pZNQPY0+ofxkfugVi0QezUJdC3APGW3hRblIYfHDuDcTwziWnEy1Xa9Yp79cnJ fL9Q== 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:date :message-id:subject:from:to:cc:content-type; bh=s/MSPH2HcEhB55+IndqbRvsC5UieWHRNPDLPTT6q0Uo=; b=XA1i8VcnOYc/b33603HpMI3KR1fsVihMbWuHazN9llzJUmXI8Wto4OK6h3kAzQVxE0 KBLOvwJcxxKS1Lw3dqYpNxSqPMeJsjKiIOHXKxqRo1t8MOIGTxnrOBvHWU+PQmp+1JK9 iJXaoaK7oAurJeSkDyjQi3E+AsSekejpx+sc7Y4UoST3u4sPbYkQC0auzbz5XnFy860G iNZtGcOyPYT0RYlQvmb5PdQz5WWs6QijICPgKnFih1TWw5nNpCvvM4/vZsmIEMM/2hCF TdoVHsRb5q6dwqLeHd71eNepe+pReq4vVS6lczYkGGp55peNnoXlzRxf4VeK2NpmxAT0 rq8A== X-Gm-Message-State: AG10YOTgoBpcBDT1Nmpfiz1Wek8num+2IDig2EvHa1Bmsqgx8XgR7Eqeda9Ux3DVAp5//t6gC8VK2pLRQymi3tzt MIME-Version: 1.0 X-Received: by 10.107.131.155 with SMTP id n27mr13341408ioi.132.1455861425041; Thu, 18 Feb 2016 21:57:05 -0800 (PST) Received: by 10.107.183.141 with HTTP; Thu, 18 Feb 2016 21:57:04 -0800 (PST) In-Reply-To: <201602190044.23065.davemgarrett@gmail.com> References: <201602190044.23065.davemgarrett@gmail.com> Date: Thu, 18 Feb 2016 21:57:04 -0800 Message-ID: From: Bill Cox To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113eb96c154a01052c19279c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 05:57:06 -0000 --001a113eb96c154a01052c19279c Content-Type: text/plain; charset=UTF-8 On Thu, Feb 18, 2016 at 9:44 PM, Dave Garrett wrote: > > I think it's a feature worth keeping. > > I do not agree. Having two different modes to achieve basically the same thing in TLS 1.3 is a bad idea. Complexity is what will kill TLS, not a lack of different ways to do the same thing. If one mode must go (and one should), PSK seems the more worthy of the two, IMO. Bill --001a113eb96c154a01052c19279c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 18, 2016 at 9:44 PM, Dave Garrett <davemgarrett@gmail.com= > wrote:

I think it's a feature worth keeping.


I do not agree.=C2=A0 Having two diffe= rent modes to achieve basically the same thing in TLS 1.3 is a bad idea.=C2= =A0 Complexity is what will kill TLS, not a lack of different ways to do th= e same thing.=C2=A0 If one mode must go (and one should), PSK seems the mor= e worthy of the two, IMO.

Bill
--001a113eb96c154a01052c19279c-- From nobody Fri Feb 19 01:04:44 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A61B1ACEBE for ; Fri, 19 Feb 2016 01:04:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=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 3ZWby5MyDopP for ; Fri, 19 Feb 2016 01:04:41 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6C1E1ACEBD for ; Fri, 19 Feb 2016 01:04:40 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id g62so65827508wme.1 for ; Fri, 19 Feb 2016 01:04:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=djZ293Cv51QhhIydrvT3u/uwURJb8cjcnEAcRNQxR+Y=; b=yqF/QwKvf+AqEZZ8tPTuK3+xZ+Jo/1mZinpCgc55pkWl/jc2tgmHrh+GuSZN+oKm87 4z/wRr+mI3RlzUejxc1i2jjAM9bK9+PRgWFbnSV4zvYwfDBxWDUV2e+qECBHv8X1ucXi rDrKcDFZwA744F5IvBwjJ9M32K2GjD9RdWSk4iJrzzNItBFzPRMfHncr2w9finRMpoig pohQA8zn+xwqwRhNL1g3ROc3Vd9uZ+8mB3YKpEcnv/jqARHzJrAb8lQ9jmp/cHcggsfK K2+fgjNSdUotMyyn63s/bHKdTyqiGkPP4ZJoUqQjgOjk1gUlAiAatrGSkc0ueUranP0A xk8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=djZ293Cv51QhhIydrvT3u/uwURJb8cjcnEAcRNQxR+Y=; b=X9N+3VeeE5aJ2CGjq7d+3TJ0DZaf/tQDiIRiXCgI3yPVIN3kJ8ozHSuAEWQ5dI/ZZS SBf+cwKiIxdwxkJZtY/A4khQ5COcUMKHdji4oj2zAGQcvYVEMQINSqHsEq9dW7/XtUew gDbuQLm5PnhIMnyS7Lfq49Rc3A7qvclp00BMaaL7dynSDK30r1nE3eR4WxERtX5BUNWA 0TwGz3YUzGO+S6IYLzKD0rCjjOYnNLFSfS254fz1ZYeOI6fntWSf2JZM/tG6rEX9mzzw y8hiMOS4J0wzZDCStWA5KlUPIXyYmy5F+csvtEdexg5jzGCCvVgOM78F91+m4bWnMwi4 P8mw== X-Gm-Message-State: AG10YOT9aBqM4A1mEvG/oJDIamXVI7VfZtGh+C6YROw79P0vKswMG2EeeiXQStCZ8COhzQ== X-Received: by 10.28.226.6 with SMTP id z6mr7519689wmg.44.1455872679378; Fri, 19 Feb 2016 01:04:39 -0800 (PST) Received: from [128.93.85.206] ([128.93.85.206]) by smtp.gmail.com with ESMTPSA id ei9sm10221885wjd.40.2016.02.19.01.04.38 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 01:04:38 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Fri, 19 Feb 2016 10:04:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hugo Krawczyk X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 09:04:43 -0000 I do not have a very strong opinion on whether the same traffic keys can = or should be used for the handshake and application. As Hugo says, it = complicates the cryptographic analysis but we do know now how to do the = analysis for such key usage, thanks to years of work on TLS <=3D 1.2. I = am told that separate application and data keys would be tricky for DTLS = implementations, but it does not seem to matter too much in our TLS = implementation, where we already manage a sequence of epochs for TLS 1.2. Regardless of whether we make this change though, I think it would be = useful for the TLS 1.3 RFC to clearly limit the scope of various keys = generated by the handshake. During the connection lifetime, we generate = a series of record encryption keys: handshake and application keys for = 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying. = None of these keys should be used outside their intended use cases in a = single connection. The only cross-connection secret specified in the = protocol is the resumption master secret, and if applications want a key = from TLS 1.3, they must only use the exporter master secret. All other = keys are internal to TLS. We are in the process of implementing and analysing TLS 1.3 both in = miTLS and in ProVerif, and from our early experiments, the one thing = that is annoying to implement and analyze is the sheer number of places = in the handshake where we generate keys. This is awkward because we need = to mix in the handshake transcript at six different places, but also = because we occasionally need to keep internal HKDF extracted state = longer than necessary. These points are probably more relevant to = Ekr=E2=80=99s other email on the key schedule, and I will make them = there and at my TRON talk. Coming back to the application/handshake key = separation, I think I would be equally happy with deriving separate = application and data keys but at the same time, so that we can still = have three sets of keys, one for 0-RTT, one for 1-RTT, and one set of = Final keys for resumption and exporters at the end of the handshake. = This is essentially the same as Ekr=E2=80=99s proposal, except that we = derive separate handshake and application keys at each stage. It has the = minor added benefit of using HKDF as a black-box and not storing = extracted secrets. If this complicates DTLS implementations, it would be = worth understanding why. > On 18 Feb 2016, at 17:45, Hugo Krawczyk = wrote: >=20 > I want to point out that the benefits of using the application key = output by the > handshake protocol also for handshake traffic protection are not clear = cut.=20 > I cannot comment at the level of implementation simplification that = motivates > this change but I can comment on the cryptographic implications of = this change. >=20 > Yes, TLS 1.3, can probably be proved secure even with this key merge, = but it is > a proof of a *weaker* guarantee. When the application key is not used = during=20 > the exchange you can claim that the handshake protocol provide = *generic* key > exchange security. Here "generic" means that you can use the key with=20= > *any* application that requires a secret shared key. In contrast, = using the > application key during the key exchange process itself can still = guarantee > security for a *specific* application but not in general. That is, we = can now > prove security for the specific application of this key to protecting = TLS record > layer traffic (achieved via TLS message type separation). But if you = want to > take that same key and use it for a variant of the protocol or in a = different > application [1] then you need to go and re-analyze [2] the protocol = with that > specific application in mind. >=20 > Given the history of weaknesses in TLS I would prefer a more = conservative > design. TLS evolves and is used in places and ways not contemplated by = the > designers. For example, no one contemplated originally that people = will use a > MAC value or a session key as collision-resistant identifiers for = sessions but > people did. Models and requirements need to be strengthened over time, = not > weakened. The merge of handshake and application key is a weakening. >=20 > Finally, a side effect of this change is that it limits the generality = of the > protocol. Till now the protocol was ready for an immediate variant = where the > server uses a Diffie-Hellman certificate. It would require a minimal = adaptation > of the current specification where the CertificateVerify message is = omitted and > an entry in the key derivation table is added. But to encrypt the DH = certificate > you'd need to derive a key from g^xy only (which is not the case for = the > application key). The DH variant is not currently contemplated but one = that can > be handy in the future (it is a simpler protocol than what we have now = and can > have benefits in a "post-quantum transition").=20 >=20 > Hugo >=20 > PS: I wrote more about this topic here=20 > https://www.ietf.org/mail-archive/web/tls/current/msg13625.html > (it was in the context of the need to encrypt the Finished message but = the issue=20 > I was commenting on was the same as here, namely, the re-use of the = application=20 > key during the handshake) >=20 > [1] Given the wide availability of TLS implementations, it makes sense = for > different applications to use the TLS handshake as their key-exchange = protocol. > Fortunately, there is the exporter key that is still secure in the = stronger > generic sense and can be used for that purpose. Even then, I would = expect > people to use the application key as the natural session key, or be = tied to TLS > in a way that requires using the same application key. And, in any = case, changes > to the record layer protocol would require a re-assessment of security = in the > combined handshake-record protocol. >=20 > [2] The analysis of a protocol that breaks the generic and modular = security > principles is doable but more complex and needs to be re-assessed with = changes=20 > to the application protocol. >=20 >=20 > On Thu, Feb 18, 2016 at 9:54 AM, Eric Rescorla wrote: >=20 > On Thu, Feb 18, 2016 at 7:32 AM, Wan-Teh Chang wrote: > On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla wrote: > > > > TL;DR. > > I propose that we should not change keys between the handshake > > and application traffic keys. >=20 > Hi Eric, >=20 > I'm not sure if I understand your one-sentence summary, because > "change keys between the foo and bar keys" is hard to understand. Are > you proposing that we should use the same keys to encrypt handshake > messages and application data? >=20 > Yes, precisely. >=20 > -Ekr >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Feb 19 01:12:17 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0121A1B2B55 for ; Fri, 19 Feb 2016 01:12:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, SPF_PASS=-0.001] autolearn=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 6IRE9AgBJQUa for ; Fri, 19 Feb 2016 01:12:13 -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 D371F1B2B30 for ; Fri, 19 Feb 2016 01:12:12 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id g62so59882954wme.0 for ; Fri, 19 Feb 2016 01:12:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=5uTlqEBYDOpzZdnUMWlmKXmR06lhyjN4GkI3XxfblU4=; b=fSgMvjz5KtEHvV/EQ/R4+8+P9BNHQIOKNXySs4kzlQPgZU4p64XSegk5XHXxfdXgEq v1EHD1F242TjmoPVdC4igrHIw/jloNdC3mxbgYH0nRGFm/ENxo62RTbhaEO1XsyDRgax CIi+VRzEolBWe8Ul8IetxDfHX470FgW/CdbW2iCIwLRsMiXjMbjq0vbIDSYn/LQ8Yvr5 TOZU0iNmvhiHSmm2JFnmhVuCOUzFywYWOFSQPZUpjEoWEOSPGYbj+P4LbWJbNZHM6Pbb BR7ThibeUmqAwOz8gFPLNaRaeWPaksQwBzdYxXWN7i+t/yBPwUizqBGULRFTgxCrK7pf 24LQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=5uTlqEBYDOpzZdnUMWlmKXmR06lhyjN4GkI3XxfblU4=; b=Zkh+NnjEk15bKanaeacdk6Nvl+FmD8ULM4dEuL8/Giu09yda/N84TBXMq5PWtdFkiO GEzr4vCNBbPYpmyK3rcDVk56c66tv0ayJTsmmxanBXv+gJQG0/1q4EjWFeolJomFuqV1 1F+fVkU2lLMfaHhQfcLeNRHPWJ5E2L/xUYC+v9zO/QW4k9kJkSROK1lMhK30RXUejQPw Dv0URXeMK0FGQZmKhRJPY6dgxql0g1vDK/D7cYBg7jWpQKNxfk6LJWhaDqZvN+w6qAb0 T6dvdwUK8X2Cug9oCF79fHm1IWg3cJ6udxcJ6lePo73tIvUt0DIHTWuB3EbFa9D9fDnc /03g== X-Gm-Message-State: AG10YOSH/jeiWN/DmFgv2cP2d3oGM8E1lwgx4wGLgfwEFnRzNU78lLjodYdp8HUdt3Y3CA== X-Received: by 10.194.47.133 with SMTP id d5mr12866368wjn.87.1455873131430; Fri, 19 Feb 2016 01:12:11 -0800 (PST) Received: from [128.93.85.206] ([128.93.85.206]) by smtp.gmail.com with ESMTPSA id av3sm10244014wjc.44.2016.02.19.01.12.10 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 19 Feb 2016 01:12:10 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_223A9FCA-E13F-4B4A-9AAC-5D2EDC85C516" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Fri, 19 Feb 2016 10:12:09 +0100 Message-Id: <76B62127-231A-4F42-BBB6-E1F27BB6A6F3@gmail.com> References: To: Hugo Krawczyk X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: Simplified Key Schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 09:12:16 -0000 --Apple-Mail=_223A9FCA-E13F-4B4A-9AAC-5D2EDC85C516 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Note that this is (almost) exactly the original KDF scheme of OPTLS as = I > presented in Dallas Indeed, Ekr=E2=80=99s proposed scheme looks much like you original = diagram. > Anyway, from here you can see that the last HKDF in your scheme (with = 0 salt) > is not needed. You can derive the RMS, EMS keys directly from the = second HKDF > (as siblings of 1-RTT Traffic Keys). Am I missing something? The purpose of the third HKDF is to bind the handshake context (the full = transcript) into the resumption and exporter keys. It adds no new key material. > What I do miss in this scheme is the derivation of the Finished keys. = I hope > you do not intend to use the application key for this! Indeed those are missing in the picture, but I believe Ekr means to = derive separate finished keys alongside the 1-RTT Traffic keys (right after the = ServerHello) > I also want to stress, for the record, that this simplification has = nothing to > do with using the application keys for handshake protection. I agree, this key schedule simplification seems orthogonal. For what it=E2=80=99s worth, I am building a symbolic model of this new = key schedule and will report my analysis results at TRON. It=E2=80=99s not a cryptographic = proof, but it should shake out early logical bugs in the design, if any. Best, Karthik > That "optimization" > is orthogonal to this KDF simplification and hopefully will be = reverted (*). >=20 > (*) You may say I'm a dreamer, But I may not be the only one :-) >=20 > Hugo >=20 > PS: I have a disagreement with you in terms of the protocol now being=20= > "signature based". Yes there are signatures in the protocol but not = all modes > use them and they are not always needed. In my eyes the logic of the = protocol > is best seen as DH-based with authentication occurring through the = server > Finished MAC (with a key derived from SS which can take the values of = g^xs, > g^xy or PSK). That is common to *all* modes, including 0-RTT and PSK = which do > not build on signatures. This is how the protocol was built originally = and > that structure remains in spite of the added signatures. >=20 >=20 > On Thu, Feb 18, 2016 at 4:05 PM, Eric Rescorla > wrote: > Hi folks, >=20 > TL;DR. > Let's simplify the key schedule. >=20 >=20 > DETAILS > This is the second in a series of proposed simplifications to TLS 1.3 > based on implementation experience and analysis once the protocol > starts to harden. The following suggestion comes out of conversations > with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud, > Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanella and > others. >=20 > The current key schedule is elegant but it is actually more than we > need in that it allows SS to be known either before or after ES. If we > assume (as is always true in the current TLS 1.3 modes) that SS is > known before or at the same time as ES, then we can design a simpler > scheme which looks more like a ladder. Something like: >=20 > 0 > | > SS -> HKDF [ClientHello + Context] > | \ > | \ > v v > X1 0-RTT Traffic Keys * > | > | > v > ES -> HKDF [ClientHello, ServerHello] > | \ > | \ > v v > X2 1-RTT Traffic Keys * > | =20 > | > v =20 > 0 -> HKDF [ClientHello...ClientFinished] > | > | > v > RMS, EMS >=20 > As should be apparent, this key schedule is well-suited to the > simplified key change schedule in my previous message. >=20 > Note 1: It might be attractive to not even bother with the first stage > if you aren't doing 0-RTT. It's not necessary then. However, this is > just an optimization. Also, if you don't want to extract an RMS or an > EMS you can skip the last stage (this is compatible). >=20 > Note 2: The IKM for the final HKDF is 0, but in principle we could use > it to add some sort of new keying material, for instance g^xs if we > were using static DH certificates (see below). >=20 >=20 > In line with Hugo's message earlier today, the major argument against > this design is that it is more oriented towards a signature-based > system, which TLS 1.3 is today, than towards a DH certificate-based > system. To elaborate on this a bit, in a DH certificate-based system, > the server authenticates by proving knowledge of g^xs (and hence > s). In the current TLS 1.3 design you can do this trivially by > replacing the signature in the server CertificateVerify with a MAC > over the transcript (using g^xs as the key) [again, analysis needed.] > This is straightforward and doesn't require rearchitecting the > protocol really at all. However, this (as with the current > signature-based mode) does not provide confidentiality of the > connection if y is later revealed. >=20 > As Hugo has noted several times, if you mix both g^xy and g^xs into > the traffic keys, then you are protected if either y or s is leaked, > which gives you somewhat stronger security properties with a DH > cetificate The current key schedule accommodates that by allowing for > SS to come before *or* after ES, but the simplified schedule does not > quite so easily.=20 >=20 > With that said, TLS 1.3 doesn=E2=80=99t support *any* pure static DH = design > now and will do so even less well if we remove the key change as > discussed above. There are at least three ways forward to incorporate > them in future: >=20 > - Just do as I suggest above. > - Define a new DH cipher suite that adds an additional key change. > This would allow us only to have the key change complexity in > that mode. > - Replace the 0 in the above schedule with g^xs and then define that > the key for KeyUpdate is actually coming out of the final HKDF. >=20 > Any of those seem like they wouldn=E2=80=99t be too hard to do, if and = when > we start having a lot of demand for DH certificates. >=20 > Please discuss. >=20 > -Ekr >=20 > * Note that as I indicated in my previous message, it is possible to > generate multiple sets of keys at the same stage, if that is necessary > to handle the analysis concerns. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_223A9FCA-E13F-4B4A-9AAC-5D2EDC85C516 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Note that this is (almost) exactly the original KDF scheme of = OPTLS as I
presented in = Dallas

Indeed, Ekr=E2=80=99s proposed scheme looks much = like you original diagram.

Anyway, from here you can see = that the last HKDF in your scheme (with 0 salt)
is = not needed. You can derive the RMS, EMS keys directly from the second = HKDF
(as siblings of 1-RTT Traffic Keys). Am I missing = something?

The purpose of the third HKDF is to bind the = handshake context (the full transcript) into
the resumption = and exporter keys. It adds no new key material.

What= I do miss in this scheme is the derivation of the Finished keys. I = hope
you do not intend to use the application key for = this!

Indeed those are missing in the picture, but I = believe Ekr means to derive separate
finished keys alongside = the 1-RTT Traffic keys (right after the ServerHello)

I = also want to stress, for the record, that this simplification has = nothing to
do with using the application keys for handshake = protection.

I agree, this key schedule simplification seems = orthogonal.
For what it=E2=80=99s worth, I am building a = symbolic model of this new key schedule and will
report my = analysis results at TRON. It=E2=80=99s not a cryptographic proof, but it = should shake
out early logical bugs in the design, if = any.

Best,
Karthik


That= "optimization"
is orthogonal to this KDF = simplification and hopefully will be reverted (*).

(*) You may say I'm a dreamer, = But I may not be the only one :-)

Hugo

PS: I have a disagreement with = you in terms of the protocol now being 
"signature based". Yes there are signatures in the protocol = but not all modes
use them and they are not always = needed. In my eyes the logic of the protocol
is = best seen as DH-based with authentication occurring through the = server
Finished MAC (with a key derived from SS which = can take the values of g^xs,
g^xy= or PSK). That is common to *all* modes, including 0-RTT and PSK which = do
not build on signatures. This is how the protocol = was built originally and
that structure remains in spite = of the added signatures.


On Thu, Feb 18, 2016 at 4:05 PM, Eric Rescorla = <ekr@rtfm.com> wrote:
Hi folks,

TL;DR.
Let's = simplify the key schedule.


DETAILS
This is the second in a series of proposed simplifications to = TLS 1.3
based on implementation experience and = analysis once the protocol
starts to harden.  = The following suggestion comes out of conversations
with Richard Barnes, Karthik Bhargavan, Antoine = Delignat-Lavaud,
Cedric Fournet, Markus Kohlweiss, = Martin Thomson, Santiago Zanella and
others.

The current key schedule is elegant but it is actually more = than we
need in that it allows SS to be known = either before or after ES. If we
assume (as is = always true in the current TLS 1.3 modes) that SS is
known before or at the same time as ES, then we can design a = simpler
scheme which looks more like a ladder. = Something like:

                =         0
      =                   = |
              =    SS -> HKDF [ClientHello + Context]
                =         |  \
    =                     | =   \
            =             v    v
                =         X1   0-RTT Traffic Keys *
                =         |
      =                   = |
              =           v
    =              ES -> HKDF = [ClientHello, ServerHello]
      =                   | =  \
            =             |   \
                =         v    v
  =                     =   X2    1-RTT Traffic Keys *
  =                     =   |  
          =               |
                =         v    
  =                 0 -> HKDF = [ClientHello...ClientFinished]
      =                   = |
              =           |
    =                     = v
              =           RMS, EMS

As should be apparent, this key = schedule is well-suited to the
simplified key = change schedule in my previous message.

Note 1: It might be attractive to not = even bother with the first stage
if you aren't = doing 0-RTT. It's not necessary then.  However, this is
just an optimization. Also, if you don't want to extract an = RMS or an
EMS you can skip the last stage (this is = compatible).

Note 2: The IKM for the final HKDF is 0, but in principle we = could use
it to add some sort of new keying = material, for instance g^xs if we
were using static = DH certificates (see below).


In = line with Hugo's message earlier today, the major argument = against
this design is that it is more oriented = towards a signature-based
system, which TLS 1.3 is = today, than towards a DH certificate-based
system. = To elaborate on this a bit, in a DH certificate-based system,
the server authenticates by proving knowledge of g^xs (and = hence
s). In the current TLS 1.3 design you can do = this trivially by
replacing the signature in the = server CertificateVerify with a MAC
over the = transcript (using g^xs as the key) [again, analysis needed.]
This is straightforward and doesn't require rearchitecting = the
protocol really at all. However, this (as with = the current
signature-based mode) does not provide = confidentiality of the
connection if y is later = revealed.

As = Hugo has noted several times, if you mix both g^xy and g^xs = into
the traffic keys, then you are protected if = either y or s is leaked,
which gives you somewhat = stronger security properties with a DH
cetificate = The current key schedule accommodates that by allowing for
SS to come before *or* after ES, but the simplified schedule = does not
quite so easily. 

With that said, TLS 1.3 = doesn=E2=80=99t support *any* pure static DH design
now and will do so even less well if we remove the key change = as
discussed above. There are at least three ways = forward to incorporate
them in future:

- Just do as I suggest = above.
- Define a new DH cipher suite that adds an = additional key change.
  This would allow us = only to have the key change complexity in
  = that mode.
- Replace the 0 in the above schedule = with g^xs and then define that
  the key for = KeyUpdate is actually coming out of the final HKDF.

Any of those seem like = they wouldn=E2=80=99t be too hard to do, if and when
we start having a lot of demand for DH = certificates.

Please discuss.

-Ekr

* Note that as I indicated in my previous message, it is = possible to
generate multiple sets = of keys at the same stage, if that is necessary
to = handle the analysis concerns.







_______________________________________________
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

= --Apple-Mail=_223A9FCA-E13F-4B4A-9AAC-5D2EDC85C516-- From nobody Fri Feb 19 02:59:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9551B2B7D for ; Fri, 19 Feb 2016 02:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYjDY-HKmAFa for ; Fri, 19 Feb 2016 02:58:57 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id B27D61B29D5 for ; Fri, 19 Feb 2016 02:58:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id A4644378; Fri, 19 Feb 2016 12:58:55 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id H6x7oRrYJSQm; Fri, 19 Feb 2016 12:58:55 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5D4A8C4; Fri, 19 Feb 2016 12:58:55 +0200 (EET) Date: Fri, 19 Feb 2016 12:58:51 +0200 From: Ilari Liusvaara To: Karthikeyan Bhargavan Message-ID: <20160219105851.GA14585@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.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 10:59:00 -0000 On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote: > Regardless of whether we make this change though, I think it would be > useful for the TLS 1.3 RFC to clearly limit the scope of various keys > generated by the handshake. During the connection lifetime, we generate > a series of record encryption keys: handshake and application keys for > 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying. > None of these keys should be used outside their intended use cases in a > single connection. The only cross-connection secret specified in the > protocol is the resumption master secret, and if applications want a > key from TLS 1.3, they must only use the exporter master secret. All > other keys are internal to TLS. I think TLS 1.3 RFC should specify what the protocol looks like and how it can be used from application perspective. This includes specifying what keys can be exported (among many other things, like how authentication can be performed). I agree that exporting the main encryption keys or secrets those are derived from for any purpose is a rotten idea. If you need keying or authentication material, use TLS EXPORTER (tls-unique is deprecated) with requirement to use EMS on prior versions[1]. Then one might need to export RMS. I think it should be exported as blob that also contains other associated information (e.g ciphersuites). And possibly also encrypted, using some MRAE algorithm. [1] Compatiblity hack: One might consider EMS always negotiated when TLS 1.3 is negotiated. This could prvent applications that do know about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3. That is, if application asks about TLS 1.3 (ServerVersion 3.4) connection "is EMS enabled?" the answer will be always "yes" (since the point of that check is to exclude THS attacks, and TLS 1.3 already excludes those on baseline). -Ilari From nobody Fri Feb 19 06:15:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49DEB1A905E for ; Fri, 19 Feb 2016 06:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6] autolearn=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 H72bQPOwDgbM for ; Fri, 19 Feb 2016 06:15:25 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30251A897C for ; Fri, 19 Feb 2016 06:15:24 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id e63so67956078ywc.3 for ; Fri, 19 Feb 2016 06:15:24 -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:content-type; bh=LNkjGMxMoPXt1Fsy24b5ygXNCgn1D1+scUbINfzecYY=; b=zVbxTbHgbdPKO8Zc7SMdNeEj5C14mKhathVThj/sBwAqm715UupMrGKI/eq/G9kMBe 03nnRMQAhseHjAGHTe9BlPWiHFztt/pMyC07s3GavIvLfF/UfuiNI5ObNMW0u8ti9zN9 1zzIY7Wd53rw027WwefwyDaESbF4dllX7J3YRzei8ReTBBIajBqjrECQcomI3ZzR/Cru ZAuQR6q0jmBzevL5FRK9yxktEWNUzkuoomWT65I7C3gYVcJQ6oE9iV+9wtu21Ak7OxMC 9CGeuR/mwnhCLteR7mq217BR3/FChs4bH70SLt7a/LP7jtMdBMChtngl4uYu1tN1pj2E yfRA== 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-type; bh=LNkjGMxMoPXt1Fsy24b5ygXNCgn1D1+scUbINfzecYY=; b=kbvaCV9vfuothqPufeCF8rJjjoszjsC4HPNWYh39vw0H6KfMQohhl5uFU40RWvNRMK b7mwFs/6jo5DziyrcH2OabBGRBo9P76Wv1+GcOcKGZcef9AAIFyaHxc/Lz4ye7Kb/WI2 qjwwfSsHL1QfZYROZk5bjbJPdIX6Py9wgX0SNomJp1gTCYW0CPqs+IuNZjSbLLfbcdJs s2sx3h1zj3fBMN+7GurFxCFlJXA1FapxJyYiH9wj6xikJKFSPI5VzOwv460+JQIQU7nf wKMBX2TrW6Fgc1trJdqDm4KylK9oW3pM8ezoTHXCE8OfgLX2u2W5V67CpYlXt66ivrdm w4Lg== X-Gm-Message-State: AG10YORxtdjTX+VjDLvdMTId6eMurPwNvglKR6JhQK0SGCDZpzaEMf3PWL+88mwJ4EsxOJYesQIPG9Eotomkpw== X-Received: by 10.129.79.209 with SMTP id d200mr7341594ywb.115.1455891324002; Fri, 19 Feb 2016 06:15:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 19 Feb 2016 06:14:44 -0800 (PST) In-Reply-To: <76B62127-231A-4F42-BBB6-E1F27BB6A6F3@gmail.com> References: <76B62127-231A-4F42-BBB6-E1F27BB6A6F3@gmail.com> From: Eric Rescorla Date: Fri, 19 Feb 2016 07:14:44 -0700 Message-ID: To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a114bbc963331ee052c201dad Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: Simplified Key Schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:15:28 -0000 --001a114bbc963331ee052c201dad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > > Note that this is (almost) exactly the original KDF scheme of OPTLS as I > presented in Dallas > > > Indeed, Ekr=E2=80=99s proposed scheme looks much like you original diagra= m. > I would like to clarify that this isn't *my* scheme, though I think it's a good one. It came out of a long discussion with the people listed in my original message and probably is most closely derived from something Karthik drew. Sorry if I gave an impression to the contrary! In any case, I'm glad to see that it's close to Hugo's original diagram, since that's a good indication that we're on the right track! Anyway, from here you can see that the last HKDF in your scheme (with 0 > salt) > is not needed. You can derive the RMS, EMS keys directly from the second > HKDF > (as siblings of 1-RTT Traffic Keys). Am I missing something? > > > The purpose of the third HKDF is to bind the handshake context (the full > transcript) into > the resumption and exporter keys. It adds no new key material. > Yes, that was my understanding as well. I see that Ilari suggested that this might not be necessary (presumably as a consequence of having the full shares included in the stage 2 transcript rather than just the nonces as in TLS 1.2. The imperative here is to avoid creating an attack like triple handshake or the Cremers et al. attack on the PSK-resumption. In any case, having the EMS and RMS keys derived at the end also helps enforce the logic that you should never be exporting/resuming until you have actually completed the handshake. What I do miss in this scheme is the derivation of the Finished keys. I hop= e > you do not intend to use the application key for this! > > > Indeed those are missing in the picture, but I believe Ekr means to deriv= e > separate > finished keys alongside the 1-RTT Traffic keys (right after the > ServerHello) > Affirmative. Error in my diagram. I also want to stress, for the record, that this simplification has nothing > to > do with using the application keys for handshake protection. > > > I agree, this key schedule simplification seems orthogonal. > Yes, but... In the current 1-RTT mode, there is a derivation stage that does not appear on this diagram, one that includes the transcript up to the server CertificateVerify and is used to derive the application traffic keys. So, if part of the intent of this diagram is to reduce the number of points at which we derive, we will need to derive the application traffic keys at stage 2 even if they are separate from the handshake traffic keys. I believe this something you proposed, but I just want to clarify that this diagram would entail a change in the timing of key derivation, even if not the number of keys. > For what it=E2=80=99s worth, I am building a symbolic model of this new k= ey > schedule and will > report my analysis results at TRON. It=E2=80=99s not a cryptographic proo= f, but it > should shake > out early logical bugs in the design, if any. > > Best, > Karthik > > > That "optimization" > is orthogonal to this KDF simplification and hopefully will be reverted > (*). > > (*) You may say I'm a dreamer, But I may not be the only one :-) > > Nothing to be reverted yet, it's just a proposal. If it's a bad idea (and being prohibitively hard to analyze is one reason it might be) then we shouldn't adopt it. Hugo > > PS: I have a disagreement with you in terms of the protocol now being > "signature based". Yes there are signatures in the protocol but not all > modes > use them and they are not always needed. In my eyes the logic of the > protocol > is best seen as DH-based with authentication occurring through the server > Finished MAC (with a key derived from SS which can take the values of g^x= s, > g^xy or PSK). That is common to *all* modes, including 0-RTT and PSK whic= h > do > not build on signatures. This is how the protocol was built originally an= d > that structure remains in spite of the added signatures. > > Sorry about the misleading terminology. I just meant that it presently has signatures. I'll try to be more precise in future. -Ekr On Thu, Feb 18, 2016 at 4:05 PM, Eric Rescorla wrote: > >> Hi folks, >> >> TL;DR. >> Let's simplify the key schedule. >> >> >> DETAILS >> This is the second in a series of proposed simplifications to TLS 1.3 >> based on implementation experience and analysis once the protocol >> starts to harden. The following suggestion comes out of conversations >> with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud, >> Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanella and >> others. >> >> The current key schedule is elegant but it is actually more than we >> need in that it allows SS to be known either before or after ES. If we >> assume (as is always true in the current TLS 1.3 modes) that SS is >> known before or at the same time as ES, then we can design a simpler >> scheme which looks more like a ladder. Something like: >> >> 0 >> | >> SS -> HKDF [ClientHello + Context] >> | \ >> | \ >> v v >> X1 0-RTT Traffic Keys * >> | >> | >> v >> ES -> HKDF [ClientHello, ServerHello] >> | \ >> | \ >> v v >> X2 1-RTT Traffic Keys * >> | >> | >> v >> 0 -> HKDF [ClientHello...ClientFinished] >> | >> | >> v >> RMS, EMS >> >> As should be apparent, this key schedule is well-suited to the >> simplified key change schedule in my previous message. >> >> Note 1: It might be attractive to not even bother with the first stage >> if you aren't doing 0-RTT. It's not necessary then. However, this is >> just an optimization. Also, if you don't want to extract an RMS or an >> EMS you can skip the last stage (this is compatible). >> >> Note 2: The IKM for the final HKDF is 0, but in principle we could use >> it to add some sort of new keying material, for instance g^xs if we >> were using static DH certificates (see below). >> >> >> In line with Hugo's message earlier today, the major argument against >> this design is that it is more oriented towards a signature-based >> system, which TLS 1.3 is today, than towards a DH certificate-based >> system. To elaborate on this a bit, in a DH certificate-based system, >> the server authenticates by proving knowledge of g^xs (and hence >> s). In the current TLS 1.3 design you can do this trivially by >> replacing the signature in the server CertificateVerify with a MAC >> over the transcript (using g^xs as the key) [again, analysis needed.] >> This is straightforward and doesn't require rearchitecting the >> protocol really at all. However, this (as with the current >> signature-based mode) does not provide confidentiality of the >> connection if y is later revealed. >> >> As Hugo has noted several times, if you mix both g^xy and g^xs into >> the traffic keys, then you are protected if either y or s is leaked, >> which gives you somewhat stronger security properties with a DH >> cetificate The current key schedule accommodates that by allowing for >> SS to come before *or* after ES, but the simplified schedule does not >> quite so easily. >> >> With that said, TLS 1.3 doesn=E2=80=99t support *any* pure static DH des= ign >> now and will do so even less well if we remove the key change as >> discussed above. There are at least three ways forward to incorporate >> them in future: >> >> - Just do as I suggest above. >> - Define a new DH cipher suite that adds an additional key change. >> This would allow us only to have the key change complexity in >> that mode. >> - Replace the 0 in the above schedule with g^xs and then define that >> the key for KeyUpdate is actually coming out of the final HKDF. >> >> Any of those seem like they wouldn=E2=80=99t be too hard to do, if and w= hen >> we start having a lot of demand for DH certificates. >> >> Please discuss. >> >> -Ekr >> >> * Note that as I indicated in my previous message, it is possible to >> generate multiple sets of keys at the same stage, if that is necessary >> to handle the analysis concerns. >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > > > --001a114bbc963331ee052c201dad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan <kart= hik.bhargavan@gmail.com> wrote:

Note = that this is (almost) exactly the original KDF scheme of OPTLS as I<= /div>
pre= sented in Dallas

=
Indeed, Ekr=E2=80=99s proposed scheme looks much like you origi= nal diagram.

I would like= to clarify that this isn't *my* scheme, though I think it's a good=
one. It came out of a long discussion with the people listed in = my original
message and probably is most closely derived from som= ething Karthik
drew. Sorry if I gave an impression to the contrar= y!

In any case, I'm glad to see that it's = close to Hugo's original diagram,
since that's a good ind= ication that we're on the right track!


=
= Anyway, from here you can see that the l= ast HKDF in your scheme (with 0 salt)
is not needed. You can derive the RMS, EMS keys directly fro= m the second HKDF
(as s= iblings of 1-RTT Traffic Keys). Am I missing something?
<= /div>

The purpose of the third= HKDF is to bind the handshake context (the full transcript) into
the resumption and exporter keys. It adds no new key material.
=
=C2=A0
Yes, that was my understanding as = well. I see that Ilari suggested that this might
not be necessary= (presumably as a consequence of having the full shares
included = in the stage 2 transcript rather than just the nonces as in TLS 1.2.
<= div>The imperative here is to avoid creating an attack like triple handshak= e or
the Cremers et al. attack on the PSK-resumption. In any case= , having the
EMS and RMS keys derived at the end also helps enfor= ce the logic that you
should never be exporting/resuming until yo= u have actually completed the handshake.

=
What I do miss in this scheme is the derivation of the Fi= nished keys. I hope
you= do not intend to use the application key for this!

Indeed those are missing in = the picture, but I believe Ekr means to derive separate
finished = keys alongside the 1-RTT Traffic keys (right after the ServerHello)

Affirmative. Error in my diagram= .=C2=A0

I also want to = stress, for the record, that this simplification has nothing to
do with using the application keys= for handshake protection.

I agree, this key schedule simplification seems orth= ogonal.

Yes, but... In th= e current 1-RTT mode, there is a derivation stage
that does not a= ppear on this diagram, one that includes the transcript up to the
server CertificateVerify and is used to derive the application traffic key= s. So,
if part of the intent of this diagram is to reduce the num= ber of points at which
we derive, we will need to derive the appl= ication traffic keys at stage 2
even if they are separate from th= e handshake traffic keys. I believe this=C2=A0
something you prop= osed, but I just want to clarify that this diagram would entail
a= change in the timing of key derivation, even if not the number of keys.

=C2=A0
For what it=E2=80=99s worth, I am = building a symbolic model of this new key schedule and will
repor= t my analysis results at TRON. It=E2=80=99s not a cryptographic proof, but = it should shake
out early logical bugs in the design, if any.

Best,
Karthik
<= div>

That "optimization"
is orthogonal to this KDF simpli= fication and hopefully will be reverted (*).

(*) You may say I'm a dreamer, But I may not be the only one :-)
Nothing to be reverted yet, it's just a proposal. If it's a= bad idea (and being prohibitively
hard to analyze is one reason = it might be) then we shouldn't adopt it.


<= /div>
Hugo

PS: I have a disagreement with you in terms of the protocol now bein= g=C2=A0
"signature= based". Yes there are signatures in the protocol but not all modes
use them and they are not= always needed. In my eyes the logic of the protocol
is best seen as DH-based with authentication = occurring through the server
Finished MAC (with a key derived from SS which can take the values of= g^xs,
g^xy or PSK). Th= at is common to *all* modes, including 0-RTT and PSK which do
<= div>not build on signatures. This is how= the protocol was built originally and
that structure remains in spite of the added signatures.
=
Sorry about the misleading terminology. I just meant that it p= resently has signatures.=C2=A0
I'll try to be more precise in= future.

-Ekr


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
On Thu, Feb 18, 2016 at 4:05 = PM, Eric Rescorla <ekr@rtfm.com> wrote:
Hi folks,

TL;DR.
Let's simplify the key schedule.


<= /div>
DETAILS
This is the second in a series of proposed simp= lifications to TLS 1.3
based on implementation experience and ana= lysis once the protocol
starts to harden.=C2=A0 The following sug= gestion comes out of conversations
with Richard Barnes, Karthik B= hargavan, Antoine Delignat-Lavaud,
Cedric Fournet, Markus Kohlwei= ss, Martin Thomson, Santiago Zanella and
others.

The current key schedule is elegant but it is actually more than w= e
need in that it allows SS to be known either before or after ES= . If we
assume (as is always true in the current TLS 1.3 modes) t= hat SS is
known before or at the same time as ES, then we can des= ign a simpler
scheme which looks more like a ladder. Something li= ke:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SS -> HKDF [C= lientHello + Context]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0\
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | = =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0v
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 X1 =C2=A0 0= -RTT Traffic Keys *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0ES -> HKDF [ClientHello, ServerHello]
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0= \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 | =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0v
=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 X2 =C2=A0 =C2=A01-RTT Traffic Keys *
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 -> HKDF [C= lientHello...ClientFinished]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 RMS, EMS

As= should be apparent, this key schedule is well-suited to the
simp= lified key change schedule in my previous message.

Note 1: It might be attractive to not even bother with the first stage
if you aren't doing 0-RTT. It's not necessary then.=C2=A0 Ho= wever, this is
just an optimization. Also, if you don't want = to extract an RMS or an
EMS you can skip the last stage (this is = compatible).

Note 2: The IKM for the final HKDF is= 0, but in principle we could use
it to add some sort of new keyi= ng material, for instance g^xs if we
were using static DH certifi= cates (see below).


In line with Hug= o's message earlier today, the major argument against
this de= sign is that it is more oriented towards a signature-based
system= , which TLS 1.3 is today, than towards a DH certificate-based
sys= tem. To elaborate on this a bit, in a DH certificate-based system,
the server authenticates by proving knowledge of g^xs (and hence
s). In the current TLS 1.3 design you can do this trivially by
= replacing the signature in the server CertificateVerify with a MAC
over the transcript (using g^xs as the key) [again, analysis needed.]
This is straightforward and doesn't require rearchitecting the
protocol really at all. However, this (as with the current
signature-based mode) does not provide confidentiality of the
= connection if y is later revealed.

As Hugo has not= ed several times, if you mix both g^xy and g^xs into
the traffic = keys, then you are protected if either y or s is leaked,
which gi= ves you somewhat stronger security properties with a DH
cetificat= e The current key schedule accommodates that by allowing for
SS t= o come before *or* after ES, but the simplified schedule does not
quite so easily.=C2=A0

With that said, TLS 1.3 do= esn=E2=80=99t support *any* pure static DH design
now and will do= so even less well if we remove the key change as
discussed above= . There are at least three ways forward to incorporate
them in fu= ture:

- Just do as I suggest above.
- De= fine a new DH cipher suite that adds an additional key change.
= =C2=A0 This would allow us only to have the key change complexity in
<= div>=C2=A0 that mode.
- Replace the 0 in the above schedule with = g^xs and then define that
=C2=A0 the key for KeyUpdate is actuall= y coming out of the final HKDF.

Any of those seem = like they wouldn=E2=80=99t be too hard to do, if and when
we star= t having a lot of demand for DH certificates.

Plea= se discuss.

-Ekr

* Note t= hat as I indicated in my previous message, it is possible to
= generate multiple sets of keys at the same stage, if that is necessary
to handle the analysis concerns.


<= div>




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


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


--001a114bbc963331ee052c201dad-- From nobody Fri Feb 19 06:17:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 713731A8ABF for ; Fri, 19 Feb 2016 06:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 1_rI_AecgLTK for ; Fri, 19 Feb 2016 06:16:59 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C43421A897C for ; Fri, 19 Feb 2016 06:16:58 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id e63so67998679ywc.3 for ; Fri, 19 Feb 2016 06:16:58 -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:content-type; bh=7tUJ80u9zWnpfXhkTkuQ3H7l6uJxzWSXaveFGoNU4Eg=; b=y3Amrl75FPCiQiZAlwEisQ9TVBceprdzva7QpkJgWWzeWj8EOi+OoTfwVJ0aEov3WB l7un4kJvQp6CtaNSgAqOYROk7t9PVas5du9KWk+ZknHYXU9EkmphB68tDAx6CQ6mzDP0 j2H+yJK0tbQ1+phIMyO2NaatTyfDqcQ8orXBiBtgwUr5+rJELtL0ov7iTXnrV7wdRyBP XWfAenwb0pLozlTEoLQq1g/FhGhAZtvvVPgFzYhE/yMbnkj6o5j1WEFSCyGYbkNwdfF+ aXjYLtT5wuIzCwzNrsmx18TT98o/PDpr53CnPlj0L4t5rRmfch0rCdvkVG1vVstTh62K r/KA== 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-type; bh=7tUJ80u9zWnpfXhkTkuQ3H7l6uJxzWSXaveFGoNU4Eg=; b=CCu/+tL/5RIygHFs8ocMepsrc8DlZZTC+9jHsONuOCh2QwBZvN8q6eLhFPVympUEgp fqBndGu7aizqqb2URi/SJdvEgDDqyO/h3XIZxRQaffVn7ofw2szFUF525WAPdRRvMcJk gnfag2aAxLLFP0unHtUMoMqSwygr0MBJYwXqhsm4aM6pKTL8uTwbCI4FqS7OW3sj/ogq Hpl/1+aVgUiu8T8Nch9IM/IVtfC/QoCRMCixw9HfPvZvFDiKqLg0NY+7LGnbDh5wHIuu Q5cyw7DchGAScTNOV3hmdSg7VVV1HSRenxSzUAZpsv9ucFbAu+pR092/jBE+SN2tVZCw m/9Q== X-Gm-Message-State: AG10YOQP8FNgPh5XmT3HY/v0R9ec6WfD2uQJ6Z6rsMCRYWmAp601eZbNbJUoCQCdbN43/tgLMx/E1bIfwvFgzg== X-Received: by 10.13.193.4 with SMTP id c4mr8553744ywd.192.1455891418171; Fri, 19 Feb 2016 06:16:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 19 Feb 2016 06:16:18 -0800 (PST) In-Reply-To: <20160219105851.GA14585@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160219105851.GA14585@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 19 Feb 2016 07:16:18 -0700 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114caa9ed02296052c2022b8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 14:17:00 -0000 --001a114caa9ed02296052c2022b8 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara wrote: > On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote: > > > Regardless of whether we make this change though, I think it would be > > useful for the TLS 1.3 RFC to clearly limit the scope of various keys > > generated by the handshake. During the connection lifetime, we generate > > a series of record encryption keys: handshake and application keys for > > 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying. > > None of these keys should be used outside their intended use cases in a > > single connection. The only cross-connection secret specified in the > > protocol is the resumption master secret, and if applications want a > > key from TLS 1.3, they must only use the exporter master secret. All > > other keys are internal to TLS. > > I think TLS 1.3 RFC should specify what the protocol looks like and how > it can be used from application perspective. This includes specifying > what keys can be exported (among many other things, like how > authentication can be performed). > > I agree that exporting the main encryption keys or secrets those are > derived from for any purpose is a rotten idea. If you need keying or > authentication material, use TLS EXPORTER (tls-unique is deprecated) > with requirement to use EMS on prior versions[1]. > This is the intent. I think we would be well-served to state this. Then one might need to export RMS. I think it should be exported as > blob that also contains other associated information (e.g ciphersuites). > And possibly also encrypted, using some MRAE algorithm. > > > > [1] Compatiblity hack: One might consider EMS always negotiated when > TLS 1.3 is negotiated. This could prvent applications that do know > about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3. > > That is, if application asks about TLS 1.3 (ServerVersion 3.4) > connection "is EMS enabled?" the answer will be always "yes" > (since the point of that check is to exclude THS attacks, and > TLS 1.3 already excludes those on baseline). Good suggestion. This in fact is what NSS currently does: https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslinfo.c#70 -Ekr > > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114caa9ed02296052c2022b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On F= ri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote:

> Regardless of whether we make this change though, I think it would be<= br> > useful for the TLS 1.3 RFC to clearly limit the scope of various keys<= br> > generated by the handshake. During the connection lifetime, we generat= e
> a series of record encryption keys: handshake and application keys for=
> 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying= .
> None of these keys should be used outside their intended use cases in = a
> single connection.=C2=A0 The only cross-connection secret specified in= the
> protocol is the resumption master secret, and if applications want a > key from TLS 1.3, they must only use the exporter master secret. All > other keys are internal to TLS.

I think TLS 1.3 RFC should specify what the protocol looks like and = how
it can be used from application perspective. This includes specifying
what keys can be exported (among many other things, like how
authentication can be performed).

I agree that exporting the main encryption keys or secrets those are
derived from for any purpose is a rotten idea. If you need keying or
authentication material, use TLS EXPORTER (tls-unique is deprecated)
with requirement to use EMS on prior versions[1].

=
This is the intent. I think we would be well-served to state thi= s.


Then one might need to export RMS. I think it should be exported as
blob that also contains other associated information (e.g ciphersuites). And possibly also encrypted, using some MRAE algorithm.



[1] Compatiblity hack: One might consider EMS always negotiated when
TLS 1.3 is negotiated. This could prvent applications that do know
about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3.

That is, if application asks about TLS 1.3 (ServerVersion 3.4)
connection "is EMS enabled?" the answer will be always "yes&= quot;
(since the point of that check is to exclude THS attacks, and
TLS 1.3 already excludes those on baseline).

Good suggestion. This in fact is what NSS currently does:

-Ekr


=C2=A0
=C2=A0




-Ilari

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

--001a114caa9ed02296052c2022b8-- From nobody Fri Feb 19 07:01:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 147A71B30EB for ; Fri, 19 Feb 2016 07:01:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g-OOU4IwD__0 for ; Fri, 19 Feb 2016 07:01:34 -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 CCAC41ACEE6 for ; Fri, 19 Feb 2016 07:01:34 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 84512433433; Fri, 19 Feb 2016 15:01:33 +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 6E2B0433401; Fri, 19 Feb 2016 15:01:33 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1455894093; bh=51WBSjy+tYeMYZrw8RHUwhwKT/aF5sZaSJBRdnCu2W8=; l=546; h=From:To:Date:References:In-Reply-To:From; b=y+MPo0CF6bOpBxhM1yu5JxoYQokNFM4twciodA6uZlPA+og4KOmS1PjKpjzqWDCPx 0FtUNXeQZDSSrtnO4NFLBTbpT5VnctUlx6WItg3RdXCpatAZjSLdr7PjgnRSOijVT1 4VgqSOuxG44gBZ7PMFNetOg/n2qPHIfLhoi64bC4= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 51B561FC87; Fri, 19 Feb 2016 15:01:33 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Fri, 19 Feb 2016 09:01:32 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1076.000; Fri, 19 Feb 2016 09:01:32 -0600 From: "Salz, Rich" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Do we actually need semi-static DHE-based 0-RTT? Thread-Index: AQHRarGLa9EhrohM80eEsJBlM29TlJ8zdqvQ Date: Fri, 19 Feb 2016 15:01:31 +0000 Message-ID: <75b91c8af44e4520a5433d48c97582b0@ustx2ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.47.143] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 15:01:37 -0000 SSBncmVhdGx5IHByZWZlciBvbmUgd2F5IHRvIGRvIHRoaW5ncy4gIChQeXRob24gbm90IHBlcmws IGlmIHlvdSB3aWxsIDopDQoNCk9uIHRoZSBvdGhlciBoYW5kLCB0aGVyZSBpcyBhbiBlbGVnYW5j ZSBhYm91dCB1c2luZyBhIHNpbmdsZSB3ZWxsLXVuZGVyc3Rvb2QgbWVjaGFuaXNtIGV2ZW4gaWYg aXQgaGFzIG9wZXJhdGlvbmFsIGJ1cmRlbnMuICBXZSBhbGwga25vdyBob3cgdG8gc2VjdXJlIFBT SyBtYXRlcmlhbCwgdGhvdWdoLCByaWdodD8gOikgIEJ1dCB3aGF0IGRvc2UgdGhpcyBkbyBhYm91 dCBlbmNyeXB0ZWQtU05JPyANCg0KLS0gIA0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hu b2xvZ2llcw0KSU06IHJpY2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0KDQoNCg== From nobody Fri Feb 19 09:59:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1FE11B338C for ; Fri, 19 Feb 2016 09:59:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKYxx6SuF_Li for ; Fri, 19 Feb 2016 09:58:55 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0745.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:745]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0561B3375 for ; Fri, 19 Feb 2016 09:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jKlXc5UvxfTOgbmWC1HUiB/7IjPuCQody34yItTk/zQ=; b=J4vk27yL/5rdywxmGseARlCN4JVYvEsMftRUFKPg/rnUOZQPaHGqrQH3dVzW75GxFH6Fk4TQ4Qfan6LaI61ut5ZLYT3D7npzwp0BQKEYpDHCl3I6OL1MQS8kbEhVMD7Mh3SZmepiidUq66tgfM38gSanAvLF8JZjxbalu9XEbZ4= Received: from DM2PR03CA0052.namprd03.prod.outlook.com (10.141.96.51) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 19 Feb 2016 17:58:31 +0000 Received: from BN1BFFO11FD022.protection.gbl (2a01:111:f400:7c10::1:196) by DM2PR03CA0052.outlook.office365.com (2a01:111:e400:2428::51) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Fri, 19 Feb 2016 17:58:31 +0000 Authentication-Results: spf=pass (sender IP is 206.191.249.68) smtp.mailfrom=microsoft.com; rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=pass action=none header.from=microsoft.com; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.249.68 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.249.68; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.249.68) by BN1BFFO11FD022.mail.protection.outlook.com (10.58.144.85) with Microsoft SMTP Server (TLS) id 15.1.415.6 via Frontend Transport; Fri, 19 Feb 2016 17:58:29 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net (141.251.48.82) by AM3PR30MB049.064d.mgd.msft.net (141.251.48.82) with Microsoft SMTP Server (TLS) id 15.1.415.9; Fri, 19 Feb 2016 17:58:28 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) by AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) with mapi id 15.01.0415.013; Fri, 19 Feb 2016 17:58:28 +0000 From: Cedric Fournet To: Eric Rescorla , Ilari Liusvaara Thread-Topic: [TLS] Proposal: don't change keys between handshake and application layer Thread-Index: AQHRallRU9dkEV6l5E6zOYRLVi6qCZ8x48sAgAAfHgCAARGDAIAAH+mAgAA3KwCAADW28A== Date: Fri, 19 Feb 2016 17:58:28 +0000 Message-ID: References: <20160219105851.GA14585@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.48.133] X-MS-Office365-Filtering-Correlation-Id: 65833c1d-a697-45a6-fbb0-08d33956464e Content-Type: multipart/alternative; boundary="_000_b0a287111e974361b4894f7f10d762f6AM3PR30MB049064dmgdmsft_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1BFFO11FD022; 1:Io9pXwfYVGlnQjmrtI7vMGCI8J9r3JIBBXTdxPIQeaoPowAj3dmx2ZTH0t8TEe01QabHTuop8LMbOx9dkMTAqvlnAwOOIOyLEbPU0b/c16pQ7XCDo6P/6o8OUTiQxAL/FeWqmkfGh/zUl7x4szRMGU6R6yU+VngVI7hsXDH85mjmUHyly/CPPoXrxi+DLXuj8AYNAuSNDV89HOmakseMmSUqXPN62mcz91nsCzaU8/SsQi3bm20MQ5AbRyh4lXzI/1YCDKlmGk5DALxFwnkTug3XEudSbAPb3ZaNrJNMQTfh2KIng/EyJzhV0O3J0OWFi3GaGE+B/GHnB7NSBXTMr16fEB4CQnhLW3/Nw+YmtTh7bmvDma9EYRqZEAKzUF08 X-Forefront-Antispam-Report: CIP:206.191.249.68; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(377454003)(189002)(24454002)(3905003)(199003)(108616004)(5003600100002)(1096002)(1220700001)(106466001)(92566002)(4326007)(300700001)(189998001)(5004730100002)(84326002)(106116001)(10090500001)(5001770100001)(16796002)(6806005)(11100500001)(5001960100002)(15975445007)(5008740100001)(16236675004)(86612001)(512874002)(86362001)(86146001)(33646002)(24736003)(2900100001)(19580405001)(93886004)(102836003)(790700001)(561944003)(3846002)(19617315012)(586003)(66066001)(1720100001)(54356999)(6116002)(5005710100001)(87936001)(10290500002)(10400500002)(2906002)(19300405004)(2950100001)(19580395003)(76176999)(50986999)(19625215002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0653; 2:uwLWxE5tAkrw/ZJ/q1qe+3gMXPM3fhJjKFsNujSuULbY1a0sj2qo6IMpc90tdJXmsbemK9QOw5wRfGN0TLYUHJ/qOorxjfEM3yk8SJXtqeB423p7OBXMCZj59Jp6Uwvj4XzoYW2QbCf238aUSXZykbg1/exEydLalwrQhR1A/tvwRveSFChZb1CvD8F6Rglf; 3:Fqxjp7jfIOOgD4uStFiSByvvJhPrR7XMvpvQv1dPWOUmU4A9l7+wymyC78IGFg+a7JNPpzYVyFfJ0uoX+HB4B1DmCAv1b45F66eTjWXhEpYq2UXyHR2K3SGczXIuganD1sh3rAXCuHQN0d1R1j+4PCU87M4RXxkoN0nowjlHp5IZyo4dCbbsJX0gvrDTz/3ABObQ+2zU8IKI3SxIebPGK6I+AaQf5K/b8G0yFFD1q4MLgM4ITY02Sq3ilexDVZp3489Y2sLSF0bkcg8Paak5lA==; 25:wCVFgMe9k/fHA4Z810csraKzritjj6M9joU5daIyW67VcqnOIMmHq9KEo4HS7s7kYOiyC1jeIaJr4nX2tkcx2b6L0829olPSX4roJqSxMuhP855Wc59wjs/kqTo4PfOrS6KbxDDghxrosjViPWtNLS5gawiauSZRlAcxiOAR5Bp/JThOxh3sLjHBY0K98dwmFPs6fLSfUonu0Utn99ejGsKn5kTCdd1oCKck0K5zvTc2Ogluxx+uj6JjDVSnO4+eEEX0H7P1dRgJCXIIHIPBwnLaueDmmJHaQETNxAWrxgDe1Fjj/ep8voWsI5MV5ICqtJ2S6M8R5vHmTqs8YE7WREITlvXtNTPVLbzNAv30ugA= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:DM2PR0301MB0653; X-O365EOP-Header: O365_EOP: Allow for Unauthenticated Relay X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0653; 20:ZRbrLMs+qZnyOLbjKT/fANjaHcTOjFP52hD6M1Gftepw3MizEm1dy53sL+yxMyyso63AO8SPcjgk/EMm6yeRoYz+oCmTue1ERaP34iUSLbETx7NZHuqNg2/xZE5mtqmJoGBBGl0tkymmVcKmvGAMXUVUYe4xg8E5pOUxJeupezx32+oQoCZUhgHxruE0jLFEtcdi9lmq0urD7lVo5TwqL9Od16uoEGJpHe5popNjUkAPdilpESKYpLi8G+yv83VYYaWP6RuS4E8QepavxvrPH2/9Bqv0HZ2LOEedloD6lLhKjG3QzR0tMQ1E576zpsIv/4PbS6HpVXTK6LOFMEVPVPQiUSsMy9itptSk3eC0n7enRfPSJ9BRkhxzN81ACtheneZAAO40grMq7d1qIzjFIMZPb8GS+OJI9RwOuQIncI4Fss9U4q0ekJMB/SLH5/5ItIKNlsVaLWapYq6P6LzjVZDKGkB11q9vHJjPDF8sORmZjFa9mdDlOEF6wITm+DWtHiBBtJZsaUIKnzgFWY46bDTvuVK+sq5oWHWZVHiX4p8cT6b5WpIKqyQYA2XOfqmaZDmkzPoOwjbP4w6Z2ruhufe0C416ofJawnSh+ermxEs= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(13016025)(13024025)(5005006)(13018025)(13013025)(13023025)(13021025)(3002001)(10201501046)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0653; 4:yFmnO4z9B7n1vANekmH5JA/3SL/EchsTjjDyPZLF6HMggKnuV0ilG4hGKGXxsWzV5WW7zkD7cYSjn40/qrnnhyVG/rZldTLNynuYxpbHRlz89xf8yCGgsHBqvUz35Z4sfwNtyrQbAutgMp4o0FWfGLQxdOmmW4dwJf8OCD2+tt9QDAl915IpB1tKhW8go9o0S5HxBTBinoIVdD81mBtSXVL5IOnlhUO2MUPv5kSLrONY3dpPKPqzivyKHBAfQFclH6WiTCB548o6KzgtMA7nz1bUAWOqFBeM6xfhtbsuV9DvUJN1IcnvW+ZUZC1nmekAcIHpX0n3q148al5vTD2MM1AYfqmC0kmLuqH/3lw3p/Midb9OejAwts/2adkqIHpcTH7/SBqiwDEEdgRnTzZ/zqbdPWyu0oApclrc6NPAd0vDiIHjxhYsddi2AkgF4SmloorhWrujIqxKIUtu5ntyjq+g25MLeyi0MotSfDkkoTKOfLLPpxmGvE3vI6cRVxajXbYZcXOo0d7Tgn90nTuGvO5iHzIt/mkiYMS7prykrXw= X-Forefront-PRVS: 08572BD77F X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM2PR0301MB0653; 23:IB+OxKU3pjkZkZkeK+O0N+RuQcAxQ+6JfAPC5RR?= =?us-ascii?Q?0BASPWHQh/hwT22dOYAvURv58v2Ej6vyhvGYCNmKbINxpsMyFSRNDAKuvlbg?= =?us-ascii?Q?B4L0EcnUrgOmIhdpy+rLqQjrpG5KNbYOaQlD9lX7jlNFn9HiqJE4ccgltsAs?= =?us-ascii?Q?jseU+RqUzxpGDqxBuPxFjP3cfkMUCsor/zaXzELRGabY861zRPJ2tmOOPm8W?= =?us-ascii?Q?qpEGcrwyIBiVdj+/3Y+g56kC9hjvAXSu+eSop0p+dLG6XeXmv5zjPLPbHNb8?= =?us-ascii?Q?+tDtgJmQsWf16H/mQDo9F/qBFrbAiRgye8CO4YScjWsMOxkULvrBRkVquDf7?= =?us-ascii?Q?4czOxEUDEC43r9i5T8v9jr9+dxC6e1d2b2Za1w3yVpV1RafYvTC/caUWxVe1?= =?us-ascii?Q?a/xqyFtNoPis+dTpp6iJMaCe+cCE/eCqaHHw6p65Y0gGpABNJjQF2ItPQdDH?= =?us-ascii?Q?LDEf4yBKBr4AjlrMscA1eCHs+yQnCdRCFhlIYoz1r9i45Yi72d6vfjVhd8h8?= =?us-ascii?Q?lAB898RkthFBNNiT5GcK59oVEKBK8MKpbXdAiUvn6GlJAIilRatds6gFNbnj?= =?us-ascii?Q?pQUfgXQNBERdxwrlFWFPwH2bUcOBMyZYndNv3rH+T/SRLw/Yuym5X+pLYH9i?= =?us-ascii?Q?LwUyvosl9oA0b1Ng3fuVHVIFnlNQPHLxz1FM6M1ztYe7h+s3lRgmW+wgcIX4?= =?us-ascii?Q?NHUvrSaWwENXOCIY41P4ZK5z03H1L97ZR5fcYPqIV1pnDXOa+a4x8ajvzXyD?= =?us-ascii?Q?+pvDLFu8mVK3aB6z4bdlIhA5Sv/EK4+V70FC9XzQd5HZlF+SoHVspb01+5K8?= =?us-ascii?Q?wb0op+t6pqby41fm3fVQeUvrDH3recMk4jybaRejkgL4WqgSLgQAH0oIW0zY?= =?us-ascii?Q?/h+U2nLehRqXaC7jrvYSw/SuV/f90hG/SN23KhDpuua4ZAmdKqhcqHt8PwZa?= =?us-ascii?Q?Qn5tYj93l8Au7hVbuBir62aZlUc9z6A7cetaCIYCicBHDgaqaSP0ymFwikWD?= =?us-ascii?Q?0Ocbkk9HJwtSs6+Tr6hpJ8wXkDaxlDz7lnX/EmCtxf+jMn1QMc8VhAAsdkfS?= =?us-ascii?Q?iFc/3lCw7paCd/CH97PKTosJEEkZ+mAygZBrpb1/lAobERX2zRdIvr6Gf9Mj?= =?us-ascii?Q?q3RwB2JM/FDxlh9YCh2xblAeESXTsrNEoOYdPfZbpk5APCqdxI49N7gRV7H0?= =?us-ascii?Q?fZP2bjGiuUWbf/zrtv9GHhEUm598ArL0jYsgSqoKsrEGPkvEVe12x8L0MCsB?= =?us-ascii?Q?933RGzyv/We4kJwhnOupTwu77FTtnvalLNbmRwqaNN4YRPOWxHU+JB1rYCGM?= =?us-ascii?Q?WTXRvlNwFkkHZhu2bz6NBCp4mAwmxfTAzhkA3mitKBWUPbe2FfjR2l74ti/D?= =?us-ascii?Q?mRdPtrLzSujWL7xxR8aAgVhcqcoQWX9qyPMjLygsAv82oNKmWUx6XOh9oYhX?= =?us-ascii?Q?/vlcAgKkXB8x8pCa09/dFYO2vrxSycuJJaCMTuRixx7Yi8OR2fFAwwAeweKc?= =?us-ascii?Q?GEc7DjtKFYvJOf54S5exu2SYOZTwOhy+/Wu7GS+t/acocp8LeFOm2ppR8?= X-Microsoft-Exchange-Diagnostics: 1; DM2PR0301MB0653; 5:Zha9n7cbMoU9iGjj+WIIfcVvdqpLAToXrtiRAug7vTHhFo+pzod3fOkJr5ZyjHjALf/ksIGLlIpsoZ2YvEL6gnZS+B5R6xwZwKwPwfoR54fsjzZ1+bjx+Aq3ZzV5c4uyT5AReBYi25zM36gO5Vt5pA==; 24:/isCEtvzWDJ0Ca7hfA6ERJB9mm5GAr2HI3FjvMOxi8qza9wX6bTQ7ko9Z4/X78LAubXZvVzFxpI/y8jj9MjYVu6btNFhCxtQz4t+x+20wbw= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Feb 2016 17:58:29.6895 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.249.68]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Cc: Karthikeyan Bhargavan , Markulf Kohlweiss , "tls@ietf.org" , Antoine Delignat-Lavaud Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 17:59:01 -0000 --_000_b0a287111e974361b4894f7f10d762f6AM3PR30MB049064dmgdmsft_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgcG9pbnRlZCBvdXQgYnkgS2FydGhpaywgd2UgYXJlIG5vdCBzdHJvbmdseSBhZHZvY2F0aW5n IHRoaXMgc2ltcGxpZmljYXRpb24sIGJ1dCB3ZSBkbyBub3QgdGhpbmsgaXQgd291bGQgd2Vha2Vu IHRoZSBzZWN1cml0eSBvZiBUTFMuIERldGFpbHMgYmVsb3cuDQoNCi1Dw6lkcmljLCB3aXRoIHRo ZSBtaVRMUyB0ZWFtDQoNCg0KSW4gdGhlIGZvbGxvd2luZywgSSBvbmx5IGNvbnNpZGVyIHRoZSBy ZWNvcmQgbGF5ZXIga2V5cywgd2hpY2ggYXJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0ZWQgZW5jcnlw dGlvbjsgSSBpZ25vcmUgYWxsIG90aGVyIGRlcml2ZWQga2V5IG1hdGVyaWFscy4gVGhlIFRMUyBs YXllcmVkIGRlc2lnbiBnb2VzIGFzIGZvbGxvd3M6DQotIFRoZSBoYW5kc2hha2UgcHJvdmlkZXMg ZnJlc2gga2V5cyB0byB0aGUgcmVjb3JkIGxheWVyIChkZXBlbmRpbmcgb24gaXRzIGludGVybmFs IHN0YXRlIG1hY2hpbmUpIGFuZCBrZWVwcyBydW5uaW5nOw0KLSBUaGUgcmVjb3JkIGxheWVyIHVz ZXMgdGhlIGN1cnJlbnQga2V5cyBmb3IgZW5jcnlwdGluZyAqYWxsKiB0cmFmZmljLCBtaXhpbmcg aGFuZHNoYWtlIG1lc3NhZ2VzLCBhbGVydHMsIGFuZCBhcHBsaWNhdGlvbiBkYXRhIChvbmNlIGVu YWJsZWQpLg0KDQpUaGVzZSBrZXlzIGFyZSB1c2VkIHNlcXVlbnRpYWxseSwgYW5kIG9ubHkgYnkg dGhlIHJlY29yZC1sYXllci4gVGhleSBhcmUgbm90IGRpcmVjdGx5IHVzZWQgd2l0aGluIHRoZSBo YW5kc2hha2UgcHJvdG9jb2wgaXRzZWxmLCBvciBieSB0aGUgVExTIGFwcGxpY2F0aW9uLg0KLSBT aW5jZSB0aGUgc2VxdWVuY2Ugb2Yga2V5cyBpcyBtZWFudCB0byBwcm90ZWN0IHRoZSB3aG9sZSBz dHJlYW0gb2YgVExTIGZyYWdtZW50cywgb25lIG5lZWRzIHRvIGF1dGhlbnRpY2F0ZSBlYWNoIHBv aW50IGluIHRoZSBzdHJlYW0gd2hlcmUgdGhlcmUgaXMgYSBrZXkgY2hhbmdlLCB0byBwcmV2ZW50 IGFueSB0cmFmZmljIHRydW5jYXRpb24uIEFzIGRpc2N1c3NlZCBpbiBhbm90aGVyIHRocmVhZCwg d2UgYmVsaWV2ZSB0aGlzIGlzIGNvcnJlY3RseSBoYW5kbGVkIGluIGRyYWZ0IzExLCBidXQgZWFj aCBrZXkgY2hhbmdlIHJlbWFpbnMgYSBzb3VyY2Ugb2YgY29tcGxpY2F0aW9uIFsxXS4NCi0gVGhl cmUgYXJlIGV4Y2VsbGVudCByZWFzb25zIHRvIGNoYW5nZSBrZXlzIGJldHdlZW4gMC1SVFQgYW5k IDEtUlRUIChzdHJvbmdlciBrZXkgbWF0ZXJpYWxzLCBmb3J3YXJkIHNlY3JlY3kpLg0KLSBPdGhl cndpc2UsIHdoYXQgbWF0dGVycyBpcyB0aGUgcHJvdmVuYW5jZSBvZiB0aGUga2V5IChob3cgaXQg d2FzIGRlcml2ZWQsIHdoYXQgaWRlbnRpdGllcyBhcmUgYXNzb2NpYXRlZCB3aXRoIGl0KSBhbmQg dGhlcmUgaXMgbm8gcG9pbnQgY2hhbmdpbmcga2V5cyB3aXRoIHRoZSBzYW1lIHByb3ZlbmFuY2Uu DQoNClRoZSBzaXR1YXRpb24gaXMgcGFydGljdWxhcmx5IGNsZWFyIGluIDAtUlRUOiBpbiBkcmFm dCMxMSwgdGhlIGNsaWVudCBhbHdheXMgZGVyaXZlcyB0d28gcmVjb3JkLWxheWVyIGtleXMgZnJv bSB0aGUgc2FtZSBtYXRlcmlhbHMsIGFuZCB1c2VzIGVhY2ggb2YgdGhlc2Uga2V5cyBpbiB0dXJu IHRvIGVuY3J5cHQgaGFsZiBvZiBpdHMgMC1SVFQgZmxpZ2h0LCB3aXRoIGEgRmluaXNoZWQgbWVz c2FnZSBpbi1iZXR3ZWVuIHRoYXQgc2lnbmFscyB0aGUga2V5IGNoYW5nZS4gVGhpcyBrZXkgY2hh bmdlIGRvZXMgbm90IGRlZ3JhZGUgc2VjdXJpdHksIGJ1dCBzZWVtcyB1bm5lY2Vzc2FyeS4NCg0K SW4gMS1SVFQsIHRoaXMgaXMgbGVzcyBvYnZpb3VzIGJlY2F1c2UsIGluIGRyYWZ0IzExLCB0aGUg aGFuZHNoYWtlIGtleXMgYW5kIGFwcGxpY2F0aW9uLWRhdGEga2V5cyBhcmUgbm90IGV4YWN0bHkg ZGVyaXZlZCBmcm9tIHRoZSBzYW1lIG1hdGVyaWFscy4gV2UgYmVsaWV2ZSB0aGlzIHNob3VsZCBi ZSBmaXhlZCAoc2VlIHRoZSDigJxzaW1wbGlmaWVkIGtleSBzY2hlZHVsZeKAnSB0aHJlYWQpLiBU aGVuIHRoZSBzYW1lIGFyZ3VtZW50IGFwcGxpZXM6IHRoZSBrZXkgY2hhbmdlIGlzIG5vdCB0ZXJy aWJsZSwgYnV0IGl0IGlzIGFuIHVubmVjZXNzYXJ5IGNvbXBsaWNhdGlvbi4NCg0KSSBkaXNhZ3Jl ZSB3aXRoIEh1Z28gdGhhdCB1c2luZyB0aGUgc2FtZSByZWNvcmQtbGF5ZXIga2V5IGZvciBoYW5k c2hha2UgYW5kIGFwcGxpY2F0aW9uIGRhdGEgeWllbGRzIGEgcHJvb2Ygb2YgYSB3ZWFrZXIgZ3Vh cmFudGVlLiBBcyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhpcyBpcyBhIHRlY2huaWNhbGl0eSBpbiB0 aGUgY3J5cHRvZ3JhcGhpYyBwcm9vZiBvZiB0aGUgaGFuZHNoYWtlLCBhbmQgd2Ugc3RpbGwgZ2V0 IHRoZSBzYW1lIHNlY3VyaXR5IGd1YXJhbnRlZXMgZm9yIFRMUyB1c2VycyBbMl0uIEkgYWxzbyBs aWtlIHNpbXBsZSBwcm9vZnMgb2YgZ2VuZXJpYyBzZWN1cml0eSBmb3IgdGhlIGhhbmRzaGFrZSBj b3JlLCBidXQgSSBkbyBub3Qgc2VlIGhvdyB0aGV5IGNhbiBjb3ZlciB0aGUgb3RoZXIgZmVhdHVy ZXMgb2YgVExTIFtlLmcuIDMsIGFuZCBsYXRlIGhhbmRzaGFrZSBtZXNzYWdlc10gd2l0aCBvciB3 aXRob3V0IHRoZSBzaW1wbGlmaWNhdGlvbi4gR2l2ZW4gdGhlIGNob2ljZSBiZXR3ZWVuIGEgc2lt cGxlciBwcm90b2NvbCB0aGF0IGl0IGlzIGVhc2llciB0byBpbXBsZW1lbnQgY29ycmVjdGx5LCBh bmQgc2ltcGxlciBwcm9vZnMgZm9yIGEgY29yZSwgSSB3b3VsZCByYXRoZXIgc2ltcGxpZnkgdGhl IG92ZXJhbGwgcHJvdG9jb2wgYW5kIGRvIHRoZSBleHRyYSBwcm9vZiB3b3JrLg0KDQpPbmUgbWF5 IGFyZ3VlIGFib3V0IHdoYXQgd291bGQgaGFwcGVuIGlmIHNvbWUgb2YgdGhlIHJlY29yZC1sYXll ciBrZXlzIHdlcmUgbWlzLXVzZWQsIGFnYWluc3QgdGhlIFRMUyBzcGVjaWZpY2F0aW9uIChkZXNw aXRlIGl0cyBleHBvcnQgbWVjaGFuaXNtKSBhbmQgY29uY2x1ZGUgdGhhdCB3ZSBuZWVkIG1vcmUs IG5vdCBsZXNzIGtleSBjaGFuZ2VzIFszXS4gQnV0IEkgd291bGQgbm90IGNhbGwgaXQg4oCcYSBk aWZmZXJlbnQgYXBwbGljYXRpb27igJ0gYW5kIEkgYW0gc3RpbGwgdGVtcHRlZCB0byBzaW1wbGlm eSB0aGUga2V5IHNjaGVkdWxlIGZvciBpdHMgaW50ZW5kZWQgdXNhZ2UgaW4gVExTLg0KDQoNClsx XSBBbiBhdHRhY2tlciBtYXksIGZvciBpbnN0YW5jZSwgZGVsZXRlIHRoZSBsYXN0IGZyYWdtZW50 IGVuY3J5cHRlZCBiZWZvcmUgdGhlIGtleSBjaGFuZ2UuIFN1Y2ggYSBkZWxldGlvbiB3aWxsIGJl IGNhdWdodCBhdCB0aGUgcHJvdG9jb2wgbGF5ZXIsIGUuZy4gYmVjYXVzZSB0aGUgbGFzdCBmcmFn bWVudCBpcyBub3QgYW4g4oCcZW5kX29mX2Vhcmx5X2RhdGHigJ0gYWxlcnQgb3IgYSBGaW5pc2hl ZCBtZXNzYWdlLiBXaXRob3V0IHRoZSBrZXkgY2hhbmdlLCBhbnkgZGVsZXRpb24gd291bGQgYmUg Y2F1Z2h0IGltbWVkaWF0ZWx5LCBhcyB0aGUgbmV4dCBmcmFnbWVudCBkZWNyeXB0aW9uIGZhaWxz Lg0KDQpbMl0gd2UgZG8gbm90IGhhdmUgYSBjb21wbGV0ZSBtb2RlbCBmb3IgVExTIDEuMyB5ZXQs IGJ1dCB3ZSBkZXZlbG9wZWQgYSBkZXRhaWxlZCBtb2RlbCBmb3IgVExTIDEuMiBodHRwOi8vZXBy aW50LmlhY3Iub3JnLzIwMTQvMTgyIHNpbWlsYXJseSBjb3ZlcmluZyByZWNvcmQtbGF5ZXIga2V5 IGNoYW5nZXMgKGZvciByZW5lZ290aWF0aW9ucykgYW5kIHRoZSBmYWN0IHRoYXQgdGhvc2Uga2V5 cyB3ZXJlIHVzZWQgdG8gcHJvdGVjdCB0aGUgRmluaXNoZWQgbWVzc2FnZXMgKmJlZm9yZSoga2V5 IGNvbmZpcm1hdGlvbiBhbmQgYXBwbGljYXRpb24tZGF0YSB0cmFmZmljLiBUaGUgbWFpbiBkaWZm ZXJlbmNlIHdpdGggY2xhc3NpYyBtb2RlbHMgZm9yIGtleSBleGNoYW5nZSwgd2hlcmUgdGhlIHBy b3RvY29sIHJ1bnMgdG8gY29tcGxldGlvbiBhbmQgcmV0dXJucyDigJx0aGXigJ0gYXBwbGljYXRp b24ga2V5LCBpcyB0aGF0IGluIG91ciBtb2RlbCB0aGUgaG9uZXN0IGluc3RhbmNlcyBwcm92aWRl IGtleXMgZHVyaW5nIHRoZSBwcm90b2NvbCBydW4uDQoNClszXSBhcyByZWNlbnRseSBkaXNjdXNz ZWQgYXMgMC41LVJUVCwgdGhlIHNwZWMgZW5hYmxlcyB0aGUgdXNlIG9mIDEtUlRUIGtleXMgYmVm b3JlIGNvbXBsZXRpbmcgdGhlIGhhbmRzaGFrZSwgd2l0aCB3ZWFrZXIgZ3VhcmFudGVlcyBvbiB0 aGUgZW5jcnlwdGVkIGFwcGxpY2F0aW9uIGRhdGEuIEhvd2V2ZXIsIGFuIGV4dHJhIGtleSBjaGFu Z2Ugd291bGQgcmVxdWlyZSBhZGRpdGlvbmFsIHNpZ25hbGxpbmcgbWVzc2FnZXMuDQoNCg0KRnJv bTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJl c2NvcmxhDQpTZW50OiAxOSBGZWJydWFyeSAyMDE2IDE0OjE2DQpUbzogSWxhcmkgTGl1c3ZhYXJh IDxpbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20+DQpDYzogS2FydGhpa2V5YW4gQmhhcmdhdmFuIDxr YXJ0aGlrLmJoYXJnYXZhbkBnbWFpbC5jb20+OyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBb VExTXSBQcm9wb3NhbDogZG9uJ3QgY2hhbmdlIGtleXMgYmV0d2VlbiBoYW5kc2hha2UgYW5kIGFw cGxpY2F0aW9uIGxheWVyDQoNCg0KDQpPbiBGcmksIEZlYiAxOSwgMjAxNiBhdCAzOjU4IEFNLCBJ bGFyaSBMaXVzdmFhcmEgPGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbTxtYWlsdG86aWxhcmlsaXVz dmFhcmFAd2VsaG8uY29tPj4gd3JvdGU6DQpPbiBGcmksIEZlYiAxOSwgMjAxNiBhdCAxMDowNDoz OEFNICswMTAwLCBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gd3JvdGU6DQoNCj4gUmVnYXJkbGVzcyBv ZiB3aGV0aGVyIHdlIG1ha2UgdGhpcyBjaGFuZ2UgdGhvdWdoLCBJIHRoaW5rIGl0IHdvdWxkIGJl DQo+IHVzZWZ1bCBmb3IgdGhlIFRMUyAxLjMgUkZDIHRvIGNsZWFybHkgbGltaXQgdGhlIHNjb3Bl IG9mIHZhcmlvdXMga2V5cw0KPiBnZW5lcmF0ZWQgYnkgdGhlIGhhbmRzaGFrZS4gRHVyaW5nIHRo ZSBjb25uZWN0aW9uIGxpZmV0aW1lLCB3ZSBnZW5lcmF0ZQ0KPiBhIHNlcmllcyBvZiByZWNvcmQg ZW5jcnlwdGlvbiBrZXlzOiBoYW5kc2hha2UgYW5kIGFwcGxpY2F0aW9uIGtleXMgZm9yDQo+IDAt UlRUIGFuZCAxLVJUVCwgYW5kIHRoZW4gYSBzZXF1ZW5jZSBvZiBrZXlzIGdlbmVyYXRlZCBkdXJp bmcgcmVrZXlpbmcuDQo+IE5vbmUgb2YgdGhlc2Uga2V5cyBzaG91bGQgYmUgdXNlZCBvdXRzaWRl IHRoZWlyIGludGVuZGVkIHVzZSBjYXNlcyBpbiBhDQo+IHNpbmdsZSBjb25uZWN0aW9uLiAgVGhl IG9ubHkgY3Jvc3MtY29ubmVjdGlvbiBzZWNyZXQgc3BlY2lmaWVkIGluIHRoZQ0KPiBwcm90b2Nv bCBpcyB0aGUgcmVzdW1wdGlvbiBtYXN0ZXIgc2VjcmV0LCBhbmQgaWYgYXBwbGljYXRpb25zIHdh bnQgYQ0KPiBrZXkgZnJvbSBUTFMgMS4zLCB0aGV5IG11c3Qgb25seSB1c2UgdGhlIGV4cG9ydGVy IG1hc3RlciBzZWNyZXQuIEFsbA0KPiBvdGhlciBrZXlzIGFyZSBpbnRlcm5hbCB0byBUTFMuDQoN CkkgdGhpbmsgVExTIDEuMyBSRkMgc2hvdWxkIHNwZWNpZnkgd2hhdCB0aGUgcHJvdG9jb2wgbG9v a3MgbGlrZSBhbmQgaG93DQppdCBjYW4gYmUgdXNlZCBmcm9tIGFwcGxpY2F0aW9uIHBlcnNwZWN0 aXZlLiBUaGlzIGluY2x1ZGVzIHNwZWNpZnlpbmcNCndoYXQga2V5cyBjYW4gYmUgZXhwb3J0ZWQg KGFtb25nIG1hbnkgb3RoZXIgdGhpbmdzLCBsaWtlIGhvdw0KYXV0aGVudGljYXRpb24gY2FuIGJl IHBlcmZvcm1lZCkuDQoNCkkgYWdyZWUgdGhhdCBleHBvcnRpbmcgdGhlIG1haW4gZW5jcnlwdGlv biBrZXlzIG9yIHNlY3JldHMgdGhvc2UgYXJlDQpkZXJpdmVkIGZyb20gZm9yIGFueSBwdXJwb3Nl IGlzIGEgcm90dGVuIGlkZWEuIElmIHlvdSBuZWVkIGtleWluZyBvcg0KYXV0aGVudGljYXRpb24g bWF0ZXJpYWwsIHVzZSBUTFMgRVhQT1JURVIgKHRscy11bmlxdWUgaXMgZGVwcmVjYXRlZCkNCndp dGggcmVxdWlyZW1lbnQgdG8gdXNlIEVNUyBvbiBwcmlvciB2ZXJzaW9uc1sxXS4NCg0KVGhpcyBp cyB0aGUgaW50ZW50LiBJIHRoaW5rIHdlIHdvdWxkIGJlIHdlbGwtc2VydmVkIHRvIHN0YXRlIHRo aXMuDQoNCg0KVGhlbiBvbmUgbWlnaHQgbmVlZCB0byBleHBvcnQgUk1TLiBJIHRoaW5rIGl0IHNo b3VsZCBiZSBleHBvcnRlZCBhcw0KYmxvYiB0aGF0IGFsc28gY29udGFpbnMgb3RoZXIgYXNzb2Np YXRlZCBpbmZvcm1hdGlvbiAoZS5nIGNpcGhlcnN1aXRlcykuDQpBbmQgcG9zc2libHkgYWxzbyBl bmNyeXB0ZWQsIHVzaW5nIHNvbWUgTVJBRSBhbGdvcml0aG0uDQoNCg0KDQpbMV0gQ29tcGF0aWJs aXR5IGhhY2s6IE9uZSBtaWdodCBjb25zaWRlciBFTVMgYWx3YXlzIG5lZ290aWF0ZWQgd2hlbg0K VExTIDEuMyBpcyBuZWdvdGlhdGVkLiBUaGlzIGNvdWxkIHBydmVudCBhcHBsaWNhdGlvbnMgdGhh dCBkbyBrbm93DQphYm91dCBFTVMgYnV0IG5vdCBUTFMgMS4zIGZyb20gYnJlYWtpbmcgd2hlbiB1 cGdyYWRpbmcgdG8gVExTIDEuMy4NCg0KVGhhdCBpcywgaWYgYXBwbGljYXRpb24gYXNrcyBhYm91 dCBUTFMgMS4zIChTZXJ2ZXJWZXJzaW9uIDMuNCkNCmNvbm5lY3Rpb24gImlzIEVNUyBlbmFibGVk PyIgdGhlIGFuc3dlciB3aWxsIGJlIGFsd2F5cyAieWVzIg0KKHNpbmNlIHRoZSBwb2ludCBvZiB0 aGF0IGNoZWNrIGlzIHRvIGV4Y2x1ZGUgVEhTIGF0dGFja3MsIGFuZA0KVExTIDEuMyBhbHJlYWR5 IGV4Y2x1ZGVzIHRob3NlIG9uIGJhc2VsaW5lKS4NCg0KR29vZCBzdWdnZXN0aW9uLiBUaGlzIGlu IGZhY3QgaXMgd2hhdCBOU1MgY3VycmVudGx5IGRvZXM6DQpodHRwczovL2R4ci5tb3ppbGxhLm9y Zy9tb3ppbGxhLWNlbnRyYWwvc291cmNlL3NlY3VyaXR5L25zcy9saWIvc3NsL3NzbGluZm8uYyM3 MDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzYSUyZiUyZmR4ci5tb3ppbGxhLm9yZyUyZm1vemlsbGEtY2VudHJhbCUyZnNvdXJjZSUyZnNl Y3VyaXR5JTJmbnNzJTJmbGliJTJmc3NsJTJmc3NsaW5mby5jJTIzNzAmZGF0YT0wMSU3YzAxJTdj Rk9VUk5FVCU0MDA2NGQubWdkLm1pY3Jvc29mdC5jb20lN2M3Njk1MTljZDk2NzU0MWM4M2U1ODA4 ZDMzOTM3NTkyNiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT15 SFU4QTFQeFYzMDNERjNoeE1MWjFCRVFSYkdxUGUxZ2pkbnJqaHdXSGU4JTNkPg0KDQotRWtyDQoN Cg0KDQoNCg0KDQoNCg0KLUlsYXJpDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRM U0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNh JTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmdGxzJmRhdGE9MDElN2Mw MSU3Y0ZPVVJORVQlNDAwNjRkLm1nZC5taWNyb3NvZnQuY29tJTdjNzY5NTE5Y2Q5Njc1NDFjODNl NTgwOGQzMzkzNzU5MjYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEmc2Rh dGE9UFBGNEg3diUyZnVHaGxORTJyJTJiZ3RZWWh6dEpzQ3ZyOWZ0TU4lMmZQcnhldkJ4USUzZD4N Cg0K --_000_b0a287111e974361b4894f7f10d762f6AM3PR30MB049064dmgdmsft_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5BcyBwb2ludGVkIG91dCBieSBLYXJ0aGlr LCB3ZSBhcmUgbm90IHN0cm9uZ2x5IGFkdm9jYXRpbmcgdGhpcyBzaW1wbGlmaWNhdGlvbiwgYnV0 IHdlIGRvIG5vdCB0aGluayBpdCB3b3VsZCB3ZWFrZW4gdGhlIHNlY3VyaXR5IG9mDQogVExTLiBE ZXRhaWxzIGJlbG93LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi1D w6lkcmljLCB3aXRoIHRoZSBtaVRMUyB0ZWFtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+SW4gdGhlIGZvbGxvd2luZywgSSBvbmx5IGNvbnNpZGVyIHRoZSByZWNvcmQgbGF5ZXIg a2V5cywgd2hpY2ggYXJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbjsgSSBpZ25v cmUgYWxsIG90aGVyIGRlcml2ZWQga2V5DQogbWF0ZXJpYWxzLiBUaGUgVExTIGxheWVyZWQgZGVz aWduIGdvZXMgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+LSBUaGUgaGFuZHNoYWtlIHByb3ZpZGVzIGZyZXNoIGtleXMgdG8gdGhlIHJlY29y ZCBsYXllciAoZGVwZW5kaW5nIG9uIGl0cyBpbnRlcm5hbCBzdGF0ZSBtYWNoaW5lKSBhbmQga2Vl cHMgcnVubmluZzs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ LSBUaGUgcmVjb3JkIGxheWVyIHVzZXMgdGhlIGN1cnJlbnQga2V5cyBmb3IgZW5jcnlwdGluZyAq YWxsKiB0cmFmZmljLCBtaXhpbmcgaGFuZHNoYWtlIG1lc3NhZ2VzLCBhbGVydHMsIGFuZCBhcHBs aWNhdGlvbiBkYXRhIChvbmNlDQogZW5hYmxlZCkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5UaGVzZSBrZXlzIGFyZSB1c2VkIHNlcXVlbnRpYWxseSwgYW5kIG9ubHkg YnkgdGhlIHJlY29yZC1sYXllci4gVGhleSBhcmUgbm90IGRpcmVjdGx5IHVzZWQgd2l0aGluIHRo ZSBoYW5kc2hha2UgcHJvdG9jb2wgaXRzZWxmLCBvcg0KIGJ5IHRoZSBUTFMgYXBwbGljYXRpb24u IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tIFNpbmNlIHRo ZSBzZXF1ZW5jZSBvZiBrZXlzIGlzIG1lYW50IHRvIHByb3RlY3QgdGhlIHdob2xlIHN0cmVhbSBv ZiBUTFMgZnJhZ21lbnRzLCBvbmUgbmVlZHMgdG8gYXV0aGVudGljYXRlIGVhY2ggcG9pbnQgaW4g dGhlIHN0cmVhbQ0KIHdoZXJlIHRoZXJlIGlzIGEga2V5IGNoYW5nZSwgdG8gcHJldmVudCBhbnkg dHJhZmZpYyB0cnVuY2F0aW9uLiBBcyBkaXNjdXNzZWQgaW4gYW5vdGhlciB0aHJlYWQsIHdlIGJl bGlldmUgdGhpcyBpcyBjb3JyZWN0bHkgaGFuZGxlZCBpbiBkcmFmdCMxMSwgYnV0IGVhY2gga2V5 IGNoYW5nZSByZW1haW5zIGEgc291cmNlIG9mIGNvbXBsaWNhdGlvbiBbMV0uDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LSBUaGVyZSBhcmUgZXhjZWxsZW50 IHJlYXNvbnMgdG8gY2hhbmdlIGtleXMgYmV0d2VlbiAwLVJUVCBhbmQgMS1SVFQgKHN0cm9uZ2Vy IGtleSBtYXRlcmlhbHMsIGZvcndhcmQgc2VjcmVjeSkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LSBPdGhlcndpc2UsIHdoYXQgbWF0dGVycyBpcyB0aGUg cHJvdmVuYW5jZSBvZiB0aGUga2V5IChob3cgaXQgd2FzIGRlcml2ZWQsIHdoYXQgaWRlbnRpdGll cyBhcmUgYXNzb2NpYXRlZCB3aXRoIGl0KSBhbmQgdGhlcmUgaXMgbm8NCiBwb2ludCBjaGFuZ2lu ZyBrZXlzIHdpdGggdGhlIHNhbWUgcHJvdmVuYW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPlRoZSBzaXR1YXRpb24gaXMgcGFydGljdWxhcmx5IGNsZWFyIGluIDAt UlRUOiBpbiBkcmFmdCMxMSwgdGhlIGNsaWVudCBhbHdheXMgZGVyaXZlcyB0d28gcmVjb3JkLWxh eWVyIGtleXMgZnJvbSB0aGUgc2FtZSBtYXRlcmlhbHMsDQogYW5kIHVzZXMgZWFjaCBvZiB0aGVz ZSBrZXlzIGluIHR1cm4gdG8gZW5jcnlwdCBoYWxmIG9mIGl0cyAwLVJUVCBmbGlnaHQsIHdpdGgg YSBGaW5pc2hlZCBtZXNzYWdlIGluLWJldHdlZW4gdGhhdCBzaWduYWxzIHRoZSBrZXkgY2hhbmdl LiBUaGlzIGtleSBjaGFuZ2UgZG9lcyBub3QgZGVncmFkZSBzZWN1cml0eSwgYnV0IHNlZW1zIHVu bmVjZXNzYXJ5LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SW4gMS1S VFQsIHRoaXMgaXMgbGVzcyBvYnZpb3VzIGJlY2F1c2UsIGluIGRyYWZ0IzExLCB0aGUgaGFuZHNo YWtlIGtleXMgYW5kIGFwcGxpY2F0aW9uLWRhdGEga2V5cyBhcmUgbm90IGV4YWN0bHkgZGVyaXZl ZCBmcm9tIHRoZQ0KIHNhbWUgbWF0ZXJpYWxzLiBXZSBiZWxpZXZlIHRoaXMgc2hvdWxkIGJlIGZp eGVkIChzZWUgdGhlIOKAnHNpbXBsaWZpZWQga2V5IHNjaGVkdWxl4oCdIHRocmVhZCkuIFRoZW4g dGhlIHNhbWUgYXJndW1lbnQgYXBwbGllczogdGhlIGtleSBjaGFuZ2UgaXMgbm90IHRlcnJpYmxl LCBidXQgaXQgaXMgYW4gdW5uZWNlc3NhcnkgY29tcGxpY2F0aW9uLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5JIGRpc2FncmVlIHdpdGggSHVnbyB0aGF0IHVzaW5n IHRoZSBzYW1lIHJlY29yZC1sYXllciBrZXkgZm9yIGhhbmRzaGFrZSBhbmQgYXBwbGljYXRpb24g ZGF0YSB5aWVsZHMgYSBwcm9vZiBvZiBhIHdlYWtlciBndWFyYW50ZWUuDQogQXMgZmFyIGFzIEkg Y2FuIHRlbGwsIHRoaXMgaXMgYSB0ZWNobmljYWxpdHkgaW4gdGhlIGNyeXB0b2dyYXBoaWMgcHJv b2Ygb2YgdGhlIGhhbmRzaGFrZSwgYW5kIHdlIHN0aWxsIGdldCB0aGUgc2FtZSBzZWN1cml0eSBn dWFyYW50ZWVzIGZvciBUTFMgdXNlcnMgWzJdLiBJIGFsc28gbGlrZSBzaW1wbGUgcHJvb2ZzIG9m IGdlbmVyaWMgc2VjdXJpdHkgZm9yIHRoZSBoYW5kc2hha2UgY29yZSwgYnV0IEkgZG8gbm90IHNl ZSBob3cgdGhleSBjYW4gY292ZXINCiB0aGUgb3RoZXIgZmVhdHVyZXMgb2YgVExTIFtlLmcuIDMs IGFuZCBsYXRlIGhhbmRzaGFrZSBtZXNzYWdlc10gd2l0aCBvciB3aXRob3V0IHRoZSBzaW1wbGlm aWNhdGlvbi4gR2l2ZW4gdGhlIGNob2ljZSBiZXR3ZWVuIGEgc2ltcGxlciBwcm90b2NvbCB0aGF0 IGl0IGlzIGVhc2llciB0byBpbXBsZW1lbnQgY29ycmVjdGx5LCBhbmQgc2ltcGxlciBwcm9vZnMg Zm9yIGEgY29yZSwgSSB3b3VsZCByYXRoZXIgc2ltcGxpZnkgdGhlIG92ZXJhbGwgcHJvdG9jb2wN CiBhbmQgZG8gdGhlIGV4dHJhIHByb29mIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5PbmUgbWF5IGFyZ3VlIGFib3V0IHdoYXQgd291bGQgaGFwcGVuIGlmIHNv bWUgb2YgdGhlIHJlY29yZC1sYXllciBrZXlzIHdlcmUgbWlzLXVzZWQsIGFnYWluc3QgdGhlIFRM UyBzcGVjaWZpY2F0aW9uIChkZXNwaXRlIGl0cyBleHBvcnQNCiBtZWNoYW5pc20pIGFuZCBjb25j bHVkZSB0aGF0IHdlIG5lZWQgbW9yZSwgbm90IGxlc3Mga2V5IGNoYW5nZXMgWzNdLiBCdXQgSSB3 b3VsZCBub3QgY2FsbCBpdCDigJxhIGRpZmZlcmVudCBhcHBsaWNhdGlvbuKAnSBhbmQgSSBhbSBz dGlsbCB0ZW1wdGVkIHRvIHNpbXBsaWZ5IHRoZSBrZXkgc2NoZWR1bGUgZm9yIGl0cyBpbnRlbmRl ZCB1c2FnZSBpbiBUTFMuJm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5bMV0gQW4gYXR0YWNrZXIgbWF5LCBmb3IgaW5zdGFuY2UsIGRlbGV0ZSB0aGUgbGFzdCBmcmFn bWVudCBlbmNyeXB0ZWQgYmVmb3JlIHRoZSBrZXkgY2hhbmdlLiBTdWNoIGEgZGVsZXRpb24gd2ls bCBiZSBjYXVnaHQgYXQgdGhlDQogcHJvdG9jb2wgbGF5ZXIsIGUuZy4gYmVjYXVzZSB0aGUgbGFz dCBmcmFnbWVudCBpcyBub3QgYW4g4oCcZW5kX29mX2Vhcmx5X2RhdGHigJ0gYWxlcnQgb3IgYSBG aW5pc2hlZCBtZXNzYWdlLiBXaXRob3V0IHRoZSBrZXkgY2hhbmdlLCBhbnkgZGVsZXRpb24gd291 bGQgYmUgY2F1Z2h0IGltbWVkaWF0ZWx5LCBhcyB0aGUgbmV4dCBmcmFnbWVudCBkZWNyeXB0aW9u IGZhaWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+WzJdIHdlIGRv IG5vdCBoYXZlIGEgY29tcGxldGUgbW9kZWwgZm9yIFRMUyAxLjMgeWV0LCBidXQgd2UgZGV2ZWxv cGVkIGEgZGV0YWlsZWQgbW9kZWwgZm9yIFRMUyAxLjINCjxhIGhyZWY9Imh0dHA6Ly9lcHJpbnQu aWFjci5vcmcvMjAxNC8xODIiPmh0dHA6Ly9lcHJpbnQuaWFjci5vcmcvMjAxNC8xODI8L2E+IHNp bWlsYXJseSBjb3ZlcmluZyByZWNvcmQtbGF5ZXIga2V5IGNoYW5nZXMgKGZvciByZW5lZ290aWF0 aW9ucykgYW5kIHRoZSBmYWN0IHRoYXQgdGhvc2Uga2V5cyB3ZXJlIHVzZWQgdG8gcHJvdGVjdCB0 aGUgRmluaXNoZWQgbWVzc2FnZXMgKmJlZm9yZSoga2V5IGNvbmZpcm1hdGlvbiBhbmQgYXBwbGlj YXRpb24tZGF0YQ0KIHRyYWZmaWMuIFRoZSBtYWluIGRpZmZlcmVuY2Ugd2l0aCBjbGFzc2ljIG1v ZGVscyBmb3Iga2V5IGV4Y2hhbmdlLCB3aGVyZSB0aGUgcHJvdG9jb2wgcnVucyB0byBjb21wbGV0 aW9uIGFuZCByZXR1cm5zIOKAnHRoZeKAnSBhcHBsaWNhdGlvbiBrZXksIGlzIHRoYXQgaW4gb3Vy IG1vZGVsIHRoZSBob25lc3QgaW5zdGFuY2VzIHByb3ZpZGUga2V5cyBkdXJpbmcgdGhlIHByb3Rv Y29sIHJ1bi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4m bmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+WzNdIGFz IHJlY2VudGx5IGRpc2N1c3NlZCBhcyAwLjUtUlRULCB0aGUgc3BlYyBlbmFibGVzIHRoZSB1c2Ug b2YgMS1SVFQga2V5cyBiZWZvcmUgY29tcGxldGluZyB0aGUgaGFuZHNoYWtlLCB3aXRoIHdlYWtl ciBndWFyYW50ZWVzDQogb24gdGhlIGVuY3J5cHRlZCBhcHBsaWNhdGlvbiBkYXRhLiBIb3dldmVy LCBhbiBleHRyYSBrZXkgY2hhbmdlIHdvdWxkIHJlcXVpcmUgYWRkaXRpb25hbCBzaWduYWxsaW5n IG1lc3NhZ2VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1l PSJfTWFpbEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNw YW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5j ZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5T ZW50OjwvYj4gMTkgRmVicnVhcnkgMjAxNiAxNDoxNjxicj4NCjxiPlRvOjwvYj4gSWxhcmkgTGl1 c3ZhYXJhICZsdDtpbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBL YXJ0aGlrZXlhbiBCaGFyZ2F2YW4gJmx0O2thcnRoaWsuYmhhcmdhdmFuQGdtYWlsLmNvbSZndDs7 IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gUHJvcG9zYWw6IGRv bid0IGNoYW5nZSBrZXlzIGJldHdlZW4gaGFuZHNoYWtlIGFuZCBhcHBsaWNhdGlvbiBsYXllcjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgRmViIDE5LCAyMDE2IGF0IDM6NTggQU0s IElsYXJpIExpdXN2YWFyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsYXJpbGl1c3ZhYXJhQHdlbGhv LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IEZyaSwgRmViIDE5LCAyMDE2IGF0IDEwOjA0OjM4QU0gJiM0MzswMTAwLCBLYXJ0aGlrZXlhbiBC aGFyZ2F2YW4gd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBSZWdhcmRsZXNzIG9mIHdoZXRoZXIgd2Ug bWFrZSB0aGlzIGNoYW5nZSB0aG91Z2gsIEkgdGhpbmsgaXQgd291bGQgYmU8YnI+DQomZ3Q7IHVz ZWZ1bCBmb3IgdGhlIFRMUyAxLjMgUkZDIHRvIGNsZWFybHkgbGltaXQgdGhlIHNjb3BlIG9mIHZh cmlvdXMga2V5czxicj4NCiZndDsgZ2VuZXJhdGVkIGJ5IHRoZSBoYW5kc2hha2UuIER1cmluZyB0 aGUgY29ubmVjdGlvbiBsaWZldGltZSwgd2UgZ2VuZXJhdGU8YnI+DQomZ3Q7IGEgc2VyaWVzIG9m IHJlY29yZCBlbmNyeXB0aW9uIGtleXM6IGhhbmRzaGFrZSBhbmQgYXBwbGljYXRpb24ga2V5cyBm b3I8YnI+DQomZ3Q7IDAtUlRUIGFuZCAxLVJUVCwgYW5kIHRoZW4gYSBzZXF1ZW5jZSBvZiBrZXlz IGdlbmVyYXRlZCBkdXJpbmcgcmVrZXlpbmcuPGJyPg0KJmd0OyBOb25lIG9mIHRoZXNlIGtleXMg c2hvdWxkIGJlIHVzZWQgb3V0c2lkZSB0aGVpciBpbnRlbmRlZCB1c2UgY2FzZXMgaW4gYTxicj4N CiZndDsgc2luZ2xlIGNvbm5lY3Rpb24uJm5ic3A7IFRoZSBvbmx5IGNyb3NzLWNvbm5lY3Rpb24g c2VjcmV0IHNwZWNpZmllZCBpbiB0aGU8YnI+DQomZ3Q7IHByb3RvY29sIGlzIHRoZSByZXN1bXB0 aW9uIG1hc3RlciBzZWNyZXQsIGFuZCBpZiBhcHBsaWNhdGlvbnMgd2FudCBhPGJyPg0KJmd0OyBr ZXkgZnJvbSBUTFMgMS4zLCB0aGV5IG11c3Qgb25seSB1c2UgdGhlIGV4cG9ydGVyIG1hc3RlciBz ZWNyZXQuIEFsbDxicj4NCiZndDsgb3RoZXIga2V5cyBhcmUgaW50ZXJuYWwgdG8gVExTLjxicj4N Cjxicj4NCkkgdGhpbmsgVExTIDEuMyBSRkMgc2hvdWxkIHNwZWNpZnkgd2hhdCB0aGUgcHJvdG9j b2wgbG9va3MgbGlrZSBhbmQgaG93PGJyPg0KaXQgY2FuIGJlIHVzZWQgZnJvbSBhcHBsaWNhdGlv biBwZXJzcGVjdGl2ZS4gVGhpcyBpbmNsdWRlcyBzcGVjaWZ5aW5nPGJyPg0Kd2hhdCBrZXlzIGNh biBiZSBleHBvcnRlZCAoYW1vbmcgbWFueSBvdGhlciB0aGluZ3MsIGxpa2UgaG93PGJyPg0KYXV0 aGVudGljYXRpb24gY2FuIGJlIHBlcmZvcm1lZCkuPGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IGV4 cG9ydGluZyB0aGUgbWFpbiBlbmNyeXB0aW9uIGtleXMgb3Igc2VjcmV0cyB0aG9zZSBhcmU8YnI+ DQpkZXJpdmVkIGZyb20gZm9yIGFueSBwdXJwb3NlIGlzIGEgcm90dGVuIGlkZWEuIElmIHlvdSBu ZWVkIGtleWluZyBvcjxicj4NCmF1dGhlbnRpY2F0aW9uIG1hdGVyaWFsLCB1c2UgVExTIEVYUE9S VEVSICh0bHMtdW5pcXVlIGlzIGRlcHJlY2F0ZWQpPGJyPg0Kd2l0aCByZXF1aXJlbWVudCB0byB1 c2UgRU1TIG9uIHByaW9yIHZlcnNpb25zWzFdLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyB0aGUgaW50ZW50LiBJIHRo aW5rIHdlIHdvdWxkIGJlIHdlbGwtc2VydmVkIHRvIHN0YXRlIHRoaXMuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlbiBvbmUg bWlnaHQgbmVlZCB0byBleHBvcnQgUk1TLiBJIHRoaW5rIGl0IHNob3VsZCBiZSBleHBvcnRlZCBh czxicj4NCmJsb2IgdGhhdCBhbHNvIGNvbnRhaW5zIG90aGVyIGFzc29jaWF0ZWQgaW5mb3JtYXRp b24gKGUuZyBjaXBoZXJzdWl0ZXMpLjxicj4NCkFuZCBwb3NzaWJseSBhbHNvIGVuY3J5cHRlZCwg dXNpbmcgc29tZSBNUkFFIGFsZ29yaXRobS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpbMV0gQ29t cGF0aWJsaXR5IGhhY2s6IE9uZSBtaWdodCBjb25zaWRlciBFTVMgYWx3YXlzIG5lZ290aWF0ZWQg d2hlbjxicj4NClRMUyAxLjMgaXMgbmVnb3RpYXRlZC4gVGhpcyBjb3VsZCBwcnZlbnQgYXBwbGlj YXRpb25zIHRoYXQgZG8ga25vdzxicj4NCmFib3V0IEVNUyBidXQgbm90IFRMUyAxLjMgZnJvbSBi cmVha2luZyB3aGVuIHVwZ3JhZGluZyB0byBUTFMgMS4zLjxicj4NCjxicj4NClRoYXQgaXMsIGlm IGFwcGxpY2F0aW9uIGFza3MgYWJvdXQgVExTIDEuMyAoU2VydmVyVmVyc2lvbiAzLjQpPGJyPg0K Y29ubmVjdGlvbiAmcXVvdDtpcyBFTVMgZW5hYmxlZD8mcXVvdDsgdGhlIGFuc3dlciB3aWxsIGJl IGFsd2F5cyAmcXVvdDt5ZXMmcXVvdDs8YnI+DQooc2luY2UgdGhlIHBvaW50IG9mIHRoYXQgY2hl Y2sgaXMgdG8gZXhjbHVkZSBUSFMgYXR0YWNrcywgYW5kPGJyPg0KVExTIDEuMyBhbHJlYWR5IGV4 Y2x1ZGVzIHRob3NlIG9uIGJhc2VsaW5lKS48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdvb2Qgc3VnZ2VzdGlvbi4gVGhpcyBpbiBm YWN0IGlzIHdoYXQgTlNTIGN1cnJlbnRseSBkb2VzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZkeHIubW96aWxsYS5v cmclMmZtb3ppbGxhLWNlbnRyYWwlMmZzb3VyY2UlMmZzZWN1cml0eSUyZm5zcyUyZmxpYiUyZnNz bCUyZnNzbGluZm8uYyUyMzcwJmFtcDtkYXRhPTAxJTdjMDElN2NGT1VSTkVUJTQwMDY0ZC5tZ2Qu bWljcm9zb2Z0LmNvbSU3Yzc2OTUxOWNkOTY3NTQxYzgzZTU4MDhkMzM5Mzc1OTI2JTdjNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT15SFU4QTFQeFYzMDNERjNo eE1MWjFCRVFSYkdxUGUxZ2pkbnJqaHdXSGU4JTNkIj5odHRwczovL2R4ci5tb3ppbGxhLm9yZy9t b3ppbGxhLWNlbnRyYWwvc291cmNlL3NlY3VyaXR5L25zcy9saWIvc3NsL3NzbGluZm8uYyM3MDwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ LUVrcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxi cj4NCjxicj4NCjxicj4NCjxicj4NCi1JbGFyaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEg aHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJmdGxzJmFtcDtkYXRh PTAxJTdjMDElN2NGT1VSTkVUJTQwMDY0ZC5tZ2QubWljcm9zb2Z0LmNvbSU3Yzc2OTUxOWNkOTY3 NTQxYzgzZTU4MDhkMzM5Mzc1OTI2JTdjNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDcl N2MxJmFtcDtzZGF0YT1QUEY0SDd2JTJmdUdobE5FMnIlMmJndFlZaHp0SnNDdnI5ZnRNTiUyZlBy eGV2QnhRJTNkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_b0a287111e974361b4894f7f10d762f6AM3PR30MB049064dmgdmsft_-- From nobody Fri Feb 19 10:07:39 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC1351B3337 for ; Fri, 19 Feb 2016 10:07:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.994 X-Spam-Level: X-Spam-Status: No, score=0.994 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_22=0.6, MANGLED_HRDCOR=2.3, RP_MATCHES_RCVD=-0.006] autolearn=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 RRWVsLEPZL3I for ; Fri, 19 Feb 2016 10:07:35 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 64DC81B2CAE for ; Fri, 19 Feb 2016 10:07:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 967552AD6; Fri, 19 Feb 2016 20:07:33 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id lfGaXsr1i8_a; Fri, 19 Feb 2016 20:07:33 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 1EC37C4; Fri, 19 Feb 2016 20:07:33 +0200 (EET) Date: Fri, 19 Feb 2016 20:07:29 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160219180729.GA14778@LK-Perkele-V2.elisa-laajakaista.fi> References: <76B62127-231A-4F42-BBB6-E1F27BB6A6F3@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Proposal: Simplified Key Schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 18:07:38 -0000 On Fri, Feb 19, 2016 at 07:14:44AM -0700, Eric Rescorla wrote: > On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan < > karthik.bhargavan@gmail.com> wrote: > > > > > Note that this is (almost) exactly the original KDF scheme of OPTLS as I > > presented in Dallas > > > > > > Indeed, Ekr’s proposed scheme looks much like you original diagram. > > > > I would like to clarify that this isn't *my* scheme, though I think it's a > good > one. It came out of a long discussion with the people listed in my original > message and probably is most closely derived from something Karthik > drew. Sorry if I gave an impression to the contrary! > > In any case, I'm glad to see that it's close to Hugo's original diagram, > since that's a good indication that we're on the right track! > > > Anyway, from here you can see that the last HKDF in your scheme (with 0 > > salt) > > is not needed. You can derive the RMS, EMS keys directly from the second > > HKDF > > (as siblings of 1-RTT Traffic Keys). Am I missing something? > > > > > > The purpose of the third HKDF is to bind the handshake context (the full > > transcript) into > > the resumption and exporter keys. It adds no new key material. > > > > Yes, that was my understanding as well. I see that Ilari suggested that > this might > not be necessary (presumably as a consequence of having the full shares > included in the stage 2 transcript rather than just the nonces as in TLS > 1.2. > The imperative here is to avoid creating an attack like triple handshake or > the Cremers et al. attack on the PSK-resumption. In any case, having the > EMS and RMS keys derived at the end also helps enforce the logic that you > should never be exporting/resuming until you have actually completed the > handshake. To be clear, RMS needs to include some data in "flight 3", so the most straightforward is to take the hash to be ClientHello1...ClientFinished. EMS needs to be secret and nonce versus ES and SS (otherwise you can get Triple-Handshake-style attacks). And one can compute such values immediately after ServerHello in main modes. However, given that some more "exotic" modes might have attacks all the way into ClientFinished, it would be good idea to take the EMS hash to ClientFinished too. Taking EMS to ClientFinished would prevent server from computing authenticators immediately after getting into application data, but usually those kinds of authenticators are used client-first so it won't matter much. And authentication TBS need to be nonce versus ES and SS. TBS failing to be nonce with SS is what led to Cremers attack. Also, where things can also get scary is server authentication. Whereas with client auth, the TBS should become nonce versus SS via Server- Finished, there is nothing corresponding for server authentication (this is not problem in GDHE-CERT w/o Config because SS=ES, and TBS is nonce versus ES). There are some subtle caveats tho: In practicular, the HKDF salt needs to be constant-length or one can obtain trivial collisions in HKDF. So one can't feed raw SS as salt (but must extract it first). > What I do miss in this scheme is the derivation of the Finished keys. I hope > > you do not intend to use the application key for this! > > > > > > Indeed those are missing in the picture, but I believe Ekr means to derive > > separate > > finished keys alongside the 1-RTT Traffic keys (right after the > > ServerHello) > > > > Affirmative. Error in my diagram. There's question about if to use ES+SS or just SS. One of those might make proofs of some kind easier, dunno. > > > > That "optimization" > > is orthogonal to this KDF simplification and hopefully will be reverted > > (*). > > > > (*) You may say I'm a dreamer, But I may not be the only one :-) > > > Nothing to be reverted yet, it's just a proposal. If it's a bad idea (and > being prohibitively > hard to analyze is one reason it might be) then we shouldn't adopt it. I don't find it prohibitively hard (or even hard) to analyze unless you get thigns like configurations or future modes involved. (And I think one would get similar problems before the simplication too). -Ilari From nobody Fri Feb 19 10:16:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F361B2CF5 for ; Fri, 19 Feb 2016 10:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 j4QV2rsKmBUg for ; Fri, 19 Feb 2016 10:16:51 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031281B2B1C for ; Fri, 19 Feb 2016 10:16:51 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id z13so38273264ykd.0 for ; Fri, 19 Feb 2016 10:16:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=F1bsW50iADdECYM2APU7WLTVTiEAzrS/9JJNCe9a4NA=; b=uXIQZZDrHpZUmFM7jAN+pn3d6KU133P++06h1EkWfvKFhvvBEAkYuHXiFl4ZMfxGKj jrbwEXAYOotqhaA2s4/dr9W51Qcrx571cpWc9NlZR/SQ82z9Sbo2UaHxMo04tjphNJ6o 2/MBYZMhRMCXf2stJW9PUXuP2/jvKQsuducf49cagNlvuAnc9h5cX5HJMC/lNrbkuf/j OBmvr8FCyPv0XOGW14TZ7+Ja2rHXt+MZR/Dd8eyG3CzlDVSf+jFVBOShVK5VHAPmG2PB bEE0wlXacTUjLIfHQMGCq/lUOSahScUExpICDJir44Z+LMiIi0Nq+0oswGKQMUGZN7+w mWtw== 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:content-type; bh=F1bsW50iADdECYM2APU7WLTVTiEAzrS/9JJNCe9a4NA=; b=iPs9V63mNg4ikcxyDgPoYsD3GEBKkljEAIhr3xK6eDln4EEIgfsSZR0nwMDdtRO//L 37fCeksh5Divf9go6BmeS09qdYgX7CILoh0ALNiv1Zzz2z0wm/UsA5aWQ5Ks/1j5Q74q Da/NtzKd2872rhUUnzSoLvhJmaw+gs20f6gDVfRfZ1Vu2OvS+TimicDNkhT81Y7cusI6 pYogilJfBDY4jx/y8xtwH31lsibONsm8nuvDrH2M686ZHM6brJyBISWz6hIII4+rGY0/ iXkw+5bIjFotJDgtj9358NsYWz4vbQfkvjj8WoxPmsaSZwU/AmenrXV3f5o1pLeRw9Is R0NQ== X-Gm-Message-State: AG10YOR6T5YWWJ4WJ2rlY2dHBrSGiBxT8hraoMdjBf1Ei8G9xcJ2fhbT4qSukoBCRfCm5+pGEiKHDDldBPdeHw== X-Received: by 10.37.231.146 with SMTP id e140mr7956317ybh.146.1455905810362; Fri, 19 Feb 2016 10:16:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 19 Feb 2016 10:16:10 -0800 (PST) In-Reply-To: References: <75b91c8af44e4520a5433d48c97582b0@ustx2ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Fri, 19 Feb 2016 11:16:10 -0700 Message-ID: To: "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c0b12e8a76c1f052c237cd0 Archived-At: Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 18:16:52 -0000 --94eb2c0b12e8a76c1f052c237cd0 Content-Type: text/plain; charset=UTF-8 + TLS WG On Fri, Feb 19, 2016 at 8:46 AM, Eric Rescorla wrote: > > On Fri, Feb 19, 2016 at 8:01 AM, Salz, Rich wrote: > >> I greatly prefer one way to do things. (Python not perl, if you will :) >> >> On the other hand, there is an elegance about using a single >> well-understood mechanism even if it has operational burdens. We all know >> how to secure PSK material, though, right? :) But what dose this do about >> encrypted-SNI? >> > > Funny you should mention that. There's actually a very elegant way to do > encrypted > SNI here (due to Cedric Fourney). The basic idea is that you initially > contact the hidden > server and do a TLS handshake establishing a ticket. That ticket actually > has two parts: > > - The ordinary ticket > - The identity of the hidden cipher enciphered for the gateway > > Then when you connect to the gateway, you do an apparent PSK+(ECDHE) > handshake with it and provide the ticket. It unwraps the identity of the > hidden > server and then forwards the ClientHello to the hidden server for > processing > and the rest of the handshake just completes as normal, but with the hidden > server [0]. And because each handshake provides a new ticket, this > is unlinkable. > > The major drawback of this design is that the first ticket establishment > requires > contacting the hidden server, but you can either do this directly (as we > have > been assuming) or just tunnel through the gateway the first time with > TLS-in-TLS. > > -Ekr > > [0] I originally thought this might need a change to the ticket signaling > mechanism, but I'm less sure that that's true. In any case, that should > be minor. > > >> -- >> Senior Architect, Akamai Technologies >> IM: richsalz@jabber.at Twitter: RichSalz >> >> >> > --94eb2c0b12e8a76c1f052c237cd0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+ TLS WG

On Fri, Feb 19, 2016 at 8:46 AM, Eric Rescorla <ekr@rtfm.com&= gt; wrote:

On Fri= , Feb 19, 2016 at 8:01 AM, Salz, Rich <rsalz@akamai.com> wrot= e:
I greatly prefer one way to do things.= =C2=A0 (Python not perl, if you will :)

On the other hand, there is an elegance about using a single well-understoo= d mechanism even if it has operational burdens.=C2=A0 We all know how to se= cure PSK material, though, right? :)=C2=A0 But what dose this do about encr= ypted-SNI?

Funny you should ment= ion that. There's actually a very elegant way to do encrypted
SNI here (due to Cedric Fourney). The basic idea is that you initially con= tact the hidden
server and do a TLS handshake establishing a tick= et. That ticket actually has two parts:

- The ordi= nary ticket
- The identity of the hidden cipher enciphered for th= e gateway

Then when you connect to the gateway, yo= u do an apparent PSK+(ECDHE)
handshake with it and provide the ti= cket. It unwraps the identity of the hidden
server and then forwa= rds the ClientHello to the hidden server for processing
and the r= est of the handshake just completes as normal, but with the hidden
server [0]. And because each handshake provides a new ticket, this
<= div>is unlinkable.

The major drawback of this desi= gn is that the first ticket establishment requires
contacting the= hidden server, but you can either do this directly (as we have
b= een assuming) or just tunnel through the gateway the first time with
<= div>TLS-in-TLS.

-Ekr
=C2=A0
[0= ] I originally thought this might need a change to the ticket signaling
mechanism, but I'm less sure that that's true. In any case, = that should
be minor.


--
Senior Architect, Akamai Technologies
IM: richsalz@jabber= .at Twitter: RichSalz




--94eb2c0b12e8a76c1f052c237cd0-- From nobody Fri Feb 19 10:25:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A981B3340 for ; Fri, 19 Feb 2016 10:25: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M-4UZTmt1iGY for ; Fri, 19 Feb 2016 10:25:31 -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 EBC4F1B33E2 for ; Fri, 19 Feb 2016 10:25:29 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id u200so74269665ywf.0 for ; Fri, 19 Feb 2016 10:25:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=gRutZzRN3QvqE4GmDQQ7Xh560GCQS04+Ovt2G/mvv3c=; b=RbZAFMLsK7CHQMMETDgvb7JtK3p1Z3bzd/XgjWXfTul2PLANRoRj4K+Dbf8Ri0DrZ/ p/ZJtDMPshi1BDTWNRzQO2hJr4bGuGek/uE79Yuqi0DJVnhyM9hdaVT9HJ1XHdthuzEJ 2eNhvJgwub3g9jGiojlB4bE9D6h4WMrajpgYZPr/xRiTNzZXLfabThYWE8+foMa/SNb5 c/Qf4QsupKqPU6ye4vqlldTWRyunV3GFciu/2CLNmwrpWKMXDL5C5qwu6nij1lYDeKhU uGzlbe4pclEd9qkahBTunp+Ccp0Q53Qn1jIx2YNE6xC1m/nlbKFe9ypZro9DcojkQN6H XE7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=gRutZzRN3QvqE4GmDQQ7Xh560GCQS04+Ovt2G/mvv3c=; b=HR+pz1y5emE25SpiQOH7EK+ngT9DplGBorrVBo1nKtbLBxBbxyG0AXHp5MT53Dqgwn INBUJI5JAQpu2l0BrxzvOMNsI7XWNjcGbqPxo9IeuqX5+atpUY7aOYuvQdBZnrE+SO/j MyMNZzdRjZiVfHbaf2C5LVdGcACwBvJ9Lq12OdqqWI71iv+bVazlqIYAJP5rO1xVQ+y3 csyWjQii5SK4Q24PonRP5/iDvk5mnMFpM4Q6h1tv8NMvYCE0k3O/v7S5CJ++NigxrLk0 js7HaZA4HmpMHfjCCD35Aczu6Zz9xmR9kkywOgkJAtFwyH3EpeRuwB+zpVB1xA/bZ9fx I3BA== X-Gm-Message-State: AG10YORoicsIq12zgWW95yVP6VKNdrDepma0RKsMw4w5jk3wjv0tkqvKUw7Kd5DLRytaHxyKryF9WfmzBQzJHQ== MIME-Version: 1.0 X-Received: by 10.13.226.86 with SMTP id l83mr8932629ywe.239.1455906329328; Fri, 19 Feb 2016 10:25:29 -0800 (PST) Received: by 10.13.216.138 with HTTP; Fri, 19 Feb 2016 10:25:29 -0800 (PST) Date: Fri, 19 Feb 2016 10:25:29 -0800 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] PSK and client verify X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 18:25:33 -0000 Cf 6.3.4.2. Certificate Verify with 6.3.5.1. New Session Ticket Message and we see that client certificate verification is allowed for some PSK exchanges and not others, and that the PSK exchanges used in resumption are ones where it is allowed. (Maybe I am reading that wrong) Right now this feels footgunny to me: you have to track where the PSK came from to decide if client auth is allowed. I'd like to see an explicit separation by indicating where the PSK came from in the ciphersuite, and then implementations reject authentication with one of them. This way someone who wants to do the wrong thing is at least forced through enough contortions they will notice, rather than seeing two features that seem to work together but don't. TRON is in 2 days, and I'm concerned that the degree of analysis of TLS 1.3 is far below where I would like to see with the timelines some people are pushing for. I think it's clear that TLS 1.3 implementations will never be as secure and as simple as QUIC or CurveCP. At the same time we've diverged from TLS 1.2 enough that implementations will be significantly complicated when supporting both, the reason given for not massively simplifying the protocol in the first place. Sincerely, Watson From nobody Fri Feb 19 11:00:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4F441B329D for ; Fri, 19 Feb 2016 11:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 a8C-adqrV6SW for ; Fri, 19 Feb 2016 11:00:11 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F3FC1B2C63 for ; Fri, 19 Feb 2016 11:00:11 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id g127so74978875ywf.2 for ; Fri, 19 Feb 2016 11:00:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ny0ne0KSSzzxQYEw/m721N/KVr3YtIb8dSPYU7+ivYU=; b=ao+0ylzL9gLKr/39bRRHyMykEIK1zEDib8a/L+BfidzT4O93VLIEgh3MdXWv4dPiTT MJI0wW5dMAgMaAOnkFVdNxi56B1P6560EJVXN46gwm9ww1KioxVvTNOIk1k/oxR5QbDB Ir95KXANXjCIzUanTLJAhrGvmZZvkSXe+qis1RMqv57jAEh4r28HFZZrhbzX/JRNjI/J WO44RdOjjICzA9t0lIgP0Rpe2BrTVXWjySvvnjXEK/MKEzRfQCypStM2Y6ovh07XI5Xb bKpkDxKX4EhnVjAsnVi6ltG7zZ18PqjCSQfz6SQRhhnX6A4zAjfvDBNgY02yB+DOt3qS Hlkw== 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-type; bh=ny0ne0KSSzzxQYEw/m721N/KVr3YtIb8dSPYU7+ivYU=; b=FLbuFwGd2xPUexYqBFNL5WFPJU7Fpt9SQmeEW3ETyN3jGEVMeoTWG7iBW/iDGyw2Sz feNF3jqDVGFs89gzdyz8Z1/LChNKPWwJR4po4gtSCN2J8R9W84fluqtIF8sAsi3OldjV Gabf/JB2knwMWLMnVuSU2deQXQS0gJLJ6nh2gqQRm90uyY+eT8Bf5ewNdvYoMjycTYZG xHBjpTbb43o+lr5EqsBwPy2LfUe1ynj8YkuorLG47cRb6PFuzHuK3aDjZy9502ZwZRZt ryg6LlmY4HpQ4YXMYW1HlBC0ZTor6/PWe32Y87eRf3LfX5JRkweRuEXCsJXp9xta5QOX arWg== X-Gm-Message-State: AG10YORagO0DX4DRcHNgJ3LNnpQ2F/VELiFfcfN1D5bVZTwXN00sV3xSr3l2napE8VwTwA5zMXYyPQ3VryswPw== X-Received: by 10.13.218.198 with SMTP id c189mr8991456ywe.165.1455908410789; Fri, 19 Feb 2016 11:00:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 19 Feb 2016 10:59:31 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 19 Feb 2016 11:59:31 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=94eb2c08192aa6c588052c24174b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] PSK and client verify X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 19:00:13 -0000 --94eb2c08192aa6c588052c24174b Content-Type: text/plain; charset=UTF-8 On Fri, Feb 19, 2016 at 11:25 AM, Watson Ladd wrote: > Cf 6.3.4.2. Certificate Verify with 6.3.5.1. New Session Ticket Message > > and we see that client certificate verification is allowed for some > PSK exchanges and not others, and that the PSK exchanges used in > resumption are ones where it is allowed. (Maybe I am reading that > wrong) Right now this feels footgunny to me: you have to track where > the PSK came from to decide if client auth is allowed. > I suspect we actually can relax this constraint and instead have a clear warning about the impact of sharing PSKs. -Ekr I'd like to see an explicit separation by indicating where the PSK > came from in the ciphersuite, and then implementations reject > authentication with one of them. This way someone who wants to do the > wrong thing is at least forced through enough contortions they will > notice, rather than seeing two features that seem to work together but > don't. > > TRON is in 2 days, and I'm concerned that the degree of analysis of > TLS 1.3 is far below where I would like to see with the timelines some > people are pushing for. I think it's clear that TLS 1.3 > implementations will never be as secure and as simple as QUIC or > CurveCP. At the same time we've diverged from TLS 1.2 enough that > implementations will be significantly complicated when supporting > both, the reason given for not massively simplifying the protocol in > the first place. > > Sincerely, > Watson > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c08192aa6c588052c24174b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 19, 2016 at 11:25 AM, Watson Ladd <watsonbladd@gmail.c= om> wrote:
Cf 6.3.4.2. Cert= ificate Verify with 6.3.5.1.=C2=A0 New Session Ticket Message

and we see that client certificate verification is allowed for some
PSK exchanges and not others, and that the PSK exchanges used in
resumption are ones where it is allowed. (Maybe I am reading that
wrong) Right now this feels footgunny to me: you have to track where
the PSK came from to decide if client auth is allowed.

I suspect we actually can relax this constraint and instead= have
a clear warning about the impact of sharing PSKs.

-Ekr


I'd like to see an explicit separation by indicating where the PSK
came from in the ciphersuite, and then implementations reject
authentication with one of them. This way someone who wants to do the
wrong thing is at least forced through enough contortions they will
notice, rather than seeing two features that seem to work together but
don't.

TRON is in 2 days, and I'm concerned that the degree of analysis of
TLS 1.3 is far below where I would like to see with the timelines some
people are pushing for. I think it's clear that TLS 1.3
implementations will never be as secure and as simple as QUIC or
CurveCP. At the same time we've diverged from TLS 1.2 enough that
implementations will be significantly complicated when supporting
both, the reason given for not massively simplifying the protocol in
the first place.

Sincerely,
Watson

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

--94eb2c08192aa6c588052c24174b-- From nobody Fri Feb 19 11:35:21 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C503B1B32C5 for ; Fri, 19 Feb 2016 11:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.523 X-Spam-Level: X-Spam-Status: No, score=0.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_22=0.6, J_CHICKENPOX_61=0.6, SPF_PASS=-0.001] autolearn=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 mk4d_3i78uUW for ; Fri, 19 Feb 2016 11:35:15 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 614251B31BA for ; Fri, 19 Feb 2016 11:35:14 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id m1so61089911lfg.0 for ; Fri, 19 Feb 2016 11:35:14 -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:content-type; bh=XJmhJ6av6agNjR7nDCnUIjMbueupra2jcpjlvysp5Y4=; b=LGXF6iY2P0Wc4sq03CwWTggktx064bZM0ZKkljyv1/cdXQNhFXj4hY1jYGXjaaFYLS grV9muaPYL5+OpwLZznqOcMUilTAPy3HmKG+HV8ujsEiweasXVZTs+/oXE09Pxgt16EN s1eoydjC0qCRFQF4KrQTfN3MMdPHlxyyG6KHeWBsG2ld8GTyS/37q7S0mIpMQ2zW2s/7 K6TKH5f+XYNxb9/86IB93B3SBp+YCgvTwUOpAFzMs5UO1XsCl2uNNGHweqHvQN4dR/gt V9Aa3SovPSv19j6IyJjNflR7+4xyu+yhUDeAxMZyhew1ReXO/kMxpoi+LyrVPizzEY/N 8fXw== 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:content-type; bh=XJmhJ6av6agNjR7nDCnUIjMbueupra2jcpjlvysp5Y4=; b=Djz0pkr6llLAMbGVsntlCFwTtPm7SWPD+PAXIUEuHVaRhkuNJjRt9ZmNTYX2ae/Vct FLHK3YqZm7EpXbLeVnt3jGM+TEPcZVm7v8ebw54Sf93s9B0TIyTAJo49D8h1Bxq0Um/r uUdCTSQ0kb8/u7qrmYUrBB4zzlavr4GiV/ICpfdtjazTZKisG5jvjTdaApMudlP4u++J vBL9OuP/SuNMhDrc9VK572opyMkkIOI9TWKa8IY4eGr50nm5Cq9FEgkIIiD2y6RtkWeq AuEsAJ7EFC+ZbtwQfZc5nUVugxprC66x5G5Ptt2mc2X/KrcspAqdxsKwdAQE7ArR6HCN NlPg== X-Gm-Message-State: AG10YOSEm727hcXIHLqLRginoGvgcuAMWGS4TsXlbKYx/zioNjEaqekgQMFPxJ4vOAPpUCgqslUwY0bXkoxz8g== X-Received: by 10.25.21.90 with SMTP id l87mr5969472lfi.64.1455910512624; Fri, 19 Feb 2016 11:35:12 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Fri, 19 Feb 2016 11:34:43 -0800 (PST) In-Reply-To: References: <76B62127-231A-4F42-BBB6-E1F27BB6A6F3@gmail.com> From: Hugo Krawczyk Date: Fri, 19 Feb 2016 14:34:43 -0500 X-Google-Sender-Auth: bCIlEbTdEGPM2GbRdaOg3zu44h4 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113d9b54ee0a1b052c2494c5 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] Proposal: Simplified Key Schedule X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 19:35:18 -0000 --001a113d9b54ee0a1b052c2494c5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Couple of comments below. On Fri, Feb 19, 2016 at 9:14 AM, Eric Rescorla wrote: > > > On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan < > karthik.bhargavan@gmail.com> wrote: > >> >> Note that this is (almost) exactly the original KDF scheme of OPTLS as I >> presented in Dallas >> >> >> Indeed, Ekr=E2=80=99s proposed scheme looks much like you original diagr= am. >> > > I would like to clarify that this isn't *my* scheme, though I think it's = a > good > one. It came out of a long discussion with the people listed in my origin= al > message and probably is most closely derived from something Karthik > drew. Sorry if I gave an impression to the contrary! > > In any case, I'm glad to see that it's close to Hugo's original diagram, > since that's a good indication that we're on the right track! > > > Anyway, from here you can see that the last HKDF in your scheme (with 0 >> salt) >> is not needed. You can derive the RMS, EMS keys directly from the second >> HKDF >> (as siblings of 1-RTT Traffic Keys). Am I missing something? >> >> >> The purpose of the third HKDF is to bind the handshake context (the full >> transcript) into >> the resumption and exporter keys. It adds no new key material. >> > =E2=80=8BI am still confused about this. Call K the key output by the Extra= ct part of the second HKDF=E2=80=8B =E2=80=8B. You derive 1-RTT Traffic Keys as an output from Expand(K, whatever). Why can't you use the same K to derive RMS and EMS? Namely, compute RMS=3DExpand(K, label=3D"RMS Derivation", ClientHello....ClientFinished)=E2=80=8B. =E2=80=8BSimilarly for EMS. This would include all the information you wanted in the derivation of each key, and it is still a valid HKDF computation (namely, it goes through extract and expand). Am I missing something? > Yes, that was my understanding as well. I see that Ilari suggested that > this might > not be necessary (presumably as a consequence of having the full shares > included in the stage 2 transcript rather than just the nonces as in TLS > 1.2. > The imperative here is to avoid creating an attack like triple handshake = or > the Cremers et al. attack on the PSK-resumption. In any case, having the > EMS and RMS keys derived at the end also helps enforce the logic that you > should never be exporting/resuming until you have actually completed the > handshake. > > What I do miss in this scheme is the derivation of the Finished keys. I >> hope >> you do not intend to use the application key for this! >> >> >> Indeed those are missing in the picture, but I believe Ekr means to >> derive separate >> finished keys alongside the 1-RTT Traffic keys (right after the >> ServerHello) >> > > Affirmative. Error in my diagram. > > I also want to stress, for the record, that this simplification has >> nothing to >> do with using the application keys for handshake protection. >> >> >> I agree, this key schedule simplification seems orthogonal. >> > > Yes, but... In the current 1-RTT mode, there is a derivation stage > that does not appear on this diagram, one that includes the transcript up > to the > server CertificateVerify and is used to derive the application traffic > keys. So, > if part of the intent of this diagram is to reduce the number of points a= t > which > we derive, we will need to derive the application traffic keys at stage 2 > even if they are separate from the handshake traffic keys. I believe this > something you proposed, but I just want to clarify that this diagram woul= d > entail > a change in the timing of key derivation, even if not the number of keys. > > > >> For what it=E2=80=99s worth, I am building a symbolic model of this new = key >> schedule and will >> report my analysis results at TRON. It=E2=80=99s not a cryptographic pro= of, but >> it should shake >> out early logical bugs in the design, if any. >> >> Best, >> Karthik >> >> >> That "optimization" >> is orthogonal to this KDF simplification and hopefully will be reverted >> (*). >> >> (*) You may say I'm a dreamer, But I may not be the only one :-) >> >> Nothing to be reverted yet, it's just a proposal. If it's a bad idea (an= d > being prohibitively > hard to analyze is one reason it might be) then we shouldn't adopt it. > =E2=80=8BIt complicates analysis, breaks generality and modularity, weakens= the security guarantee, but d efinitely not " =E2=80=8B prohibitively =E2=80=8B =E2=80=8B hard to analyze=E2=80=8B". =E2=80=8BHugo =E2=80=8B > > Hugo >> >> PS: I have a disagreement with you in terms of the protocol now being >> "signature based". Yes there are signatures in the protocol but not all >> modes >> use them and they are not always needed. In my eyes the logic of the >> protocol >> is best seen as DH-based with authentication occurring through the serve= r >> Finished MAC (with a key derived from SS which can take the values of >> g^xs, >> g^xy or PSK). That is common to *all* modes, including 0-RTT and PSK >> which do >> not build on signatures. This is how the protocol was built originally a= nd >> that structure remains in spite of the added signatures. >> >> > Sorry about the misleading terminology. I just meant that it presently ha= s > signatures. > I'll try to be more precise in future. > > -Ekr > > > On Thu, Feb 18, 2016 at 4:05 PM, Eric Rescorla wrote: >> >>> Hi folks, >>> >>> TL;DR. >>> Let's simplify the key schedule. >>> >>> >>> DETAILS >>> This is the second in a series of proposed simplifications to TLS 1.3 >>> based on implementation experience and analysis once the protocol >>> starts to harden. The following suggestion comes out of conversations >>> with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud, >>> Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanella and >>> others. >>> >>> The current key schedule is elegant but it is actually more than we >>> need in that it allows SS to be known either before or after ES. If we >>> assume (as is always true in the current TLS 1.3 modes) that SS is >>> known before or at the same time as ES, then we can design a simpler >>> scheme which looks more like a ladder. Something like: >>> >>> 0 >>> | >>> SS -> HKDF [ClientHello + Context] >>> | \ >>> | \ >>> v v >>> X1 0-RTT Traffic Keys * >>> | >>> | >>> v >>> ES -> HKDF [ClientHello, ServerHello] >>> | \ >>> | \ >>> v v >>> X2 1-RTT Traffic Keys * >>> | >>> | >>> v >>> 0 -> HKDF [ClientHello...ClientFinished] >>> | >>> | >>> v >>> RMS, EMS >>> >>> As should be apparent, this key schedule is well-suited to the >>> simplified key change schedule in my previous message. >>> >>> Note 1: It might be attractive to not even bother with the first stage >>> if you aren't doing 0-RTT. It's not necessary then. However, this is >>> just an optimization. Also, if you don't want to extract an RMS or an >>> EMS you can skip the last stage (this is compatible). >>> >>> Note 2: The IKM for the final HKDF is 0, but in principle we could use >>> it to add some sort of new keying material, for instance g^xs if we >>> were using static DH certificates (see below). >>> >>> >>> In line with Hugo's message earlier today, the major argument against >>> this design is that it is more oriented towards a signature-based >>> system, which TLS 1.3 is today, than towards a DH certificate-based >>> system. To elaborate on this a bit, in a DH certificate-based system, >>> the server authenticates by proving knowledge of g^xs (and hence >>> s). In the current TLS 1.3 design you can do this trivially by >>> replacing the signature in the server CertificateVerify with a MAC >>> over the transcript (using g^xs as the key) [again, analysis needed.] >>> This is straightforward and doesn't require rearchitecting the >>> protocol really at all. However, this (as with the current >>> signature-based mode) does not provide confidentiality of the >>> connection if y is later revealed. >>> >>> As Hugo has noted several times, if you mix both g^xy and g^xs into >>> the traffic keys, then you are protected if either y or s is leaked, >>> which gives you somewhat stronger security properties with a DH >>> cetificate The current key schedule accommodates that by allowing for >>> SS to come before *or* after ES, but the simplified schedule does not >>> quite so easily. >>> >>> With that said, TLS 1.3 doesn=E2=80=99t support *any* pure static DH de= sign >>> now and will do so even less well if we remove the key change as >>> discussed above. There are at least three ways forward to incorporate >>> them in future: >>> >>> - Just do as I suggest above. >>> - Define a new DH cipher suite that adds an additional key change. >>> This would allow us only to have the key change complexity in >>> that mode. >>> - Replace the 0 in the above schedule with g^xs and then define that >>> the key for KeyUpdate is actually coming out of the final HKDF. >>> >>> Any of those seem like they wouldn=E2=80=99t be too hard to do, if and = when >>> we start having a lot of demand for DH certificates. >>> >>> Please discuss. >>> >>> -Ekr >>> >>> * Note that as I indicated in my previous message, it is possible to >>> generate multiple sets of keys at the same stage, if that is necessary >>> to handle the analysis concerns. >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 >> >> >> > --001a113d9b54ee0a1b052c2494c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Couple of comments below.

On Fri, Feb 19, 2016 at 9:14 AM, = Eric Rescorla <ekr@rtfm.com> wrote:


On Fri, Feb 19, 2016 at 2:12 AM, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
=

Note that this is (al= most) exactly the original KDF scheme of OPTLS as I
presented in Dallas=

Inde= ed, Ekr=E2=80=99s proposed scheme looks much like you original diagram.

I would like to clari= fy that this isn't *my* scheme, though I think it's a good
one. It came out of a long discussion with the people listed in my origin= al
message and probably is most closely derived from something Ka= rthik
drew. Sorry if I gave an impression to the contrary!
<= div>
In any case, I'm glad to see that it's close to = Hugo's original diagram,
since that's a good indication t= hat we're on the right track!


=
Anyway, from here you can see that the last HKDF in your = scheme (with 0 salt)
is= not needed. You can derive the RMS, EMS keys directly from the second HKDF=
(as siblings of 1-RTT = Traffic Keys). Am I missing something?

The purpose of the third HKDF is to bind = the handshake context (the full transcript) into
the resumption a= nd exporter keys. It adds no new key material.

=E2=80=8BI am still confused about this. Call K the key output b= y the Extract part of the second HKDF=E2=80=8B
=C2=A0
=E2=80=8B.
You derive 1-= RTT Traffic Keys as an output from Expand(K, whatever).
Why can't you use the same K to derive RMS and E= MS?=C2=A0
Namely,=C2=A0
=C2=A0compute RMS=3DExpand(K, la= bel=3D"RMS Derivation", ClientHello....ClientFinished)=E2=80=8B.<= /span>
=E2=80=8BSimilarly for EMS.
Thi= s would include all the information you wanted in the derivation of each ke= y,=C2=A0
and it is still a valid HKDF computation (namely, = it goes through extract and expand).
Am I missing something= ?

=C2=A0
Yes, that was my understanding as well. I see that Ilari suggested that th= is might
not be necessary (presumably as a consequence of having = the full shares
included in the stage 2 transcript rather than ju= st the nonces as in TLS 1.2.
The imperative here is to avoid crea= ting an attack like triple handshake or
the Cremers et al. attack= on the PSK-resumption. In any case, having the
EMS and RMS keys = derived at the end also helps enforce the logic that you
should n= ever be exporting/resuming until you have actually completed the handshake.=

=
What I do miss in this scheme = is the derivation of the Finished keys. I hope
you do not intend to use the application key for t= his!

= Indeed those are missing in the picture, but I believe Ekr means to derive = separate
finished keys alongside the 1-RTT Traffic keys (right af= ter the ServerHello)

Affirmative. Error in my diagram.=C2=A0

<= /div>
I also want to stress, for the record, that this simplification= has nothing to
do with= using the application keys for handshake protection.

I agree, this key schedul= e simplification seems orthogonal.

<= /div>
Yes, but... In the current 1-RTT mode, there is a derivati= on stage
that does not appear on this diagram, one that includes = the transcript up to the
server CertificateVerify and is used to = derive the application traffic keys. So,
if part of the intent of= this diagram is to reduce the number of points at which
we deriv= e, we will need to derive the application traffic keys at stage 2
even if they are separate from the handshake traffic keys. I believe this= =C2=A0
something you proposed, but I just want to clarify that th= is diagram would entail
a change in the timing of key derivation,= even if not the number of keys.

= =C2=A0
<= div>For what it=E2=80=99s worth, I am building a symbolic model of this new= key schedule and will
report my analysis results at TRON. It=E2= =80=99s not a cryptographic proof, but it should shake
out early = logical bugs in the design, if any.

Best,
Karthik


=
That "op= timization"
is ort= hogonal to this KDF simplification and hopefully will be reverted (*).

(*) You may say I'm a dreamer, But I may = not be the only one :-)
Nothing to be reverted yet, it'= ;s just a proposal. If it's a bad idea (and being prohibitively
hard to analyze is one reason it might be) then we shouldn't adopt i= t.

=E2= =80=8BIt complicates analysis, breaks generality and modularity, weakens th= e security guarantee,=C2=A0
but d
efinitely not "
=E2=80=8B
prohibitively
=E2=80=8B =E2=80=8B
hard to a= nalyze=E2=80=8B".

=E2=80=8BHugo
= =E2=80=8B
=C2=A0
Hugo

PS: I have a disa= greement with you in terms of the protocol now being=C2=A0
"signature based". Yes there = are signatures in the protocol but not all modes
use them and they are not always needed. In my ey= es the logic of the protocol
is best seen as DH-based with authentication occurring through the se= rver
Finished MAC (with= a key derived from SS which can take the values of g^xs,
= g^xy or PSK). That is common to *all* mo= des, including 0-RTT and PSK which do
not build on signatures. This is how the protocol was built = originally and
that str= ucture remains in spite of the added signatures.

Sorr= y about the misleading terminology. I just meant that it presently has sign= atures.=C2=A0
I'll try to be more precise in future.

-Ekr


<= /div>
On Thu, Feb 18, 2016 at 4:05 PM, Eric Rescorla <ekr@rt= fm.com> wrote:
Hi f= olks,

TL;DR.
Let's simplify the key = schedule.


DETAILS
This is= the second in a series of proposed simplifications to TLS 1.3
ba= sed on implementation experience and analysis once the protocol
s= tarts to harden.=C2=A0 The following suggestion comes out of conversations<= /div>
with Richard Barnes, Karthik Bhargavan, Antoine Delignat-Lavaud,<= /div>
Cedric Fournet, Markus Kohlweiss, Martin Thomson, Santiago Zanell= a and
others.

The current key schedule i= s elegant but it is actually more than we
need in that it allows = SS to be known either before or after ES. If we
assume (as is alw= ays true in the current TLS 1.3 modes) that SS is
known before or= at the same time as ES, then we can design a simpler
scheme whic= h looks more like a ladder. Something like:

=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0SS -> HKDF [ClientHello + Context]
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 | =C2=A0\
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 \
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v =C2=A0= =C2=A0v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 X1 =C2=A0 0-RTT Traffic Keys *
=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ES -> HKDF [ClientHello, Se= rverHello]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0\
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 \
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 v =C2=A0 =C2=A0v
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 X2 =C2=A0 =C2=A01-R= TT Traffic Keys *
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 v =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 0 -> HKDF [ClientHello...ClientFinished]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 v
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 RMS, EMS

As should be apparent, this key sc= hedule is well-suited to the
simplified key change schedule in my= previous message.

Note 1: It might be attractive = to not even bother with the first stage
if you aren't doing 0= -RTT. It's not necessary then.=C2=A0 However, this is
just an= optimization. Also, if you don't want to extract an RMS or an
EMS you can skip the last stage (this is compatible).

Note 2: The IKM for the final HKDF is 0, but in principle we could us= e
it to add some sort of new keying material, for instance g^xs i= f we
were using static DH certificates (see below).

In line with Hugo's message earlier today, t= he major argument against
this design is that it is more oriented= towards a signature-based
system, which TLS 1.3 is today, than t= owards a DH certificate-based
system. To elaborate on this a bit,= in a DH certificate-based system,
the server authenticates by pr= oving knowledge of g^xs (and hence
s). In the current TLS 1.3 des= ign you can do this trivially by
replacing the signature in the s= erver CertificateVerify with a MAC
over the transcript (using g^x= s as the key) [again, analysis needed.]
This is straightforward a= nd doesn't require rearchitecting the
protocol really at all.= However, this (as with the current
signature-based mode) does no= t provide confidentiality of the
connection if y is later reveale= d.

As Hugo has noted several times, if you mix bot= h g^xy and g^xs into
the traffic keys, then you are protected if = either y or s is leaked,
which gives you somewhat stronger securi= ty properties with a DH
cetificate The current key schedule accom= modates that by allowing for
SS to come before *or* after ES, but= the simplified schedule does not
quite so easily.=C2=A0

With that said, TLS 1.3 doesn=E2=80=99t support *any* pure= static DH design
now and will do so even less well if we remove = the key change as
discussed above. There are at least three ways = forward to incorporate
them in future:

-= Just do as I suggest above.
- Define a new DH cipher suite that = adds an additional key change.
=C2=A0 This would allow us only to= have the key change complexity in
=C2=A0 that mode.
- = Replace the 0 in the above schedule with g^xs and then define that
=C2=A0 the key for KeyUpdate is actually coming out of the final HKDF.

Any of those seem like they wouldn=E2=80=99t be too = hard to do, if and when
we start having a lot of demand for DH ce= rtificates.

Please discuss.

-Ekr

* Note that as I indicated in my previous = message, it is possible to
generate multiple sets of keys at = the same stage, if that is necessary
to handle the analysis conce= rns.




=


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


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



--001a113d9b54ee0a1b052c2494c5-- From nobody Fri Feb 19 11:57:14 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A95881B3492 for ; Fri, 19 Feb 2016 11:57:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.712 X-Spam-Level: X-Spam-Status: No, score=0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=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 Wfcg6oygzPHM for ; Fri, 19 Feb 2016 11:57:09 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BA0E1B348E for ; Fri, 19 Feb 2016 11:57:08 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id 78so60730579lfy.3 for ; Fri, 19 Feb 2016 11:57:08 -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:content-type; bh=LV/n4HtFib2vJYsntYe5cF527iPYAknO4P8vl5vdmso=; b=lOsgYCSZfiAZJ3ZGNmyvt36w2ISU3cNdj03SjYmRoT8kH+WcycCnjaqVZKknOM1hwn fagge0hyLBVUeCPdYvpD6LizUTdOmMT+h0bz4S8UnzF/t7g4dwm8Kzvt7ZWsSAHwjUYG 31436bSLcxcg/0fIJt5eQsOs2QEnK1fItOccB7W7IYV3VwzPpEdEFfX7ck9z7sobN3Y4 r5sok9ypKZYVVxhf89L75GIlLtnjdWnekyVS63x3DDp+mSXE1tNzCU3R8qC3aazjWE2p ugrPB0K5DxHJpZaXufQN2N2n8O5D1JvpJnYp1U1IJnr/o89m6Edo4scaD0O+4lOOJkKw Mk1Q== 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:content-type; bh=LV/n4HtFib2vJYsntYe5cF527iPYAknO4P8vl5vdmso=; b=KoVmhIkiKrHHy63hu3tQnApPVWz5nuWOBEjWAvfIf/b4AmrUkScfOfkdugs2DPXuNf dza/6tt3VEZo2Eabt56gpkITE/J4Eo/811zLOiUhK6aXZ5M53BP1MxMx4K+jVMEtwKjp KRinICRR1MlBxWoDJDsKqVrY4J6ZOZWG/fWRK+AIr6gUrcfr41ECe2arTCPdllMzxpaI MwYy0jqVNfq43s4rr5/ujKLk1BxDKnVW9KJBM++uURXo4JhgaNsrafGolMBr/GLrLd3x 1BD3rpLNETrW2oEH11dpzVN7ofEALQWK8JxnvdQo7ih9SCwZgtMhXhUg/k7Fym3gie0C SrTg== X-Gm-Message-State: AG10YOSmG00ylSQqZXrhHZ0zLtYUKsR21ZXJQYbu+hhwf1v7NSq6p1jHS6W8pzhEvVlXRLZN+KRoltwpMGRWJA== X-Received: by 10.25.21.90 with SMTP id l87mr5998435lfi.64.1455911826517; Fri, 19 Feb 2016 11:57:06 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Fri, 19 Feb 2016 11:56:36 -0800 (PST) In-Reply-To: References: <20160219105851.GA14585@LK-Perkele-V2.elisa-laajakaista.fi> From: Hugo Krawczyk Date: Fri, 19 Feb 2016 14:56:36 -0500 X-Google-Sender-Auth: _C_rC0C4EECe1g6OC0Rma_Wd0Qs Message-ID: To: Cedric Fournet Content-Type: multipart/alternative; boundary=001a113d9b543e7595052c24e38d Archived-At: Cc: Karthikeyan Bhargavan , Markulf Kohlweiss , "tls@ietf.org" , Antoine Delignat-Lavaud Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 19:57:12 -0000 --001a113d9b543e7595052c24e38d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 19, 2016 at 12:58 PM, Cedric Fournet wrote: > As pointed out by Karthik, we are not strongly advocating this > simplification, but we do not think it would weaken the security of TLS. > Details below. > I am glad you are not strongly advocating this. I strongly advocate not using the application keys to protect handshake messages. I want a well-delimited point where the output session key is as good as a fresh, never-used secret key, and that session key be used to protect subsequent record layer traffic. As I said, I cannot weigh this against implementation advantages of the freshness-violation approach; but these have to be *very* significant to be worth the security weakening. And yes, I think this is a security weakening. We are talking about two levels of guarantee. One, where the TLS key exchange protocol outputs a secret key that is good for *any* application that requires two parties to share a secret key. The other, where the use of the key produced by this protocol is secure enough for a *specific* application, namely, TLS record layer (at least in its current definition). The second is clearly weaker. It has a more limited (secure) use scope. For example, it means that changes to the record layer protocol could require a re-assessment of the security of the handshake, and certainly this is the case for a different application that somehow modifies the record layer or makes assumptions different than the intended use of the record layer. With a "generically secure" handshake this reassessment of the handshake would not be needed, you would only need to verify that your application is secure under an (ideally) shared secret key. I am sure we all agree that considering future changes to the record layer, changes to applications using the handshake, etc is not a theoretical concern. The last thing you want to assume is that the TLS environment and the protocol evolution is static. I think that a conservative take on this important point is the right way to go. H =E2=80=8Bugo=E2=80=8B > > -C=C3=A9dric, with the miTLS team > > > > > > In the following, I only consider the record layer keys, which are used > for authenticated encryption; I ignore all other derived key materials. T= he > TLS layered design goes as follows: > > - The handshake provides fresh keys to the record layer (depending on its > internal state machine) and keeps running; > > - The record layer uses the current keys for encrypting *all* traffic, > mixing handshake messages, alerts, and application data (once enabled). > > > > These keys are used sequentially, and only by the record-layer. They are > not directly used within the handshake protocol itself, or by the TLS > application. > > - Since the sequence of keys is meant to protect the whole stream of TLS > fragments, one needs to authenticate each point in the stream where there > is a key change, to prevent any traffic truncation. As discussed in anoth= er > thread, we believe this is correctly handled in draft#11, but each key > change remains a source of complication [1]. > > - There are excellent reasons to change keys between 0-RTT and 1-RTT > (stronger key materials, forward secrecy). > > - Otherwise, what matters is the provenance of the key (how it was > derived, what identities are associated with it) and there is no point > changing keys with the same provenance. > > > > The situation is particularly clear in 0-RTT: in draft#11, the client > always derives two record-layer keys from the same materials, and uses ea= ch > of these keys in turn to encrypt half of its 0-RTT flight, with a Finishe= d > message in-between that signals the key change. This key change does not > degrade security, but seems unnecessary. > > > > In 1-RTT, this is less obvious because, in draft#11, the handshake keys > and application-data keys are not exactly derived from the same materials= . > We believe this should be fixed (see the =E2=80=9Csimplified key schedule= =E2=80=9D thread). > Then the same argument applies: the key change is not terrible, but it is > an unnecessary complication. > > > > I disagree with Hugo that using the same record-layer key for handshake > and application data yields a proof of a weaker guarantee. As far as I ca= n > tell, this is a technicality in the cryptographic proof of the handshake, > and we still get the same security guarantees for TLS users [2]. I also > like simple proofs of generic security for the handshake core, but I do n= ot > see how they can cover the other features of TLS [e.g. 3, and late > handshake messages] with or without the simplification. Given the choice > between a simpler protocol that it is easier to implement correctly, and > simpler proofs for a core, I would rather simplify the overall protocol a= nd > do the extra proof work. > > > > One may argue about what would happen if some of the record-layer keys > were mis-used, against the TLS specification (despite its export mechanis= m) > and conclude that we need more, not less key changes [3]. But I would not > call it =E2=80=9Ca different application=E2=80=9D and I am still tempted = to simplify the > key schedule for its intended usage in TLS. > > > > > > [1] An attacker may, for instance, delete the last fragment encrypted > before the key change. Such a deletion will be caught at the protocol > layer, e.g. because the last fragment is not an =E2=80=9Cend_of_early_dat= a=E2=80=9D alert > or a Finished message. Without the key change, any deletion would be caug= ht > immediately, as the next fragment decryption fails. > > > > [2] we do not have a complete model for TLS 1.3 yet, but we developed a > detailed model for TLS 1.2 http://eprint.iacr.org/2014/182 similarly > covering record-layer key changes (for renegotiations) and the fact that > those keys were used to protect the Finished messages *before* key > confirmation and application-data traffic. The main difference with class= ic > models for key exchange, where the protocol runs to completion and return= s > =E2=80=9Cthe=E2=80=9D application key, is that in our model the honest in= stances provide > keys during the protocol run. > > > > [3] as recently discussed as 0.5-RTT, the spec enables the use of 1-RTT > keys before completing the handshake, with weaker guarantees on the > encrypted application data. However, an extra key change would require > additional signalling messages. > > > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* 19 February 2016 14:16 > *To:* Ilari Liusvaara > *Cc:* Karthikeyan Bhargavan ; tls@ietf.org > *Subject:* Re: [TLS] Proposal: don't change keys between handshake and > application layer > > > > > > > > On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara > wrote: > > On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote: > > > Regardless of whether we make this change though, I think it would be > > useful for the TLS 1.3 RFC to clearly limit the scope of various keys > > generated by the handshake. During the connection lifetime, we generate > > a series of record encryption keys: handshake and application keys for > > 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying. > > None of these keys should be used outside their intended use cases in a > > single connection. The only cross-connection secret specified in the > > protocol is the resumption master secret, and if applications want a > > key from TLS 1.3, they must only use the exporter master secret. All > > other keys are internal to TLS. > > I think TLS 1.3 RFC should specify what the protocol looks like and how > it can be used from application perspective. This includes specifying > what keys can be exported (among many other things, like how > authentication can be performed). > > I agree that exporting the main encryption keys or secrets those are > derived from for any purpose is a rotten idea. If you need keying or > authentication material, use TLS EXPORTER (tls-unique is deprecated) > with requirement to use EMS on prior versions[1]. > > > > This is the intent. I think we would be well-served to state this. > > > > > > Then one might need to export RMS. I think it should be exported as > blob that also contains other associated information (e.g ciphersuites). > And possibly also encrypted, using some MRAE algorithm. > > > > [1] Compatiblity hack: One might consider EMS always negotiated when > TLS 1.3 is negotiated. This could prvent applications that do know > about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3. > > That is, if application asks about TLS 1.3 (ServerVersion 3.4) > connection "is EMS enabled?" the answer will be always "yes" > (since the point of that check is to exclude THS attacks, and > TLS 1.3 already excludes those on baseline). > > > > Good suggestion. This in fact is what NSS currently does: > > > https://dxr.mozilla.org/mozilla-central/source/security/nss/lib/ssl/sslin= fo.c#70 > > > > > -Ekr > > > > > > > > > > > > > > -Ilari > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > --001a113d9b543e7595052c24e38d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 19, 2016 at 12:58 PM, Cedric Fournet <fournet@microsoft.com> wrote:

As pointed out by Karthik, we are not= strongly advocating this simplification, but we do not think it would weak= en the security of TLS. Details below.


I am glad you are not strongly advocating this.<= /div>
I strongly advocate not using the= application keys to protect handshake messages.
I want a well-delimited point where the output session key = is as good as a fresh, never-used secret key, and that session key be used = to protect subsequent record layer traffic.

As I said, I cann= ot weigh this against implementation advantages of the freshness-violation = approach; but these have to be *very* significant to be worth the security = weakening.=C2=A0

=
And yes, I think this is a security weakenin= g.
We are ta= lking about two levels of guarantee.
One, where the TLS key exchange protocol outputs a secret key that= is good for *any* application that requires two parties to share a secret = key.
The other, where the use of = the key produced by this protocol is secure enough for a *specific* applica= tion, namely, TLS record layer (at least in its current definition).
<= /div>

The second is clearly weaker. It has a more limited (secure) use sc= ope.
For example, it means that c= hanges to the record layer protocol could require a re-assessment of the se= curity of the handshake, and certainly this is the case for a different app= lication that somehow modifies the record layer or makes assumptions differ= ent than the intended use of the record layer.
With a "generically secure" handshake this reasse= ssment of the handshake would not be needed, you would only need to verify = that your application is secure under an (ideally) shared secret key.
=

I am sure we all agree that considering future changes to the reco= rd layer, changes to applications using the handshake, etc is not a theoret= ical concern.=C2=A0
The= last thing you want to assume is that the TLS environment and the protocol= evolution is static.

I think that a c= onservative take on this important point is the right way to go.

H
=E2=80=8Bugo=E2=80=8B

=C2=A0

-C=C3=A9dric, with the miTLS team<= /u>

=C2=A0

=C2=A0

In the following, I only consider the= record layer keys, which are used for authenticated encryption; I ignore a= ll other derived key materials. The TLS layered design goes as follows:

- The handshake provides fresh keys t= o the record layer (depending on its internal state machine) and keeps runn= ing;

- The record layer uses the current k= eys for encrypting *all* traffic, mixing handshake messages, alerts, and ap= plication data (once enabled).

=C2=A0

These keys are used sequentially, and= only by the record-layer. They are not directly used within the handshake = protocol itself, or by the TLS application.

- Since the sequence of keys is meant= to protect the whole stream of TLS fragments, one needs to authenticate ea= ch point in the stream where there is a key change, to prevent any traffic truncation. As discuss= ed in another thread, we believe this is correctly handled in draft#11, but= each key change remains a source of complication [1].

- There are excellent reasons to chan= ge keys between 0-RTT and 1-RTT (stronger key materials, forward secrecy).

- Otherwise, what matters is the prov= enance of the key (how it was derived, what identities are associated with = it) and there is no point changing keys with the same provenance.

=C2=A0

The situation is particularly clear i= n 0-RTT: in draft#11, the client always derives two record-layer keys from = the same materials, and uses each of these keys in turn to encrypt half of its 0-RTT flight, w= ith a Finished message in-between that signals the key change. This key cha= nge does not degrade security, but seems unnecessary.<= /p>

=C2=A0

In 1-RTT, this is less obvious becaus= e, in draft#11, the handshake keys and application-data keys are not exactl= y derived from the same materials. We believe this should be fixed (see the =E2=80=9Csimplifi= ed key schedule=E2=80=9D thread). Then the same argument applies: the key c= hange is not terrible, but it is an unnecessary complication.

=C2=A0

I disagree with Hugo that using the s= ame record-layer key for handshake and application data yields a proof of a= weaker guarantee. As far as I can tell, this is a technicality in the cryptographic proof of= the handshake, and we still get the same security guarantees for TLS users= [2]. I also like simple proofs of generic security for the handshake core,= but I do not see how they can cover the other features of TLS [e.g. 3, and late handshake messages] with or wi= thout the simplification. Given the choice between a simpler protocol that = it is easier to implement correctly, and simpler proofs for a core, I would= rather simplify the overall protocol and do the extra proof work.

=C2=A0

One may argue about what would happen= if some of the record-layer keys were mis-used, against the TLS specificat= ion (despite its export mechanism) and conclude that we need more, not less key changes [3]. But I= would not call it =E2=80=9Ca different application=E2=80=9D and I am still= tempted to simplify the key schedule for its intended usage in TLS.=C2=A0

=C2=A0

=C2=A0

[1] An attacker may, for instance, de= lete the last fragment encrypted before the key change. Such a deletion wil= l be caught at the protocol layer, e.g. because the last fragment is not an =E2=80=9Cend_of_e= arly_data=E2=80=9D alert or a Finished message. Without the key change, any= deletion would be caught immediately, as the next fragment decryption fail= s.

=C2=A0

[2] we do not have a complete model f= or TLS 1.3 yet, but we developed a detailed model for TLS 1.2 http://eprint= .iacr.org/2014/182 similarly covering record-layer key changes (for ren= egotiations) and the fact that those keys were used to protect the Finished= messages *before* key confirmation and application-data traffic. The main difference with classic models for key exchange, where t= he protocol runs to completion and returns =E2=80=9Cthe=E2=80=9D applicatio= n key, is that in our model the honest instances provide keys during the pr= otocol run.

=C2=A0

[3] as recently discussed as 0.5-RTT,= the spec enables the use of 1-RTT keys before completing the handshake, wi= th weaker guarantees on the encrypted application data. However, an extra key change would requ= ire additional signalling messages.

=C2=A0

=C2=A0

From: = TLS [mailto:tls-b= ounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 19 February 2016 14:16
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>; tls@ietf.org
Subject: Re: [TLS] Proposal: don't change keys between handshake= and application layer

=C2=A0

=C2=A0

=C2=A0

On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:

On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeya= n Bhargavan wrote:

> Regardless of whether we make this change though, I think it would be<= br> > useful for the TLS 1.3 RFC to clearly limit the scope of various keys<= br> > generated by the handshake. During the connection lifetime, we generat= e
> a series of record encryption keys: handshake and application keys for=
> 0-RTT and 1-RTT, and then a sequence of keys generated during rekeying= .
> None of these keys should be used outside their intended use cases in = a
> single connection.=C2=A0 The only cross-connection secret specified in= the
> protocol is the resumption master secret, and if applications want a > key from TLS 1.3, they must only use the exporter master secret. All > other keys are internal to TLS.

I think TLS 1.3 RFC should specify what the protocol looks like and how
it can be used from application perspective. This includes specifying
what keys can be exported (among many other things, like how
authentication can be performed).

I agree that exporting the main encryption keys or secrets those are
derived from for any purpose is a rotten idea. If you need keying or
authentication material, use TLS EXPORTER (tls-unique is deprecated)
with requirement to use EMS on prior versions[1].

=C2=A0

This is the intent. I think we would be well-served = to state this.

=C2=A0

=C2=A0

Then one might need to export RMS. I think it should= be exported as
blob that also contains other associated information (e.g ciphersuites). And possibly also encrypted, using some MRAE algorithm.



[1] Compatiblity hack: One might consider EMS always negotiated when
TLS 1.3 is negotiated. This could prvent applications that do know
about EMS but not TLS 1.3 from breaking when upgrading to TLS 1.3.

That is, if application asks about TLS 1.3 (ServerVersion 3.4)
connection "is EMS enabled?" the answer will be always "yes&= quot;
(since the point of that check is to exclude THS attacks, and
TLS 1.3 already excludes those on baseline).

=C2=A0

Good suggestion. This in fact is what NSS currently = does:

=C2=A0

-Ekr

=C2=A0

=C2=A0

=C2=A0

=C2=A0





-Ilari


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

=C2=A0


--001a113d9b543e7595052c24e38d-- From nobody Fri Feb 19 14:08:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 699EA1B34E1 for ; Fri, 19 Feb 2016 14:08:24 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bcCGW06jmwKf for ; Fri, 19 Feb 2016 14:08:23 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 070911B349D for ; Fri, 19 Feb 2016 14:08:23 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id e63so78198139ywc.3 for ; Fri, 19 Feb 2016 14:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=dQFvFDVKyWQA5fEEhburZo5sY+MCOZ6vZTBKaGyAa9M=; b=IQe858savNSpxChwEJc0JPAdjVgBvOUDvANvWyMUH5ri/TX4Vktm0d0XYH2BrQnfnm xqc/qvJwrK0GZtifCJgCHaqEiXl9z2KwXQmhyYH/MuxzDu81nNuU0/Jj2UF67irZjxrJ 7pIZsHUqmRxN9uJDbgEIczln+pjkx+E0B1Mir/xj2Cbofu+Lbwyq3B3U/QOsK8DLI/fR 1gAPsXp/LdIZw85W6CeVWkSru06gLTkan8+kYzaajVpajjfAT5bMdxkclmxhg/0iZvba 96Q2Yjygb5JXk9g/dWS7OFhqOtmN3kgz0OMeQJ3bt18k4zK5Ga18h9v6peO2jU3XAu/E ZHSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=dQFvFDVKyWQA5fEEhburZo5sY+MCOZ6vZTBKaGyAa9M=; b=L1qH3l6aNN66hGgkKxb1D2UhlmQfKIS773wKKYNvqs9Vh/DqY62fwA/jUIEOlPrkAk daTxdozpCANouR1XvhV2BknzZo3S1bQJ5WFjCYOjqalP6jI0ygFyVWKZveWEG7TBXmH9 mFLRy7ES4Kp4Pker93A4p+/Hb2r3Jd3sKoRtqpLFNooNDx4hwuEdZQOqvLRBfemZvhfA Lmp7bABgxrZmNd8odAfRqgBqEfBvnCE6pSyUIwtXAKrIYSXuixe9FzswcvlYFK49tj+J pQDTlmgHmze/XewmGdmDazXaIloSTOg5ihYmS7hz6xV96S9TP/GfaxrFzOt6a/ifUiZS JdlA== X-Gm-Message-State: AG10YOQEVnqczfU03nLKwxts4mwoWvl3P4Nb3R1QhGECB8Zse03PZC/2UK2Wj83RVLrn6Q== X-Received: by 10.129.80.87 with SMTP id e84mr8395971ywb.198.1455919702448; Fri, 19 Feb 2016 14:08:22 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id i67sm10152019ywf.34.2016.02.19.14.08.21 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 Feb 2016 14:08:21 -0800 (PST) From: Dave Garrett To: "tls@ietf.org" Date: Fri, 19 Feb 2016 17:08:20 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201602190044.23065.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201602191708.20869.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 22:08:24 -0000 On Friday, February 19, 2016 12:57:04 am Bill Cox wrote: > Having two different modes to achieve basically the same > thing in TLS 1.3 is a bad idea. On Friday, February 19, 2016 10:01:31 am Salz, Rich wrote: > I greatly prefer one way to do things. I do not fundamentally disagree. I would support dropping PSK resumption in favor of using only DHE 0RTT for resumption. With PSK resumption, as far as I know, the issue of what cipher suites to offer & use has not been settled, or at least written down in the spec. Not having to use all of the PSK suites (or non-PSK suites but actually using PSK, which could be confusing) and the PSK extension for resumption, and instead using some session ID and DHE 0RTT would be simpler and not loose capability. I think that requiring PSK for 0RTT would significantly reduce the availability of actually using 0RTT, whilst providing no way to improve the situation over the long term. It would mean that TLS only has 0RTT resumption and not actually have any 0RTT sessions. Dave From nobody Fri Feb 19 14:25:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3AE71B3547 for ; Fri, 19 Feb 2016 14:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 7584bk9tX9Am for ; Fri, 19 Feb 2016 14:25:05 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63C3D1B3550 for ; Fri, 19 Feb 2016 14:25:05 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id g127so78862243ywf.2 for ; Fri, 19 Feb 2016 14:25:05 -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:content-type; bh=AdUtZBMdnKQc40nw/nrL6P4V8OjlcDuEp7VaM2iBdhs=; b=tvaZQmmnpcxa7hx1WkbE4AjdyEyduQRm08uZlDAEaZyGg4hhHGF+RURRrbVYs+Cmz1 xmsvqvWadKuWU7vHVQQJTMhxyT3U0kE0cJyv9XVH9h3pg9g9VBD6zWYtgl93+tREnnOM wx50YdNMLjI9hZxBgcawqxyRfdTPSp9GSUH/vIKD6wzp66svJE20y1Ax+ijLWsuJd2SL WO31wWdBXfW7jt0Ypub8t2WumZPaWC+Z21K1MALGnt9vmIJBGkuxLGpnafEU90sqMRRk tHEKwtzMKq/hbg0gNSGVFFjsUgNpNQoULoPNJqr2xeP6JEckuvQftqh0/dDThs3Osuil /m4A== 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-type; bh=AdUtZBMdnKQc40nw/nrL6P4V8OjlcDuEp7VaM2iBdhs=; b=XHFv+HkYXh0fWin5q5Zjzf8tkGgbZLLrIK17NHRMqPdTqDXwfy92oSFfFBAoQHOftF 0atcDX23x6BD76J8jmIlOQWx4NCB+AGpc9VDEUmylXay/2o9Zr2qdkzbQc4Z5LfZS8iz 93KhwiSmdvb/RPmzvD2YcbUUychc+nBSN9pKXmnN+8CtOjktATUP2k29ajm94zyfnI8Y l8H5ONwa3xKMp34x7i++/ShHJ/zsi7sjsBK61pMVpE2Td5TM2b38u32HY0EgZ3TLBci+ 7GPElLCWiVOsUS5pLF46eQ/vf0yf7mOzv7EP0m++3PhkeNAyoRc90OD5Ci1uwVKw14Fa 4sgA== X-Gm-Message-State: AG10YORg8qrqe9cFcNC0p4D4JPqu3p7isJB53zqJKHCNlqC02HJVPXz2yfwPLqaGITYV+KScjSjc7eDeBSb5WA== X-Received: by 10.129.79.209 with SMTP id d200mr8045923ywb.115.1455920704710; Fri, 19 Feb 2016 14:25:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 19 Feb 2016 14:24:25 -0800 (PST) In-Reply-To: <201602191708.20869.davemgarrett@gmail.com> References: <201602190044.23065.davemgarrett@gmail.com> <201602191708.20869.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 19 Feb 2016 15:24:25 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114bbc966d1b98052c26f449 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 22:25:07 -0000 --001a114bbc966d1b98052c26f449 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett wrote: > On Friday, February 19, 2016 12:57:04 am Bill Cox wrote: > > Having two different modes to achieve basically the same > > thing in TLS 1.3 is a bad idea. > > On Friday, February 19, 2016 10:01:31 am Salz, Rich wrote: > > I greatly prefer one way to do things. > > I do not fundamentally disagree. I would support dropping PSK resumption > in favor of using only DHE 0RTT for resumption. > This would represent a major performance regression from TLS 1.2 and therefore I do not believe is practical. With PSK resumption, as far as I know, the issue of what cipher suites to > offer & use has not been settled, or at least written down in the spec. Not > having to use all of the PSK suites (or non-PSK suites but actually using > PSK, which could be confusing) and the PSK extension for resumption, and > instead using some session ID and DHE 0RTT would be simpler and not loose > capability. > I'm fairly far into a PSK-resumption implementation and I don't believe that that is going to be correct. I do agree that some details need to be written down, but I don't expect them to be that hard. I think that requiring PSK for 0RTT would significantly reduce the > availability of actually using 0RTT, whilst providing no way to improve the > situation over the long term. My impression is exactly the opposite. All the infrastructure to PSK-resumption and hence PSK-0RTT is already in place for TLS 1.2. And of course PSK-resumption is also much faster. It would mean that TLS only has 0RTT resumption and not actually have any > 0RTT sessions. Why do you think that this makes a material difference? -Ekr --001a114bbc966d1b98052c26f449 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Friday, February 19, 2016 12:57:04 am Bill Cox wrote:
> Having two different modes to achieve basically the same
> thing in TLS 1.3 is a bad idea.

On Friday, February 19, 2016 10:01:31 am Salz, Rich= wrote:
> I greatly prefer one way to do things.

I do not fundamentally disagree. I would support dropping PSK resump= tion in favor of using only DHE 0RTT for resumption.
<= br>
This would represent a major performance regression from TLS = 1.2
and therefore I do not believe is practical.


With PSK resumption, as far as I know, the issue of what cipher suites to o= ffer & use has not been settled, or at least written down in the spec. = Not having to use all of the PSK suites (or non-PSK suites but actually usi= ng PSK, which could be confusing) and the PSK extension for resumption, and= instead using some session ID and DHE 0RTT would be simpler and not loose = capability.

I'm fairly far into a P= SK-resumption implementation and I don't believe that that is going
to be correct. I do agree that some details need to be written down,= but I don't expect
them to be that hard.


I think that requiring PSK for 0RTT would significantly reduce the availabi= lity of actually using 0RTT, whilst providing no way to improve the situati= on over the long term.

My impression is exa= ctly the opposite. All the infrastructure to PSK-resumption and
h= ence PSK-0RTT is already in place for TLS 1.2. And of course PSK-resumption=
is also much faster.

=C2=A0

It would mean that TLS only ha= s 0RTT resumption and not actually have any 0RTT sessions.

Why do you think that this makes a material difference?

-Ekr
=C2=A0

--001a114bbc966d1b98052c26f449-- From nobody Fri Feb 19 15:15:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FEA41B3625 for ; Fri, 19 Feb 2016 15:15:14 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KL69raRpJFOu for ; Fri, 19 Feb 2016 15:15:12 -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 A48431B3623 for ; Fri, 19 Feb 2016 15:15:12 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id e63so79206416ywc.3 for ; Fri, 19 Feb 2016 15:15:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=HLpWK/6E6EilM5odBmPn2n2l3S4UPWL2WxXp/toy6ko=; b=VuJbyqxqIPKnEtz1mbUegME9cVHP33E8Cl+39bMhevOfa+G8Dlm/aQTSD3dVkxLti6 kQA8k9FBHG292D+kef+k+zlt0SrUXPXSQtyic2wC1C+ivP4mBPjH0dxxDO2+V55Ka2ly ILUbnJ9ro4cd/aWE7c0MWFW1ViuIuVDVfas45DvDRF/Z3Ystb+wGw1M0NNoyBkPY1Jvk mWzRIHVhGdpb2hVolurebasqi5NcpvqGR+NUQv/tJQXR+p2ZXhr/Uzvqu8ns4dWtgfec 9Grz8+6w7U+7P0Xh/xJkz1qTwRMbHNtblfLuqe8uliZnyliAc5D8DZvGygfEcmXrrI+0 +KFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=HLpWK/6E6EilM5odBmPn2n2l3S4UPWL2WxXp/toy6ko=; b=iS6RodbUwExf8y2xA3tm3j1SpPKosMLeMUZlOGI5UxLNGMi854F8rnW3jnjhssnm+i yuMh00JeyeNPHkePBPNGscJEcpzB7fAeMvDYvAHOk+xnO1xK0WepSnR0uLHQ38g6blbF KmRDEzrsIjwmbd0EZws8tZM+t/i+ZOtjMi81gP0pMUJ6owDURQapl7VKHtT2zz3fafIL m+4IDY3t2BzxGn7I0/amEu4r/3uwEqc++RlgwcW3oFFsGFfa0Usb5ojuDTfCDW6pvuyK 0EDkTGJL4mqhvwJXPuU/AGIJBiByu2krxHNn+OG5lVdqNku5jT/58yAFMRlR+1CaKZr2 E5HA== X-Gm-Message-State: AG10YORv9F55v/Gpzy0G1PVCK0yt7raudO2xcTOrOhoEYblxsd0bxVWlS2FN0MOkvH13Aw== X-Received: by 10.129.44.194 with SMTP id s185mr8713347yws.34.1455923711850; Fri, 19 Feb 2016 15:15:11 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id g128sm10350491ywg.33.2016.02.19.15.15.11 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 Feb 2016 15:15:11 -0800 (PST) From: Dave Garrett To: Eric Rescorla , "tls@ietf.org" Date: Fri, 19 Feb 2016 18:15:09 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201602191708.20869.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201602191815.10375.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 23:15:14 -0000 On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote: > My impression is exactly the opposite. All the infrastructure to PSK-resumption and > hence PSK-0RTT is already in place for TLS 1.2. And of course PSK-resumption > is also much faster. That's good to hear. The perf advantage is why I'm not advocating dropping it; merely saying that I too would prefer a single method if it didn't loose capability. Dropping PSK resumption drops less than dropping DHE 0RTT, but keeping both seems like the best option at the moment. > On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett wrote: > > It would mean that TLS only has 0RTT resumption and not actually have any 0RTT sessions. > > Why do you think that this makes a material difference? One of the fundamental complaints about TLS, performance-wise, is the added round trip time over plaintext. That's why the WG made a point to focus on adding 0RTT in the first place. Someone considering upgrading from HTTP to HTTPS generally has this concern (or any other protocol to a variant over TLS). With only PSK resumption, we can still always have a 1RTT hit on first connection, and revert to that after the session is considered expired. With DHE 0RTT we have a longer term config that could allow for more generic caching and distribution and thus not have to get that 1RTT hit in many scenarios. The lack of a current ability to easily distribute a new config system should not be used as evidence against creating a new config system that we would want to create a way to easily distribute. Even dumping the top few dozen sites' 0RTT DHE config into a static file in a client update would be a noticeable improvement over not doing so. Coming up with a better method can come next. People should be using TLS or encryption in general as a matter of responsibility, but they don't. Softening *all* barriers to them upgrading is very necessary to get more to switch. 0RTT PSK only gets rid of a delay in continuing a session, which in some use-cases might be minimally noticeable. 0RTT DHE allows for a first-connect with comparable speed to plaintext (in scenarios where 0RTT data is safe, namely most HTTP). Within the context of HTTP, which is singled out as a focus in the TLS WG charter, 0RTT DHE will provide a more noticeable latency reduction in comparison to 0RTT PSK only. Another issue is that of privacy with session resumption. If the only way to get 0RTT is to keep sessions alive, then clearing that cache on the client side costs a future 1RTT. You can, however, cache 0RTT DHE configs safely for a longer time because they are not specific to the user agent. (we should probably narrow the spec to state that configs SHOULD NOT be per-client) In order to reliably get 0RTT without DHE configs, applications/services would need to cache PSK resumption sessions for as long as possible, which leaves a distinct per-user marker on both the client and server. Anyone trying to optimize away the 1RTT hit of first-connect will be required to maintain a system that keeps more user identifiable information than we should want. Dave From nobody Fri Feb 19 15:31:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82AC1A8F46 for ; Fri, 19 Feb 2016 15:31:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtdXHQf08dWJ for ; Fri, 19 Feb 2016 15:31:34 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858E21A8876 for ; Fri, 19 Feb 2016 15:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5096; q=dns/txt; s=iport; t=1455924694; x=1457134294; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IZuvOjxdxL+VwJ6Ekrz6cR3EfV/jXh7AinyCxnLw+hM=; b=e2WWLhgKe/tk6SusX4S4ZkYf6jb2+JuiJOYkrBzrdrtWYqoLnsH32I50 Uhup+cRE7StjsfzEzXipspMiuXCp+iLOC3gTiq0X7WieuuV7ZpsQ4UU6s BgO3kIFp/odX3LjRYLs+rSOT+cbYhQ2JipYqEDr6HPTntvTO0fqcB5I36 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ABAgBKpcdW/4kNJK1egzpSbQa6PwENg?= =?us-ascii?q?WgXCoVsAoFBOBQBAQEBAQEBZCeEQQEBAQQBAQE3NBcEAgEIEQQBAQEeCQchBgs?= =?us-ascii?q?UCQgCBAESCId9AxIOtwQNhGABAQEBAQEBAQEBAQEBAQEBAQEBAQERBIYSgz59g?= =?us-ascii?q?jqBYwmESQWHUocJiCwBiESDJoFsgWONF4VygROHQgEeAQFCggMZgUhqh0I7fQE?= =?us-ascii?q?BAQ?= X-IronPort-AV: E=Sophos;i="5.22,473,1449532800"; d="scan'208";a="240429409" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Feb 2016 23:31:33 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1JNVXv0021271 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 19 Feb 2016 23:31:33 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 19 Feb 2016 17:31:32 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Fri, 19 Feb 2016 17:31:32 -0600 From: "Scott Fluhrer (sfluhrer)" To: Dave Garrett , Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Do we actually need semi-static DHE-based 0-RTT? Thread-Index: AQHRarGUzd/3c2l16U6aGMx/+/I1IZ8zQFwAgAADjACAAQ9fAIAABH6AgAAOLYD//5z38A== Date: Fri, 19 Feb 2016 23:31:32 +0000 Message-ID: <184c96f0ac1a423f8a96fbc645ff7f66@XCH-RCD-006.cisco.com> References: <201602191708.20869.davemgarrett@gmail.com> <201602191815.10375.davemgarrett@gmail.com> In-Reply-To: <201602191815.10375.davemgarrett@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.59] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2016 23:31:40 -0000 I would also suggest keeping PSK 0RTT. On of the things I'm looking at is postquatum cryptography (that is, crypto= graphy that would still be secure even if someone manages to build a large = quantum computer). While this is not the most important issue that TLS 1.3= needs to deal with; it's probably not in the top 100; however at some poin= t, TLS will need to deal with it, and it would be preferable if we could sa= y "here's a minor tweak/new ciphersuite/named group we apply to TLS 1.3, an= d we're good to go", rather than "we need to start doing a TLS 1.4". Here's one of the issues that I foresee; we have key exchange protocols tha= t look postquantum, however they can't do everything that (EC)DH can; eithe= r either must be run ephemerally (that is, no static keyshares, you have to= generate a fresh one for each key exchange), or the response keyshare is a= function of the initiator's one (and can't be used be used in a second exc= hange). While such a key exchange protocol would work fine in an initial contact si= tuation, it doesn't work out nearly as well in a DHE-0RTT protocol (which d= oes make both assumptions). Leaving in a doorway where we don't require ou= r cryptoprimitives to have such capabilities may, in the long run, make thi= ngs easier on us. > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dave Garrett > Sent: Friday, February 19, 2016 6:15 PM > To: Eric Rescorla; tls@ietf.org > Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? >=20 > On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote: > > My impression is exactly the opposite. All the infrastructure to > > PSK-resumption and hence PSK-0RTT is already in place for TLS 1.2. And > > of course PSK-resumption is also much faster. >=20 > That's good to hear. The perf advantage is why I'm not advocating droppin= g > it; merely saying that I too would prefer a single method if it didn't lo= ose > capability. Dropping PSK resumption drops less than dropping DHE 0RTT, bu= t > keeping both seems like the best option at the moment. >=20 > > On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett > wrote: > > > It would mean that TLS only has 0RTT resumption and not actually have > any 0RTT sessions. > > > > Why do you think that this makes a material difference? >=20 > One of the fundamental complaints about TLS, performance-wise, is the > added round trip time over plaintext. That's why the WG made a point to > focus on adding 0RTT in the first place. Someone considering upgrading fr= om > HTTP to HTTPS generally has this concern (or any other protocol to a vari= ant > over TLS). With only PSK resumption, we can still always have a 1RTT hit = on > first connection, and revert to that after the session is considered expi= red. > With DHE 0RTT we have a longer term config that could allow for more > generic caching and distribution and thus not have to get that 1RTT hit i= n > many scenarios. >=20 > The lack of a current ability to easily distribute a new config system sh= ould > not be used as evidence against creating a new config system that we woul= d > want to create a way to easily distribute. Even dumping the top few dozen > sites' 0RTT DHE config into a static file in a client update would be a n= oticeable > improvement over not doing so. Coming up with a better method can come > next. >=20 > People should be using TLS or encryption in general as a matter of > responsibility, but they don't. Softening *all* barriers to them upgradin= g is > very necessary to get more to switch. 0RTT PSK only gets rid of a delay i= n > continuing a session, which in some use-cases might be minimally noticeab= le. > 0RTT DHE allows for a first-connect with comparable speed to plaintext (i= n > scenarios where 0RTT data is safe, namely most HTTP). Within the context = of > HTTP, which is singled out as a focus in the TLS WG charter, 0RTT DHE wil= l > provide a more noticeable latency reduction in comparison to 0RTT PSK onl= y. >=20 > Another issue is that of privacy with session resumption. If the only way= to > get 0RTT is to keep sessions alive, then clearing that cache on the clien= t side > costs a future 1RTT. You can, however, cache 0RTT DHE configs safely for = a > longer time because they are not specific to the user agent. (we should > probably narrow the spec to state that configs SHOULD NOT be per-client) = In > order to reliably get 0RTT without DHE configs, applications/services wou= ld > need to cache PSK resumption sessions for as long as possible, which leav= es a > distinct per-user marker on both the client and server. Anyone trying to > optimize away the 1RTT hit of first-connect will be required to maintain = a > system that keeps more user identifiable information than we should want. >=20 >=20 > Dave >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Feb 19 16:03:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4471B36A6 for ; Fri, 19 Feb 2016 16:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 LpY2PCYMKwnj for ; Fri, 19 Feb 2016 16:03:25 -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 B899A1B3618 for ; Fri, 19 Feb 2016 16:03:24 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id u200so80186337ywf.0 for ; Fri, 19 Feb 2016 16:03:24 -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:content-type; bh=O1KiRap2HDwzvmI6FfZO1gMq+XwtczYFMPn8PplAdBg=; b=Uqsxc4kGgLodewZVhUX1NfRkr8dVyhwj9InL8A8l7CrdW2Q/93+JOcI/lvi4CdvrFp 1Phlb/G2SovLNQnxMFoKNcXcglrXHk/yIapyqHObLGPO5wQLWkYJCtO0V1H+zMM2aHl7 a38NG+A13ABePtcLhZib9P6HwWBEi8oik978BNLla95BHjRf8mnKMYjWcL8qx/CgdRqW /VqYQvLTyFtRp/U5fzWby1YcZRNiiotHvukvnorpUynGeHpAq2aA6NKPONPk9yfocsfE GnQ7FeLXgDOpQK7Mx2bv49o6wo61uS/Y+4X7H3ZDwkE+g+c4MEh27Aar8WEHXjlcvu0B ozsg== 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-type; bh=O1KiRap2HDwzvmI6FfZO1gMq+XwtczYFMPn8PplAdBg=; b=StB7rNWpaKlyBKd8PWUkOfnaKJtOS8Yo3pY6xWncr2irmM/nOok2NN/psoA9XyxTQ/ p1gSRkr5310kFmW309fGm1R8k9st0wsxUYDPWo5URpUeQAZn5YceVra20U2VZ5ZPTTEO Z/22Yj2Utn/K++g/iKr8stXN4eurmUveIurHT7NHHk96X1vCMhNCt5uJk9YDUe/vaECS lP/gOXNMUzK5Tdec/Q4SUhwqTzTFiKU1KwQ4CmiaLtoK3gjkUoQe9i/MFOHJ50Zh1+G4 CULWPYqEAZH7RILBonYh7joExio+ka9F0FEk8pQglzYYMkM3zlBbiJCNgg0aVZuzj0rR SpYw== X-Gm-Message-State: AG10YORJkZq5ueH3OLQmbZo4US83o8mHmOy741o36K7dt20lZsxn1FOC7gbY/VMaKwF7AZV+rWUsSU0ADJJo1g== X-Received: by 10.129.73.207 with SMTP id w198mr9212660ywa.223.1455926603999; Fri, 19 Feb 2016 16:03:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 19 Feb 2016 16:02:44 -0800 (PST) In-Reply-To: <201602191815.10375.davemgarrett@gmail.com> References: <201602191708.20869.davemgarrett@gmail.com> <201602191815.10375.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 19 Feb 2016 17:02:44 -0700 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a114dc91c0d1f82052c2854dd Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 00:03:27 -0000 --001a114dc91c0d1f82052c2854dd Content-Type: text/plain; charset=UTF-8 On Fri, Feb 19, 2016 at 4:15 PM, Dave Garrett wrote: > On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote: > > My impression is exactly the opposite. All the infrastructure to > PSK-resumption and > > hence PSK-0RTT is already in place for TLS 1.2. And of course > PSK-resumption > > is also much faster. > > That's good to hear. The perf advantage is why I'm not advocating dropping > it; merely saying that I too would prefer a single method if it didn't > loose capability. Dropping PSK resumption drops less than dropping DHE > 0RTT, but keeping both seems like the best option at the moment. > > > On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett > wrote: > > > It would mean that TLS only has 0RTT resumption and not actually have > any 0RTT sessions. > > > > Why do you think that this makes a material difference? > > One of the fundamental complaints about TLS, performance-wise, is the > added round trip time over plaintext. That's why the WG made a point to > focus on adding 0RTT in the first place. Someone considering upgrading from > HTTP to HTTPS generally has this concern (or any other protocol to a > variant over TLS). With only PSK resumption, we can still always have a > 1RTT hit on first connection, and revert to that after the session is > considered expired. With DHE 0RTT we have a longer term config that could > allow for more generic caching and distribution and thus not have to get > that 1RTT hit in many scenarios. > > The lack of a current ability to easily distribute a new config system > should not be used as evidence against creating a new config system that we > would want to create a way to easily distribute. Even dumping the top few > dozen sites' 0RTT DHE config into a static file in a client update would be > a noticeable improvement over not doing so. Coming up with a better method > can come next. > > People should be using TLS or encryption in general as a matter of > responsibility, but they don't. Softening *all* barriers to them upgrading > is very necessary to get more to switch. 0RTT PSK only gets rid of a delay > in continuing a session, which in some use-cases might be minimally > noticeable. 0RTT DHE allows for a first-connect with comparable speed to > plaintext (in scenarios where 0RTT data is safe, namely most HTTP). Within > the context of HTTP, which is singled out as a focus in the TLS WG charter, > 0RTT DHE will provide a more noticeable latency reduction in comparison to > 0RTT PSK only. > This seems to basically come down to an assessment of how likely it is that we in fact will have an out-of-band priming mechanism. My sense from talking to the people most likely to deploy such a thing is that that's not actually very likely to emerge. Note that we're primarily discussing what has to appear in TLS 1.3. If something like this emerged it can be added in a future extension. appreciate that this is a judgement call and for a long time I leaned the way you are arguing, but lately I've started to feel like the arguments to the contrary are fairly persuasive. > Another issue is that of privacy with session resumption. If the only way > to get 0RTT is to keep sessions alive, then clearing that cache on the > client side costs a future 1RTT. You can, however, cache 0RTT DHE configs > safely for a longer time because they are not specific to the user agent. > (we should probably narrow the spec to state that configs SHOULD NOT be > per-client) In order to reliably get 0RTT without DHE configs, > applications/services would need to cache PSK resumption sessions for as > long as possible, which leaves a distinct per-user marker on both the > client and server. Anyone trying to optimize away the 1RTT hit of > first-connect will be required to maintain a system that keeps more user > identifiable information than we should want. > I don't find this argument very persuasive. The server need not store any information at all (because it can use tickets). As a practical matter, having the server's config leaks the fact that you had contacted the server just as much as having a session ticket. We already see this with HPKP and HSTS information and that's definitely public. -Ekr --001a114dc91c0d1f82052c2854dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 19, 2016 at 4:15 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote:
> My impression is exactly the opposite. All the infrastructure to PSK-r= esumption and
> hence PSK-0RTT is already in place for TLS 1.2. And of course PSK-resu= mption
> is also much faster.

That's good to hear. The perf advantage is why I'm not advoc= ating dropping it; merely saying that I too would prefer a single method if= it didn't loose capability. Dropping PSK resumption drops less than dr= opping DHE 0RTT, but keeping both seems like the best option at the moment.=

> On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
> > It would mean that TLS only has 0RTT resu= mption and not actually have any 0RTT sessions.
>
> Why do you think that this makes a material difference?

One of the fundamental complaints about TLS, performance-wise, is th= e added round trip time over plaintext. That's why the WG made a point = to focus on adding 0RTT in the first place. Someone considering upgrading f= rom HTTP to HTTPS generally has this concern (or any other protocol to a va= riant over TLS). With only PSK resumption, we can still always have a 1RTT = hit on first connection, and revert to that after the session is considered= expired. With DHE 0RTT we have a longer term config that could allow for m= ore generic caching and distribution and thus not have to get that 1RTT hit= in many scenarios.

The lack of a current ability to easily distribute a new config system shou= ld not be used as evidence against creating a new config system that we wou= ld want to create a way to easily distribute. Even dumping the top few doze= n sites' 0RTT DHE config into a static file in a client update would be= a noticeable improvement over not doing so. Coming up with a better method= can come next.

People should be using TLS or encryption in general as a matter of responsi= bility, but they don't. Softening *all* barriers to them upgrading is v= ery necessary to get more to switch. 0RTT PSK only gets rid of a delay in c= ontinuing a session, which in some use-cases might be minimally noticeable.= 0RTT DHE allows for a first-connect with comparable speed to plaintext (in= scenarios where 0RTT data is safe, namely most HTTP). Within the context o= f HTTP, which is singled out as a focus in the TLS WG charter, 0RTT DHE wil= l provide a more noticeable latency reduction in comparison to 0RTT PSK onl= y.

This seems to basically come down to= an assessment of how likely it is that we in fact will
have an o= ut-of-band priming mechanism. My sense from talking to the people most like= ly
to deploy such a thing is that that's not actually very li= kely to emerge. Note that we're
primarily discussing what has= to appear in TLS 1.3. If something like this emerged
it can be a= dded in a future extension. =C2=A0appreciate that this is a judgement call = and for a
long time I leaned the way you are arguing, but lately = I've started to feel like the arguments
to the contrary are f= airly persuasive.

=C2=A0
Another issue is that of privacy with session resumption. If the= only way to get 0RTT is to keep sessions alive, then clearing that cache o= n the client side costs a future 1RTT. You can, however, cache 0RTT DHE con= figs safely for a longer time because they are not specific to the user age= nt. (we should probably narrow the spec to state that configs SHOULD NOT be= per-client) In order to reliably get 0RTT without DHE configs, application= s/services would need to cache PSK resumption sessions for as long as possi= ble, which leaves a distinct per-user marker on both the client and server.= Anyone trying to optimize away the 1RTT hit of first-connect will be requi= red to maintain a system that keeps more user identifiable information than= we should want.

I don't find this = argument very persuasive. The server need not store any information at all<= /div>
(because it can use tickets). As a practical matter, having the s= erver's config leaks the
fact that you had contacted the serv= er just as much as having a session ticket. We already
see this w= ith HPKP and HSTS information and that's definitely public.
<= br>
-Ekr
=C2=A0

--001a114dc91c0d1f82052c2854dd-- From nobody Fri Feb 19 16:38:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B0321B341C for ; Fri, 19 Feb 2016 16:38:35 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dF0Ka3sBUz8C for ; Fri, 19 Feb 2016 16:38:34 -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 1C46E1B32CA for ; Fri, 19 Feb 2016 16:38:34 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id g127so80625591ywf.2 for ; Fri, 19 Feb 2016 16:38:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=yte74+qR87ju00nLWwB0M/ZwQdF3OYpAJtoY51cE500=; b=Jt/wmDyesYhrdjYT2jsF6OfuP76/canSx1BDiBW+JbiwoqLPCwFXoQkjIuAgvzelsN eEg98MSXiLk5Ewkbg1oEqMZGCT+6eyPC15LOSdh6aVozHdTDhQLCvYWp1CzUMTpW+REB IcOKRPip6oEGp9dwCydg7w3fxhdAQGbepXAxWOREFbGih7YEtkdH/rpNmbn8MyGfAXLQ kGOBJ/8buIFYKSkPml9rhxV/tvQWR6YqJai1a4UHlMF1nnFMJu7sVWK778SlVcXMDP6A RCY4qYqfCF3u8ByuDawNmy4orZzabk4zCg3G4DzU3xvrpwFZjwCdfSLxXmRngeu6N4Ys Qtrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=yte74+qR87ju00nLWwB0M/ZwQdF3OYpAJtoY51cE500=; b=ADCUMEOxYz0I891rJV9rHolR7tFlxNsVhflsbnwySXyFiSFXxa+s9bQ8wza9DR9M5+ zLyY8kkj8umVe15tpYzvnTwxjKa/aFKMnBX6mhPEUpFt9hV0/Dx+vYbGwyqTnFbLn3+/ lDOgSw8RB020Ga0vTjiAoLasQ+tFsl5dCVtjRZzxPb0Y3mtBGb9hEwTJcyKEhVQE4Bls sChFts/KvtXVmXAuWXuYhdLtx69xPy78yMn8WFC9YqplXu/+aZoMmyQgunnEcmTca/bb AwRvZR2QB57r4u9yrOZCnBQ+RlBUQ73mjunwTSsNR0GKCD34HVCoo9cJJbW+zhAzzvnB yp5A== X-Gm-Message-State: AG10YORW1ScrbHPM5GRxGzDiskFHifDZxxoN4SshL+lHWL8W5j2lFVQuHgM2+hVmRVXxqA== X-Received: by 10.129.87.3 with SMTP id l3mr8515685ywb.149.1455928713514; Fri, 19 Feb 2016 16:38:33 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id o23sm10608789ywd.30.2016.02.19.16.38.32 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 Feb 2016 16:38:32 -0800 (PST) From: Dave Garrett To: Eric Rescorla , "tls@ietf.org" Date: Fri, 19 Feb 2016 19:38:31 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201602191815.10375.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201602191938.31574.davemgarrett@gmail.com> Archived-At: Subject: [TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 00:38:35 -0000 I just had an idea. There is significant doubt of how useful semi-static DH= E 0RTT would be due to the difficulty of distributing the configs out-of-bo= und. I don't dispute this; I merely dispute that no capability is better th= an minimal, in this realm. There is another way that they could be helpful,= however. Take a typical HTTP page and a client with no prior knowledge. (could be ap= plicable to other applications, but the TLS WG does have a charter to take = special note of HTTP latency; subresources' lack of HTTPS often is a stated= reason for a site's lack of HTTPS overall) There will be a 1RTT cost witho= ut having a pre-cached way to do 0RTT, and then after that there will be a = 1RTT cost for *every* subresource on a different server. To do HTTPS for th= e servers of 3rd party scripts, ads, user-posted images/video embeds, etc.,= each of those servers will need to be connected to by the client with TLS = and no prior knowledge, meaning a 1RTT cost. This could be significantly op= timized by creating a new HTTP extension that allows servers to enumerate t= he domains on a page, cache all those domains' semi-static DHE config, and = push them to each client in their first flight returning the primary resour= ce. This would allow all subresources to be fetched by the client with a 0R= TT cost, and just a single 1RTT cost for the primary resource. Servers coul= d simply refresh their cache of their subresources' semi-static DHE configs= on a daily basis. A stale config can be sent to a client and it can still = fallback to 1RTT, though. Clients would not need to have any prior knowledg= e in order to significantly benefit from 0RTT in this scenario. TLS 1.3 wou= ld need to have some way of facilitating this scenario in order to devise a= way to do this sort of thing in HTTP (or another general protocol with sub= resources). The general point I'm trying to convey here is that we can come up with way= s to use this to improve latency noticeably, if given the underlying capabi= lity. We don't know how effectively it can be used until we try. Dave From nobody Fri Feb 19 16:47:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68F11B2A78 for ; Fri, 19 Feb 2016 16:47: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, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mNz_o9X5zkEw for ; Fri, 19 Feb 2016 16:47:32 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 21B431B2CE6 for ; Fri, 19 Feb 2016 16:47:31 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id xg9so46053682igb.1 for ; Fri, 19 Feb 2016 16:47:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-transfer-encoding; bh=6OqfS6CY73jWrFexMkXP3CpVCNue6vsgz8WVURkUI4w=; b=mZbx4bopL0fl12YwtVw3B+/7IleUoVnn3IZhe+xlH55Mzv/jqJYyiwdg6eIhbyHRXB vL9BZpffkue+OPiMsTetGnVZ/mFVqCZ2/lO144hgKEwCRIl8ud+TkULE6dOdIjQDZwzs 7Nk5A+XbAPGidnG+KLhhyZ46MsE7Y8WEB8a7gKj8n4gUTHvVwL0PEG2QxaUGLdm8f6S0 D0kl+1S9yEjFpqFpcUarnQh9+usvgGtD6FnhPCcJNZvz+tu+Kyb8Ay4FrwjGTIQvElW/ CxZ6uvczg5qkO8Sqzl+g6I7LJTfVHD2/ioURNHIXE3TaX+1qAsLjXoO2s5qSOZ0YZXpM ocAg== 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:date :message-id:subject:from:to:cc:content-transfer-encoding; bh=6OqfS6CY73jWrFexMkXP3CpVCNue6vsgz8WVURkUI4w=; b=gFtj00zMoOSuLK9acelrbejxzf+6FJHllWUUnViT6Uxa+k9xlmCpmL3FemjYDWUysO TomRLIfXIm/0iRcyKIMOdBgAA+q7xJnr4k36PBMOBaRg+Tj1rzo/O032NbzDlXyF24ct LAqEzkH6pfNciDSW4pSHSF9sR82J1WDE1B1n35j11ZRDAiWVygAU7wS+HQjgxAiGdit/ kf9+3hd5Gtwfsc31Yuk8VGWeb4RQ2xSFhjBLFRCCCTcU4gXYse+szPyqrx93UUPCeNds K+35UfQvo6JKbOqD7PJb+VZXX5yIH3Uxlfn2hkOJMw+G4R1ykQbOXLSGcyU+esjiZ07N dZOg== X-Gm-Message-State: AG10YOTb0vCg9H80621WpSZQhwM/lr7TkCVGTQa1lRDsT/H4Y4m5wLGBb5PMxBBjNczuJHDE4AxoODxHQ6Phgg== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr656580igz.58.1455929251415; Fri, 19 Feb 2016 16:47:31 -0800 (PST) Received: by 10.36.53.79 with HTTP; Fri, 19 Feb 2016 16:47:31 -0800 (PST) In-Reply-To: <201602191938.31574.davemgarrett@gmail.com> References: <201602191815.10375.davemgarrett@gmail.com> <201602191938.31574.davemgarrett@gmail.com> Date: Fri, 19 Feb 2016 16:47:31 -0800 Message-ID: From: Martin Thomson To: Dave Garrett Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 00:47:34 -0000 This really only helps on the first connection attempt. Browsers already pre-warm connections to subresource hosts. On 19 February 2016 at 16:38, Dave Garrett wrote: > I just had an idea. There is significant doubt of how useful semi-static = DHE 0RTT would be due to the difficulty of distributing the configs out-of-= bound. I don't dispute this; I merely dispute that no capability is better = than minimal, in this realm. There is another way that they could be helpfu= l, however. > > Take a typical HTTP page and a client with no prior knowledge. (could be = applicable to other applications, but the TLS WG does have a charter to tak= e special note of HTTP latency; subresources' lack of HTTPS often is a stat= ed reason for a site's lack of HTTPS overall) There will be a 1RTT cost wit= hout having a pre-cached way to do 0RTT, and then after that there will be = a 1RTT cost for *every* subresource on a different server. To do HTTPS for = the servers of 3rd party scripts, ads, user-posted images/video embeds, etc= ., each of those servers will need to be connected to by the client with TL= S and no prior knowledge, meaning a 1RTT cost. This could be significantly = optimized by creating a new HTTP extension that allows servers to enumerate= the domains on a page, cache all those domains' semi-static DHE config, an= d push them to each client in their first flight returning the primary reso= urce. This would allow all subresources to be fetched by the client with a = 0RTT cost, and just a sin > gle 1RTT cost for the primary resource. Servers could simply refresh the= ir cache of their subresources' semi-static DHE configs on a daily basis. A= stale config can be sent to a client and it can still fallback to 1RTT, th= ough. Clients would not need to have any prior knowledge in order to signif= icantly benefit from 0RTT in this scenario. TLS 1.3 would need to have some= way of facilitating this scenario in order to devise a way to do this sort= of thing in HTTP (or another general protocol with subresources). > > The general point I'm trying to convey here is that we can come up with w= ays to use this to improve latency noticeably, if given the underlying capa= bility. We don't know how effectively it can be used until we try. > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Feb 19 17:00:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ABBF1B37BE for ; Fri, 19 Feb 2016 17:00:34 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1b20vyII3v0J for ; Fri, 19 Feb 2016 17:00:33 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 056021B37B7 for ; Fri, 19 Feb 2016 17:00:33 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id u200so80858951ywf.0 for ; Fri, 19 Feb 2016 17:00:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=6CrGRzCl3Aqv6T2QEKj24gQn5qTHx6G73uo0Bo2pSDM=; b=XW0vUlQARUeorzLV3YtimvVnj9pW5QygxKmA6bU8vh2Jg6PSesFVZRG61rKgGnzjUm nvnJNMrVZQlbOZTKqDmXWb+1m2vszc808bx3pc/xgs042SmgFd0VhMrULaWPq8sKoxyU ZKo5vifVZd/tvAUjlmCV//BPpiaPOc4CxZhJ/rc8VDdiIH/JoXcvfUwnfOm+FX1IhjBG ECWvS5eiUdUwpRuc6BMk0KqyR0/rJPimgFUkzY45CSJp+V0rVQTAgRP3GmfKYcsz9igm rQjJxK9HpMoOFqBbEe0MFP8XsnV6VwbzWksQhyXalHWU3fjFnemEDcMLcSOLf1EM9Fj7 tLZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=6CrGRzCl3Aqv6T2QEKj24gQn5qTHx6G73uo0Bo2pSDM=; b=i7YzkI0Ixa4amA881Nx8PIAzf3e7cxDkW2sk4f/JoSimcMDxn/uLrlC4ooBM9pXSpo Ms0Y1REIERO/Hpa76ZKIh7JNiDlNZ3psnkmxZgMblnmQPdpsQjFjFQea/bVI49i4SFVK PwRKCI+9U3F8uzDmO4z8GKE/dpt0A8EcoWyEW+5DNsjZrNZGSSzaFfJfMwwI2NrmdSrM SflcyY/Oc3/TwqnkkOHXeJNeEe8IDNhjyznt008GGPlunSkhjHOF2+O2jhDekab434PZ 16Pdx7W+EBJdoUJK0st+rUgIqtIi5355xN6FI43Be2x8d6Jev1tZ6qUY/Yu7FeHnOwOR 3eAw== X-Gm-Message-State: AG10YOQTiHj4lFrcwjD4Mpl4ogPnMKc8j4/tJVp6s1oBiQKjrX4mvZ95Q9O595iB3u0Cvw== X-Received: by 10.13.246.5 with SMTP id g5mr8616401ywf.118.1455930032428; Fri, 19 Feb 2016 17:00:32 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id z7sm10704533ywf.7.2016.02.19.17.00.23 (version=TLS1 cipher=AES128-SHA bits=128/128); Fri, 19 Feb 2016 17:00:24 -0800 (PST) From: Dave Garrett To: Martin Thomson Date: Fri, 19 Feb 2016 20:00:22 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <201602191938.31574.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201602192000.23101.davemgarrett@gmail.com> Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 01:00:34 -0000 On Friday, February 19, 2016 07:47:31 pm Martin Thomson wrote: > This really only helps on the first connection attempt. Browsers > already pre-warm connections to subresource hosts. The first connect is important, as are new connections after a cache clear (think also, private browsing modes). Providing this capability to TLS 1.3 clients (likely also requiring HTTP/2) would allow for browsers to explicitly have a way to do this, rather than speculatively "pre-warm" connections. Additionally, servers could push a cached config for links on pages if they wanted to. Servers supporting this could effectively chain together to give 0RTT for virtually all normal user connections. Clients would not have to open connections to arbitrary link destinations in order to optimize away this 1RTT. (yes, there's the TCP 1RTT too, but that's a separate issue) Dave From nobody Fri Feb 19 17:53:27 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB461B37CA for ; Fri, 19 Feb 2016 17:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 Oq8O-G2bE3rE for ; Fri, 19 Feb 2016 17:53:25 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A378A1B3794 for ; Fri, 19 Feb 2016 17:53:24 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id g127so81451010ywf.2 for ; Fri, 19 Feb 2016 17:53:24 -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:content-type; bh=Zgo90DPAKqcn+3QC6iF53sD/S1TvR5cf1qyCifX/GS0=; b=min5cgvRNTVubYGxwV71FOUHxJK3boDyeteDr2tCq0R3hH0hFYwRMgkPVtCshgAcPq COQRW3PBBD3jrzPPAJgzPcC7NvORDwKMRm7I0Cep12V21G8FI4+IGsIn+CF7rcSAQhID wurufR0/Q27R7xmORJgD9I2vb3bShJWPkkDH31xuFRxfjD4Q7QdHDZdL0K/TuDnFnG0C FP+QSHttJdN2P6liqSUyYdhoIt1T3eXMlvCD7guxBKThiFTKHjqsKB1psOXVlvjiFrLk +nBwIOaRyz8NWBoMmaAyTe1jQYLCtcvhdepRdKKG3PyeoH1fYhwFhv5wCkna0sCh9QVt /PlQ== 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-type; bh=Zgo90DPAKqcn+3QC6iF53sD/S1TvR5cf1qyCifX/GS0=; b=TSkDKFjhi+SDYuk6JAGFcVWVx3voGNerRoJc5x2nDO7CZFft/rAzIe+WiWLratNwL4 X949ScO6Q2Wt8dr8UumRX7N5zaVd/vt/rOHH1rz7+lO/iyPOVFadBmx/ZL20QhrqC4a4 7mQP3HSOw6Jww5GyL5hpCCq/C9xihsCi4yx54iJor6EYU7+oUbBMO821KsgwaPQMUWWU kzyYgxC30S2TglFRlqMUHvfU00Yp6HdFmx8g8LCBDf7Ul35RLAtLsnwq/KD9St/Jk24+ pfz5GV2PXcIQx0jp5UUlPA4flt90pb3CcclbASHIUzuX1aD94MFD3Qf4zTbFKzu6ffEW 8s3A== X-Gm-Message-State: AG10YOT02J8zVvGHEfnag0DvbUtR4OSSc9e+tjqWsCpr8FsfCA9s8TYkUdRr4KmTeZtmpBx7JqD9+U2dhP42fg== X-Received: by 10.129.46.15 with SMTP id u15mr8285926ywu.129.1455933203786; Fri, 19 Feb 2016 17:53:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Fri, 19 Feb 2016 17:52:44 -0800 (PST) In-Reply-To: <201602192000.23101.davemgarrett@gmail.com> References: <201602191938.31574.davemgarrett@gmail.com> <201602192000.23101.davemgarrett@gmail.com> From: Eric Rescorla Date: Fri, 19 Feb 2016 17:52:44 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a11414df06def7f052c29ddf9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 01:53:26 -0000 --001a11414df06def7f052c29ddf9 Content-Type: text/plain; charset=UTF-8 I don't believe that this is going to work very well, since it is a fairly large burden for referring servers to refresh their state. -Ekr On Fri, Feb 19, 2016 at 5:00 PM, Dave Garrett wrote: > On Friday, February 19, 2016 07:47:31 pm Martin Thomson wrote: > > This really only helps on the first connection attempt. Browsers > > already pre-warm connections to subresource hosts. > > The first connect is important, as are new connections after a cache clear > (think also, private browsing modes). > > Providing this capability to TLS 1.3 clients (likely also requiring > HTTP/2) would allow for browsers to explicitly have a way to do this, > rather than speculatively "pre-warm" connections. > > Additionally, servers could push a cached config for links on pages if > they wanted to. Servers supporting this could effectively chain together to > give 0RTT for virtually all normal user connections. Clients would not have > to open connections to arbitrary link destinations in order to optimize > away this 1RTT. (yes, there's the TCP 1RTT too, but that's a separate issue) > > > Dave > --001a11414df06def7f052c29ddf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I don't believe that this is going to work very well, = since it is a fairly large burden for referring
servers to refresh thei= r state.

-Ekr


On Fri, Feb 19, 2016 at= 5:00 PM, Dave Garrett <davemgarrett@gmail.com> wrote:<= br>
On Friday, February 19, = 2016 07:47:31 pm Martin Thomson wrote:
> This really only helps on the first connection attempt.=C2=A0 Browsers=
> already pre-warm connections to subresource hosts.

The first connect is important, as are new connections after a cache= clear (think also, private browsing modes).

Providing this capability to TLS 1.3 clients (likely also requiring HTTP/2)= would allow for browsers to explicitly have a way to do this, rather than = speculatively "pre-warm" connections.

Additionally, servers could push a cached config for links on pages if they= wanted to. Servers supporting this could effectively chain together to giv= e 0RTT for virtually all normal user connections. Clients would not have to= open connections to arbitrary link destinations in order to optimize away = this 1RTT. (yes, there's the TCP 1RTT too, but that's a separate is= sue)


Dave

--001a11414df06def7f052c29ddf9-- From nobody Sat Feb 20 04:07:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 082791A8879 for ; Sat, 20 Feb 2016 04:07:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p2gRAdP7Xo49 for ; Sat, 20 Feb 2016 04:07:07 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 071151A8904 for ; Sat, 20 Feb 2016 04:07:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D1B752880; Sat, 20 Feb 2016 14:07:04 +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 fY0T8kGAafCQ; Sat, 20 Feb 2016 14:07:04 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 953E221C; Sat, 20 Feb 2016 14:07:04 +0200 (EET) Date: Sat, 20 Feb 2016 14:07:00 +0200 From: Ilari Liusvaara To: Eric Rescorla Message-ID: <20160220120700.GA15801@LK-Perkele-V2.elisa-laajakaista.fi> References: <201602191938.31574.davemgarrett@gmail.com> <201602192000.23101.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Mass 0RTT of subresources with no prior knowledge (was Re: Do we actually need semi-static DHE-based 0-RTT?) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 12:07:09 -0000 On Fri, Feb 19, 2016 at 05:52:44PM -0800, Eric Rescorla wrote: > I don't believe that this is going to work very well, since it is a fairly > large burden for referring > servers to refresh their state. Then there is the question of authenticating the state. -Ilari From nobody Sat Feb 20 10:54:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E7C1ACECB for ; Sat, 20 Feb 2016 10:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.012 X-Spam-Level: X-Spam-Status: No, score=-0.012 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_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lilVWmM97Vf for ; Sat, 20 Feb 2016 10:53:56 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0116.outbound.protection.outlook.com [65.55.169.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBC2D1ACEC8 for ; Sat, 20 Feb 2016 10:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zQoWIoCnCn3lh1HK8YlUtycLYM/kkZcprH3kiYRAu2A=; b=SiDvzQTrnh057260TTTK0Np6rBmNwvVXZQGacbxrRavZMlPEsPl9EB5ufN6VC6NYcA2eqi2IpmN2ecOwa0rv2o+TQlym01QE1/VkVsLcRXiymmdK3H+d0sC2dKRia0rREx6aUPqOTzSbOulBES/ytCbsOT786VgjijUhwdqHpts= Received: from BLUPR03CA005.namprd03.prod.outlook.com (10.255.124.22) by BL2PR03MB307.namprd03.prod.outlook.com (10.141.68.21) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 18:53:50 +0000 Received: from BL2FFO11FD005.protection.gbl (10.255.124.4) by BLUPR03CA005.outlook.office365.com (10.255.124.22) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Sat, 20 Feb 2016 18:53:49 +0000 Authentication-Results: spf=pass (sender IP is 206.191.249.68) smtp.mailfrom=microsoft.com; ee.technion.ac.il; dkim=none (message not signed) header.d=none;ee.technion.ac.il; dmarc=pass action=none header.from=microsoft.com; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.249.68 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.249.68; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.249.68) by BL2FFO11FD005.mail.protection.outlook.com (10.173.161.1) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Sat, 20 Feb 2016 18:53:46 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net (141.251.48.82) by AM3PR30MB050.064d.mgd.msft.net (141.251.48.83) with Microsoft SMTP Server (TLS) id 15.1.415.9; Sat, 20 Feb 2016 18:53:45 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) by AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) with mapi id 15.01.0415.013; Sat, 20 Feb 2016 18:53:45 +0000 From: Cedric Fournet To: Hugo Krawczyk Thread-Topic: [TLS] Proposal: don't change keys between handshake and application layer Thread-Index: AQHRallRU9dkEV6l5E6zOYRLVi6qCZ8x48sAgAAfHgCAARGDAIAAH+mAgAA3KwCAADW28IAAKV4AgAEzqGA= Date: Sat, 20 Feb 2016 18:53:44 +0000 Message-ID: <4cfe8afe17a44ed096102aacf12dcbc3@AM3PR30MB049.064d.mgd.msft.net> References: <20160219105851.GA14585@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.48.5] X-MS-Office365-Filtering-Correlation-Id: 5d711687-8ac2-42ff-fbcc-08d33a272af8 Content-Type: multipart/alternative; boundary="_000_4cfe8afe17a44ed096102aacf12dcbc3AM3PR30MB049064dmgdmsft_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11FD005; 1:iaajt/1CrDtWGI6vxjlE0Us/Xf/+qJ6P/9DQgY/rMJgwajxt9SqeJkycgKsFmJJIFxo/s3n0j8BNJwRfHipHROn22guqpPcIOQe8+uRYo/196klU1ljhckBLTcjI6O/QVzLiGO4CiRD4w5LtASK6bQe7oxOzLmfLpUhTmoax5BnqmPHspL51g/RKRTtaEcXxAJr5YAquxXS796MNi4tNM/0jCckGnhNgAFnAinwcKUK1HcKr/uMHH8PeijszaENL1Jq0CD1gR+t3TLnLyggG4I5fdw7dakbqL6bV6yup+yf5L71FsPFPFbzHjLcdnpdVMPBfwWh3T7jxscbiIQ8uHqu34CHxnpfmG4seG+4rv0mPsTDuzD+k0AYLeXl5O76v X-Forefront-Antispam-Report: CIP:206.191.249.68; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(377454003)(189002)(3905003)(24454002)(51444003)(199003)(5005710100001)(11100500001)(87936001)(10290500002)(110136002)(10090500001)(107886002)(4001430100002)(6806005)(108616004)(5008740100001)(76176999)(102836003)(86146001)(15975445007)(5001960100002)(3846002)(92566002)(24736003)(19300405004)(10400500002)(54356999)(50986999)(512874002)(5004730100002)(106466001)(2906002)(300700001)(19580405001)(2950100001)(106116001)(561944003)(19617315012)(86362001)(1220700001)(5003600100002)(586003)(2900100001)(19625215002)(4326007)(66066001)(575784001)(1096002)(189998001)(16236675004)(86612001)(16796002)(6116002)(33646002)(84326002)(93886004)(19580395003)(579004); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB307; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; MLV:sfv; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB307; 2:scsFGmpScmtypEesPJphc6PqYLQjPlqEVA3MejmTSOFbHjRhJNEaXYQponUpBR5lUZwV4wSCsmOHTyX6yxd3lL5U5Zdr4IKhf9kzDVLxWhzKAv7+jNoItcGlJpE7FKdvk5B32ouvAEEQbuHqeuMTy4vEZsS6s2W8k+0annQyaKswC78W5EbVNVLw3UOwIy7u; 3:ikNB7/hZKaBXsZcJjiRCGivDCbbTI87EjM5/oLfLPk/0XlSgOAksdqHVLi7zT6G+Vel5bBKxi51gEW+aJ2HAbLsvzxmf/sM23bHH0+ptT0vYAe85C/lNDJ9F2X40jrNVJQNx8VteAbvNcBa5GnIgbA0KUPf0qs9fgBnK9Q0MWvyb5LX3xAankdiJha1aAMuhhgIRPpwQtitugOGiSKXKc7R9xQmofun5a1uxDhoWlsVSyQq1r1nuRyzwlAtTZ1GCwZ+tdEHP9eE4s/iHXwhs1g==; 25:+gH4oxkV4xdQCVEHApp7oqOmpG/PKousFM2cuNgJcxDlwYKGAUct7Yjzdv9MQ9/eiqaI/lh/7bkqhz2nVSIW3A/FOqDUqKqlfZFF16lw1LDCE9wNPvI1INMhvuQwXSVICfI2hc5jI+sZ+VYK3UzNHeaoRGlPsTvhOEpqcch0JEgaN29t9zMfNy/5RWyO87vwrSsTiy7YXXDb2XQcTkb8FYDwuJY4nykeh5I8lcS4/ayNT7MAIyRyTIgbLi88syHoYcz5hl2ue0vcHdXtIh6pGfwoUR/pneGa+6L2TkrkW5nT2bhQ8UmdiVGNKi4igRMSms25C9bYERSRkGKaSPAVyS0jiOQ5snMMpj4kimGaAJw= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BL2PR03MB307; X-O365EOP-Header: O365_EOP: Allow for Unauthenticated Relay X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB307; 20:vFHg/fKOZyj/UKo85fA+YwzDQtm1ovSYBqo1OdGgSNzTI2EUPK9kuXiza8ywJIHCE6viB5BS0Ac5QJllCoVQS0u0d/rkq+uQLbalyvYEOLgsc/y594iZSC/+EjSAjGbwDdisuWl6CEVkHlUB+ZGvebYjkP4nq1d2B3c4ge/dW8QRNt5pyLYeW6qfbx13jpYXd2J9Pk5ErJmG+t7HQlVhk1/vcE4wZ3iMWhgC7SXFoVCcljVl/7NJ2bCs9PuSs7YfOECxW/8SCIC0Fe0wAZfJbqkXaue8wJ2i/b2kVnKibTnK17hWVI5drXNrH87LmguH3F7rEd8P09h/JNiRgvmztSrZPlHAClDKZNKWBUKr77wxtmdsfo2j3WxfsxA5kqUnGRLMCrdCL61UT8QPeduwvEgFjmQOp/jPHOERd8SxqcHwxkC2Y1nSd+i+cwRjMQ1JFp1CT9WcYOJaEi0ltCxeDRnKLJqk1hOZ3TZBRXH0R1AI2mfqav3voyYOzz1s5bO/ii1ubMFKUkPHHg4n8rvWBLkE7s1dqOddrjdGE4zWyOyKw1P+fZPoutESZe9DCAlK2rVleCfZ5Tb9BJ4Zfqp9WEbe/7nfnLv9L9bBXffFlns= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(13016025)(13018025)(13021025)(5005006)(13013025)(13024025)(13023025)(3002001)(10201501046)(61426038)(61427038); SRVR:BL2PR03MB307; BCL:0; PCL:0; RULEID:; SRVR:BL2PR03MB307; X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB307; 4:2Op7NYP38YKY3KE9uQXTUo4+FOsZsaZgqu5arHKXykMkczyJebhnQrpbK27y6WQZ7A9k+OHppSX0+00FBna1IWfknNkhUblFcVvKTgVwRSj9ez4t9AQ/pVj+6HnEFysKqso0/n++VG9FAPREhhI6TBlPACsygNYdOo7J9lIRiH54DEk5+0aQFUWZAYo/e1VDe8u3QiX3zOnNdnvUY3SLGj2Qwk8Mfmad22stxToP1/8AHIOxx1N/KoU36kn5e1NafWacBNAkAo7p6kUy2UcL/JNfzA6qPjhfFiXtpA1aGP0ny+5L4Wqkh3Dmx9nHF5lNselMsOUQeadfe4eiPueVd3u5XcGQzxB/OH+HSOADqVBCGhQrCEwDivginIEH1cgzgBXJ5ryR+kFMj5lJryyMLA5y2QqhtGA2cKIAFOYi5D/xOInRQ06V1oeiBHWCmjMDFxTiLolUQBhAPoacjBQSoUiGRi4L35TrR7f/DbmUOXVbgDUy1pE0dY/j+mHCYfdY51mwA97Q9nDHyziy5TtI478hgVLnBnpnoKraw1C5xsI= X-Forefront-PRVS: 0858FF8026 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BL2PR03MB307; 23:jYNlong1O4MOB2UMKIBGgkllQBBOkgRGGrCNbjPOcW?= =?us-ascii?Q?VtFThVcSE3DjgBeQyPecxzMeW56Z3Wz84OQUA1zeLkqNswkxEWV7if2WdXUT?= =?us-ascii?Q?KGN4rYyySnYPOz87+uvQOn8qEsew+jF45P4OCLQNfyW3Qq9JenQ4i8msZU5z?= =?us-ascii?Q?XixNGPiEA+jMLQnTgVe7FggK02UXxlTfTzsBLkMJLmXXHeNMdjd8ZwggZ+7D?= =?us-ascii?Q?Qw3Njb/0gj/KUWZxl58Ks7YoAsWVdctjNygK1zr+0nY7mIfZq5vfOHlSBwTV?= =?us-ascii?Q?ISW191sn2hFvuKFnruCdLUq3yJ8k2/x+k9cjW98hAfO/tfr9HtEKBExkxMvf?= =?us-ascii?Q?5j0FoUTtxvzZ3zTyRMsqfWJTBRpze7+ocgDu6uQTB8mhzTYG2wvblLRuHaEg?= =?us-ascii?Q?YOz2e6llzBanzabRZQ8KCQauI+zOBzKRqfol95t/SJoJc4mRSpflM5dcquEW?= =?us-ascii?Q?ZhgluQnIj1VovoCJpjJT66xDFCJ8aaqsMvh1IZ92GyEfFVoF2C4eq2JUBepu?= =?us-ascii?Q?nA64/dWpfUkNBh0QP/zIk7w49YzI/ShDE2+oTG4/wt3TVSoA7ecwOHGruhMQ?= =?us-ascii?Q?Q4puDMvqRLisNG1JubjluCNgvnPrshfBKBAhb6GEOOOfB+EWOu/hv/ie0OtH?= =?us-ascii?Q?QFpyqMJfMR9vw2X1/UjLV2FHeOJYrYLiszbOQDZEq5EXw3Cpr4RvcJfESaz6?= =?us-ascii?Q?ShA2Fx8R4560Z754weNd5fRgx1V0n4Iq7Fnn0XwiZh17ifqPGn3uZBUvDkQb?= =?us-ascii?Q?sfW3sA6jDvPj9bFFc/vgZTnsiFcq23okhGl7+9yFWHx57CnHhJ+TGaRjX/CM?= =?us-ascii?Q?b3U/E278VyaYh/bl4vld2uL9xeNDMOxWNOB032fkJvDbusVcAn1ygmj+VEOc?= =?us-ascii?Q?oRXR96AbcEAzfj8y8DIsPIJaRwE3uhbM4Nbij/riJEZfc3Y/2JDY8BTWBSXB?= =?us-ascii?Q?QVDNj0LgcHu/VsVh6Hr3/QvY8LlgXLvaYEg+sr4Pc53SjcA9qKDbL4tdPj61?= =?us-ascii?Q?HO9Vltz0e1cS0QV3+s9oebMFFO7t6aHsbeEyR3CSsz7A+XKImETt2WwTFQrB?= =?us-ascii?Q?vNKWD9p0CFsqVMozCcDQY+S/oOxZ6pxnlgCGk0eJXX9aMcC20zlFWqM5sumb?= =?us-ascii?Q?/8GZEKIFHJNwrovRSd/AfwqWjoFmHXT0QhWknQezGd88djjh+IrvsBje7uXt?= =?us-ascii?Q?7efcdZ6NiXdeQ1YL/VLvJzEgm0jHjKiy/ZzlLCEmoLq7ToS/6nj6TSb2iyhv?= =?us-ascii?Q?K4o1Xlgvw5wxE2uI43PUuxqAEFr0a15ucmHhZtHcFmCPxoKlagfm+wctKqHw?= =?us-ascii?Q?Hn2J44h0HDGBLbgms/UduQv3BTxKKuHbFhi8L3SpLpA6EzUo3cYN/qfMn1kv?= =?us-ascii?Q?IXKWLyIX6szd1W6vi/b4PwdaT5XFgCdNrkCOkJYsV3rg/RaA3j4rL1VcWK0e?= =?us-ascii?Q?63KaFygA8JHhmgAW/ovpg7lL8KOEVQSHixpxlezEsw41Lo3gDpG8ffj6uLmN?= =?us-ascii?Q?+4v8xhUpgXMI7rzsf7orbxbGCjEGPk7yHoMU0VxqPwNI1Qs933pjts2ialXR?= =?us-ascii?Q?VX4DwjchwUx75wUcXwL2FwDAaGa8OopsWgS2Lz9J97tyZ9l9xaqsrCf+7U?= X-Microsoft-Exchange-Diagnostics: 1; BL2PR03MB307; 5:Gj7uumTPXHXbT6L8sBFSzlpTDmr5eRti/WGFISnq3d+PqJ8v++dz7eo3KCVD9X7A/qqyp5ko0us5xGkrnDl8sKdFYNvPtZxpq+cq663KSGwQRlYirw8uQK8YAfYq/n33kXza5O9Fj1cLtN0iusGHRQ==; 24:MSt5zzuj5KWC1ozeJ1fdiNu0VW1Dxt5KCAXBZxNGMIQzBn1Xb+BkPUXTJ7+n6Li7hk0N9qS28j+Wa+AAEp87VclY430hgZIJBF5ZqGeOgxo= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2016 18:53:46.9747 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.249.68]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2PR03MB307 Archived-At: Cc: Karthikeyan Bhargavan , Markulf Kohlweiss , "tls@ietf.org" , Antoine Delignat-Lavaud Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 18:54:02 -0000 --_000_4cfe8afe17a44ed096102aacf12dcbc3AM3PR30MB049064dmgdmsft_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgaGF2ZSByYXRoZXIgZGlmZmVyZW50IHZpZXdzIG9mIHRoZSBwcm90b2NvbC4gWW91IHNlZSB0 aGUgcmVjb3JkIGxheWVyIGFzIGEgc2FtcGxlIGFwcGxpY2F0aW9uIG91dHNpZGUgVExTLCB3aGVy ZWFzIG91ciBtb2RlbCAodGllZCB0byBvdXIgaW1wbGVtZW50YXRpb24pIGNvbXBvc2VzIHRoZSBo YW5kc2hha2UgYW5kIHRoZSByZWNvcmQtbGF5ZXIgc3VicHJvdG9jb2xzIHRvIGdldCBzZWN1cml0 eSBhdCB0aGUgVExTIEFQSS4gWW91IGFsc28gcmVhc29uIGFib3V0IOKAnHRoZSBvdXRwdXQgc2Vz c2lvbiBrZXnigJ0sIHdoZXJlYXMgdGhlIGhhbmRzaGFrZSBzdWNjZXNzaXZlbHkgcHJvdmlkZXMg YWxsIHRyYWZmaWMga2V5cyB0byB0aGUgcmVjb3JkIGxheWVyIGFuZCB0aGVuIHByb3ZpZGVzIGFu ICJleHBvcnRlciBzZWNyZXQiIHRvIHRoZSBhcHBsaWNhdGlvbi4gQWNjb3JkaW5nbHksIHlvdSBh c3N1bWUgdGhlIGhhbmRzaGFrZSBlbmNyeXB0cyBpdHMgb3duIG1lc3NhZ2VzLCB3aGVyZWFzIFRM UyBkZWxlZ2F0ZXMgdGhhdCB0YXNrIHRvIHRoZSByZWNvcmQgbGF5ZXLigJRzZWUgbXkgcHJldmlv dXMgcG9zdCBmb3IgdGhlIGRldGFpbHMuDQoNCkhlbmNlLCBJIHVuZGVyc3RhbmQgeW91ciBnZW5l cmFsIGFyZ3VtZW50LCBhbmQgSSB0aGluayBpdCBhcHBsaWVzIHBlcmZlY3RseSB0byB0aGUgImV4 cG9ydGVyIHNlY3JldCIsIGJ1dCBub3QgdG8gdGhlIHByb3Bvc2VkIHNpbXBsaWZpY2F0aW9uIChp bnZvbHZpbmcgdHdvIHRyYWZmaWMga2V5cyBpbnRlcm5hbCB0byBUTFMsIHN1Y2Nlc3NpdmVseSB1 c2VkIGJ5IHRoZSBzYW1lIHJlY29yZC1sYXllcikgYW5kIEkgZG9u4oCZdCBzZWUgaG93IHRoaXMg c2ltcGxpZmljYXRpb24gd291bGQgY2F1c2UgYW55IHNlY3VyaXR5IHdlYWtlbmluZy4NCg0KQmVz aWRlcywgaW4gb3VyIGFuYWx5c2lzIG9mIHRoZSBoYW5kc2hha2UsIHdlIGdldCBwcmVjaXNlbHkg dGhlIHNhbWUg4oCcZnJlc2gsIG5ldmVyLXVzZWQgc2VjcmV04oCdIHByb3BlcnR5IHlvdSBhcmUg YWR2b2NhdGluZywgd2l0aCBvciB3aXRob3V0IHRoZSBzaW1wbGlmaWNhdGlvbiwgZWFjaCB0aW1l IHRoZSBoYW5kc2hha2UgcHJvdmlkZXMga2V5cyB0byB0aGUgcmVjb3JkIGxheWVyLiBUaGVzZSBw b2ludHMgYXJlIHdlbGwtc3BlY2lmaWVkIGFuZCBkZWxpbWl0ZWQuIFRoZXkganVzdCBkbyBub3Qg Y29pbmNpZGUgd2l0aCB0aGUgZW5kIG9mIHRoZSBoYW5kc2hha2UuIFNvIEkgZG9u4oCZdCBzZWUg YW55IGZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgaW4gdGVybSBvZiBnZW5lcmljLXNlY3VyaXR5Lg0K DQpXZSBhcmUgbGVmdCB3aXRoIHNjZW5hcmlvcyB3aGVyZWJ5IHRoZSByZWNvcmQgbGF5ZXIsIGdp dmVuIGJvdGggdGhlIGhhbmRzaGFrZSBhbmQgYXBwbGljYXRpb24tZGF0YSB0cmFmZmljIGtleXMs IHNvbWVob3cgbGVha3Mgb25seSBvbmUgb2YgdGhlIHR3by4gSSBkb27igJl0IG1pbmQga2VlcGlu ZyB0aGUga2V5IGNoYW5nZSBpZiBzb21lb25lIGlzIGNvbmNlcm5lZCBhYm91dCBpdC4NCg0KLUPD qWRyaWMNCg0KRnJvbTogaHVnb2tyYXdAZ21haWwuY29tIFttYWlsdG86aHVnb2tyYXdAZ21haWwu Y29tXSBPbiBCZWhhbGYgT2YgSHVnbyBLcmF3Y3p5aw0KU2VudDogMTkgRmVicnVhcnkgMjAxNiAx OTo1Nw0KVG86IENlZHJpYyBGb3VybmV0IDxmb3VybmV0QG1pY3Jvc29mdC5jb20+DQpDYzogRXJp YyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPjsgSWxhcmkgTGl1c3ZhYXJhIDxpbGFyaWxpdXN2YWFy YUB3ZWxoby5jb20+OyBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gPGthcnRoaWsuYmhhcmdhdmFuQGdt YWlsLmNvbT47IHRsc0BpZXRmLm9yZzsgTWFya3VsZiBLb2hsd2Vpc3MgPG1hcmt1bGZAbWljcm9z b2Z0LmNvbT47IEFudG9pbmUgRGVsaWduYXQtTGF2YXVkIDxhbnRkbEBtaWNyb3NvZnQuY29tPjsg U2FudGlhZ28gWmFuZWxsYS1CZWd1ZWxpbiA8c2FudGlhZ29AbWljcm9zb2Z0LmNvbT4NClN1Ympl Y3Q6IFJlOiBbVExTXSBQcm9wb3NhbDogZG9uJ3QgY2hhbmdlIGtleXMgYmV0d2VlbiBoYW5kc2hh a2UgYW5kIGFwcGxpY2F0aW9uIGxheWVyDQoNCg0KDQpPbiBGcmksIEZlYiAxOSwgMjAxNiBhdCAx Mjo1OCBQTSwgQ2VkcmljIEZvdXJuZXQgPGZvdXJuZXRAbWljcm9zb2Z0LmNvbTxtYWlsdG86Zm91 cm5ldEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpBcyBwb2ludGVkIG91dCBieSBLYXJ0aGlrLCB3 ZSBhcmUgbm90IHN0cm9uZ2x5IGFkdm9jYXRpbmcgdGhpcyBzaW1wbGlmaWNhdGlvbiwgYnV0IHdl IGRvIG5vdCB0aGluayBpdCB3b3VsZCB3ZWFrZW4gdGhlIHNlY3VyaXR5IG9mIFRMUy4gRGV0YWls cyBiZWxvdy4NCg0KSSBhbSBnbGFkIHlvdSBhcmUgbm90IHN0cm9uZ2x5IGFkdm9jYXRpbmcgdGhp cy4NCkkgc3Ryb25nbHkgYWR2b2NhdGUgbm90IHVzaW5nIHRoZSBhcHBsaWNhdGlvbiBrZXlzIHRv IHByb3RlY3QgaGFuZHNoYWtlIG1lc3NhZ2VzLg0KSSB3YW50IGEgd2VsbC1kZWxpbWl0ZWQgcG9p bnQgd2hlcmUgdGhlIG91dHB1dCBzZXNzaW9uIGtleSBpcyBhcyBnb29kIGFzIGEgZnJlc2gsIG5l dmVyLXVzZWQgc2VjcmV0IGtleSwgYW5kIHRoYXQgc2Vzc2lvbiBrZXkgYmUgdXNlZCB0byBwcm90 ZWN0IHN1YnNlcXVlbnQgcmVjb3JkIGxheWVyIHRyYWZmaWMuDQoNCkFzIEkgc2FpZCwgSSBjYW5u b3Qgd2VpZ2ggdGhpcyBhZ2FpbnN0IGltcGxlbWVudGF0aW9uIGFkdmFudGFnZXMgb2YgdGhlIGZy ZXNobmVzcy12aW9sYXRpb24gYXBwcm9hY2g7IGJ1dCB0aGVzZSBoYXZlIHRvIGJlICp2ZXJ5KiBz aWduaWZpY2FudCB0byBiZSB3b3J0aCB0aGUgc2VjdXJpdHkgd2Vha2VuaW5nLg0KDQpBbmQgeWVz LCBJIHRoaW5rIHRoaXMgaXMgYSBzZWN1cml0eSB3ZWFrZW5pbmcuDQpXZSBhcmUgdGFsa2luZyBh Ym91dCB0d28gbGV2ZWxzIG9mIGd1YXJhbnRlZS4NCk9uZSwgd2hlcmUgdGhlIFRMUyBrZXkgZXhj aGFuZ2UgcHJvdG9jb2wgb3V0cHV0cyBhIHNlY3JldCBrZXkgdGhhdCBpcyBnb29kIGZvciAqYW55 KiBhcHBsaWNhdGlvbiB0aGF0IHJlcXVpcmVzIHR3byBwYXJ0aWVzIHRvIHNoYXJlIGEgc2VjcmV0 IGtleS4NClRoZSBvdGhlciwgd2hlcmUgdGhlIHVzZSBvZiB0aGUga2V5IHByb2R1Y2VkIGJ5IHRo aXMgcHJvdG9jb2wgaXMgc2VjdXJlIGVub3VnaCBmb3IgYSAqc3BlY2lmaWMqIGFwcGxpY2F0aW9u LCBuYW1lbHksIFRMUyByZWNvcmQgbGF5ZXIgKGF0IGxlYXN0IGluIGl0cyBjdXJyZW50IGRlZmlu aXRpb24pLg0KDQpUaGUgc2Vjb25kIGlzIGNsZWFybHkgd2Vha2VyLiBJdCBoYXMgYSBtb3JlIGxp bWl0ZWQgKHNlY3VyZSkgdXNlIHNjb3BlLg0KRm9yIGV4YW1wbGUsIGl0IG1lYW5zIHRoYXQgY2hh bmdlcyB0byB0aGUgcmVjb3JkIGxheWVyIHByb3RvY29sIGNvdWxkIHJlcXVpcmUgYSByZS1hc3Nl c3NtZW50IG9mIHRoZSBzZWN1cml0eSBvZiB0aGUgaGFuZHNoYWtlLCBhbmQgY2VydGFpbmx5IHRo aXMgaXMgdGhlIGNhc2UgZm9yIGEgZGlmZmVyZW50IGFwcGxpY2F0aW9uIHRoYXQgc29tZWhvdyBt b2RpZmllcyB0aGUgcmVjb3JkIGxheWVyIG9yIG1ha2VzIGFzc3VtcHRpb25zIGRpZmZlcmVudCB0 aGFuIHRoZSBpbnRlbmRlZCB1c2Ugb2YgdGhlIHJlY29yZCBsYXllci4NCldpdGggYSAiZ2VuZXJp Y2FsbHkgc2VjdXJlIiBoYW5kc2hha2UgdGhpcyByZWFzc2Vzc21lbnQgb2YgdGhlIGhhbmRzaGFr ZSB3b3VsZCBub3QgYmUgbmVlZGVkLCB5b3Ugd291bGQgb25seSBuZWVkIHRvIHZlcmlmeSB0aGF0 IHlvdXIgYXBwbGljYXRpb24gaXMgc2VjdXJlIHVuZGVyIGFuIChpZGVhbGx5KSBzaGFyZWQgc2Vj cmV0IGtleS4NCg0KSSBhbSBzdXJlIHdlIGFsbCBhZ3JlZSB0aGF0IGNvbnNpZGVyaW5nIGZ1dHVy ZSBjaGFuZ2VzIHRvIHRoZSByZWNvcmQgbGF5ZXIsIGNoYW5nZXMgdG8gYXBwbGljYXRpb25zIHVz aW5nIHRoZSBoYW5kc2hha2UsIGV0YyBpcyBub3QgYSB0aGVvcmV0aWNhbCBjb25jZXJuLg0KVGhl IGxhc3QgdGhpbmcgeW91IHdhbnQgdG8gYXNzdW1lIGlzIHRoYXQgdGhlIFRMUyBlbnZpcm9ubWVu dCBhbmQgdGhlIHByb3RvY29sIGV2b2x1dGlvbiBpcyBzdGF0aWMuDQoNCkkgdGhpbmsgdGhhdCBh IGNvbnNlcnZhdGl2ZSB0YWtlIG9uIHRoaXMgaW1wb3J0YW50IHBvaW50IGlzIHRoZSByaWdodCB3 YXkgdG8gZ28uDQoNCkgNCuKAi3Vnb+KAiw0KDQoNCi1Dw6lkcmljLCB3aXRoIHRoZSBtaVRMUyB0 ZWFtDQoNCg0KSW4gdGhlIGZvbGxvd2luZywgSSBvbmx5IGNvbnNpZGVyIHRoZSByZWNvcmQgbGF5 ZXIga2V5cywgd2hpY2ggYXJlIHVzZWQgZm9yIGF1dGhlbnRpY2F0ZWQgZW5jcnlwdGlvbjsgSSBp Z25vcmUgYWxsIG90aGVyIGRlcml2ZWQga2V5IG1hdGVyaWFscy4gVGhlIFRMUyBsYXllcmVkIGRl c2lnbiBnb2VzIGFzIGZvbGxvd3M6DQotIFRoZSBoYW5kc2hha2UgcHJvdmlkZXMgZnJlc2gga2V5 cyB0byB0aGUgcmVjb3JkIGxheWVyIChkZXBlbmRpbmcgb24gaXRzIGludGVybmFsIHN0YXRlIG1h Y2hpbmUpIGFuZCBrZWVwcyBydW5uaW5nOw0KLSBUaGUgcmVjb3JkIGxheWVyIHVzZXMgdGhlIGN1 cnJlbnQga2V5cyBmb3IgZW5jcnlwdGluZyAqYWxsKiB0cmFmZmljLCBtaXhpbmcgaGFuZHNoYWtl IG1lc3NhZ2VzLCBhbGVydHMsIGFuZCBhcHBsaWNhdGlvbiBkYXRhIChvbmNlIGVuYWJsZWQpLg0K DQpUaGVzZSBrZXlzIGFyZSB1c2VkIHNlcXVlbnRpYWxseSwgYW5kIG9ubHkgYnkgdGhlIHJlY29y ZC1sYXllci4gVGhleSBhcmUgbm90IGRpcmVjdGx5IHVzZWQgd2l0aGluIHRoZSBoYW5kc2hha2Ug cHJvdG9jb2wgaXRzZWxmLCBvciBieSB0aGUgVExTIGFwcGxpY2F0aW9uLg0KLSBTaW5jZSB0aGUg c2VxdWVuY2Ugb2Yga2V5cyBpcyBtZWFudCB0byBwcm90ZWN0IHRoZSB3aG9sZSBzdHJlYW0gb2Yg VExTIGZyYWdtZW50cywgb25lIG5lZWRzIHRvIGF1dGhlbnRpY2F0ZSBlYWNoIHBvaW50IGluIHRo ZSBzdHJlYW0gd2hlcmUgdGhlcmUgaXMgYSBrZXkgY2hhbmdlLCB0byBwcmV2ZW50IGFueSB0cmFm ZmljIHRydW5jYXRpb24uIEFzIGRpc2N1c3NlZCBpbiBhbm90aGVyIHRocmVhZCwgd2UgYmVsaWV2 ZSB0aGlzIGlzIGNvcnJlY3RseSBoYW5kbGVkIGluIGRyYWZ0IzExLCBidXQgZWFjaCBrZXkgY2hh bmdlIHJlbWFpbnMgYSBzb3VyY2Ugb2YgY29tcGxpY2F0aW9uIFsxXS4NCi0gVGhlcmUgYXJlIGV4 Y2VsbGVudCByZWFzb25zIHRvIGNoYW5nZSBrZXlzIGJldHdlZW4gMC1SVFQgYW5kIDEtUlRUIChz dHJvbmdlciBrZXkgbWF0ZXJpYWxzLCBmb3J3YXJkIHNlY3JlY3kpLg0KLSBPdGhlcndpc2UsIHdo YXQgbWF0dGVycyBpcyB0aGUgcHJvdmVuYW5jZSBvZiB0aGUga2V5IChob3cgaXQgd2FzIGRlcml2 ZWQsIHdoYXQgaWRlbnRpdGllcyBhcmUgYXNzb2NpYXRlZCB3aXRoIGl0KSBhbmQgdGhlcmUgaXMg bm8gcG9pbnQgY2hhbmdpbmcga2V5cyB3aXRoIHRoZSBzYW1lIHByb3ZlbmFuY2UuDQoNClRoZSBz aXR1YXRpb24gaXMgcGFydGljdWxhcmx5IGNsZWFyIGluIDAtUlRUOiBpbiBkcmFmdCMxMSwgdGhl IGNsaWVudCBhbHdheXMgZGVyaXZlcyB0d28gcmVjb3JkLWxheWVyIGtleXMgZnJvbSB0aGUgc2Ft ZSBtYXRlcmlhbHMsIGFuZCB1c2VzIGVhY2ggb2YgdGhlc2Uga2V5cyBpbiB0dXJuIHRvIGVuY3J5 cHQgaGFsZiBvZiBpdHMgMC1SVFQgZmxpZ2h0LCB3aXRoIGEgRmluaXNoZWQgbWVzc2FnZSBpbi1i ZXR3ZWVuIHRoYXQgc2lnbmFscyB0aGUga2V5IGNoYW5nZS4gVGhpcyBrZXkgY2hhbmdlIGRvZXMg bm90IGRlZ3JhZGUgc2VjdXJpdHksIGJ1dCBzZWVtcyB1bm5lY2Vzc2FyeS4NCg0KSW4gMS1SVFQs IHRoaXMgaXMgbGVzcyBvYnZpb3VzIGJlY2F1c2UsIGluIGRyYWZ0IzExLCB0aGUgaGFuZHNoYWtl IGtleXMgYW5kIGFwcGxpY2F0aW9uLWRhdGEga2V5cyBhcmUgbm90IGV4YWN0bHkgZGVyaXZlZCBm cm9tIHRoZSBzYW1lIG1hdGVyaWFscy4gV2UgYmVsaWV2ZSB0aGlzIHNob3VsZCBiZSBmaXhlZCAo c2VlIHRoZSDigJxzaW1wbGlmaWVkIGtleSBzY2hlZHVsZeKAnSB0aHJlYWQpLiBUaGVuIHRoZSBz YW1lIGFyZ3VtZW50IGFwcGxpZXM6IHRoZSBrZXkgY2hhbmdlIGlzIG5vdCB0ZXJyaWJsZSwgYnV0 IGl0IGlzIGFuIHVubmVjZXNzYXJ5IGNvbXBsaWNhdGlvbi4NCg0KSSBkaXNhZ3JlZSB3aXRoIEh1 Z28gdGhhdCB1c2luZyB0aGUgc2FtZSByZWNvcmQtbGF5ZXIga2V5IGZvciBoYW5kc2hha2UgYW5k IGFwcGxpY2F0aW9uIGRhdGEgeWllbGRzIGEgcHJvb2Ygb2YgYSB3ZWFrZXIgZ3VhcmFudGVlLiBB cyBmYXIgYXMgSSBjYW4gdGVsbCwgdGhpcyBpcyBhIHRlY2huaWNhbGl0eSBpbiB0aGUgY3J5cHRv Z3JhcGhpYyBwcm9vZiBvZiB0aGUgaGFuZHNoYWtlLCBhbmQgd2Ugc3RpbGwgZ2V0IHRoZSBzYW1l IHNlY3VyaXR5IGd1YXJhbnRlZXMgZm9yIFRMUyB1c2VycyBbMl0uIEkgYWxzbyBsaWtlIHNpbXBs ZSBwcm9vZnMgb2YgZ2VuZXJpYyBzZWN1cml0eSBmb3IgdGhlIGhhbmRzaGFrZSBjb3JlLCBidXQg SSBkbyBub3Qgc2VlIGhvdyB0aGV5IGNhbiBjb3ZlciB0aGUgb3RoZXIgZmVhdHVyZXMgb2YgVExT IFtlLmcuIDMsIGFuZCBsYXRlIGhhbmRzaGFrZSBtZXNzYWdlc10gd2l0aCBvciB3aXRob3V0IHRo ZSBzaW1wbGlmaWNhdGlvbi4gR2l2ZW4gdGhlIGNob2ljZSBiZXR3ZWVuIGEgc2ltcGxlciBwcm90 b2NvbCB0aGF0IGl0IGlzIGVhc2llciB0byBpbXBsZW1lbnQgY29ycmVjdGx5LCBhbmQgc2ltcGxl ciBwcm9vZnMgZm9yIGEgY29yZSwgSSB3b3VsZCByYXRoZXIgc2ltcGxpZnkgdGhlIG92ZXJhbGwg cHJvdG9jb2wgYW5kIGRvIHRoZSBleHRyYSBwcm9vZiB3b3JrLg0KDQpPbmUgbWF5IGFyZ3VlIGFi b3V0IHdoYXQgd291bGQgaGFwcGVuIGlmIHNvbWUgb2YgdGhlIHJlY29yZC1sYXllciBrZXlzIHdl cmUgbWlzLXVzZWQsIGFnYWluc3QgdGhlIFRMUyBzcGVjaWZpY2F0aW9uIChkZXNwaXRlIGl0cyBl eHBvcnQgbWVjaGFuaXNtKSBhbmQgY29uY2x1ZGUgdGhhdCB3ZSBuZWVkIG1vcmUsIG5vdCBsZXNz IGtleSBjaGFuZ2VzIFszXS4gQnV0IEkgd291bGQgbm90IGNhbGwgaXQg4oCcYSBkaWZmZXJlbnQg YXBwbGljYXRpb27igJ0gYW5kIEkgYW0gc3RpbGwgdGVtcHRlZCB0byBzaW1wbGlmeSB0aGUga2V5 IHNjaGVkdWxlIGZvciBpdHMgaW50ZW5kZWQgdXNhZ2UgaW4gVExTLg0KDQoNClsxXSBBbiBhdHRh Y2tlciBtYXksIGZvciBpbnN0YW5jZSwgZGVsZXRlIHRoZSBsYXN0IGZyYWdtZW50IGVuY3J5cHRl ZCBiZWZvcmUgdGhlIGtleSBjaGFuZ2UuIFN1Y2ggYSBkZWxldGlvbiB3aWxsIGJlIGNhdWdodCBh dCB0aGUgcHJvdG9jb2wgbGF5ZXIsIGUuZy4gYmVjYXVzZSB0aGUgbGFzdCBmcmFnbWVudCBpcyBu b3QgYW4g4oCcZW5kX29mX2Vhcmx5X2RhdGHigJ0gYWxlcnQgb3IgYSBGaW5pc2hlZCBtZXNzYWdl LiBXaXRob3V0IHRoZSBrZXkgY2hhbmdlLCBhbnkgZGVsZXRpb24gd291bGQgYmUgY2F1Z2h0IGlt bWVkaWF0ZWx5LCBhcyB0aGUgbmV4dCBmcmFnbWVudCBkZWNyeXB0aW9uIGZhaWxzLg0KDQpbMl0g d2UgZG8gbm90IGhhdmUgYSBjb21wbGV0ZSBtb2RlbCBmb3IgVExTIDEuMyB5ZXQsIGJ1dCB3ZSBk ZXZlbG9wZWQgYSBkZXRhaWxlZCBtb2RlbCBmb3IgVExTIDEuMiBodHRwOi8vZXByaW50LmlhY3Iu b3JnLzIwMTQvMTgyPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHAlM2ElMmYlMmZlcHJpbnQuaWFjci5vcmclMmYyMDE0JTJmMTgyJmRhdGE9MDEl N2MwMSU3Y0ZPVVJORVQlNDAwNjRkLm1nZC5taWNyb3NvZnQuY29tJTdjMDY5NTNlZGM3YjEzNDNl YzU5MzcwOGQzMzk2NmRhODAlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3YzEm c2RhdGE9YUEwZTZvaFR1JTJiVThrbkR4MjNEb2xWTmsweENlJTJmZ2Y1MUhzUUU2akZUS1klM2Q+ IHNpbWlsYXJseSBjb3ZlcmluZyByZWNvcmQtbGF5ZXIga2V5IGNoYW5nZXMgKGZvciByZW5lZ290 aWF0aW9ucykgYW5kIHRoZSBmYWN0IHRoYXQgdGhvc2Uga2V5cyB3ZXJlIHVzZWQgdG8gcHJvdGVj dCB0aGUgRmluaXNoZWQgbWVzc2FnZXMgKmJlZm9yZSoga2V5IGNvbmZpcm1hdGlvbiBhbmQgYXBw bGljYXRpb24tZGF0YSB0cmFmZmljLiBUaGUgbWFpbiBkaWZmZXJlbmNlIHdpdGggY2xhc3NpYyBt b2RlbHMgZm9yIGtleSBleGNoYW5nZSwgd2hlcmUgdGhlIHByb3RvY29sIHJ1bnMgdG8gY29tcGxl dGlvbiBhbmQgcmV0dXJucyDigJx0aGXigJ0gYXBwbGljYXRpb24ga2V5LCBpcyB0aGF0IGluIG91 ciBtb2RlbCB0aGUgaG9uZXN0IGluc3RhbmNlcyBwcm92aWRlIGtleXMgZHVyaW5nIHRoZSBwcm90 b2NvbCBydW4uDQoNClszXSBhcyByZWNlbnRseSBkaXNjdXNzZWQgYXMgMC41LVJUVCwgdGhlIHNw ZWMgZW5hYmxlcyB0aGUgdXNlIG9mIDEtUlRUIGtleXMgYmVmb3JlIGNvbXBsZXRpbmcgdGhlIGhh bmRzaGFrZSwgd2l0aCB3ZWFrZXIgZ3VhcmFudGVlcyBvbiB0aGUgZW5jcnlwdGVkIGFwcGxpY2F0 aW9uIGRhdGEuIEhvd2V2ZXIsIGFuIGV4dHJhIGtleSBjaGFuZ2Ugd291bGQgcmVxdWlyZSBhZGRp dGlvbmFsIHNpZ25hbGxpbmcgbWVzc2FnZXMuDQoNCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9m IEVyaWMgUmVzY29ybGENClNlbnQ6IDE5IEZlYnJ1YXJ5IDIwMTYgMTQ6MTYNClRvOiBJbGFyaSBM aXVzdmFhcmEgPGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbTxtYWlsdG86aWxhcmlsaXVzdmFhcmFA d2VsaG8uY29tPj4NCkNjOiBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gPGthcnRoaWsuYmhhcmdhdmFu QGdtYWlsLmNvbTxtYWlsdG86a2FydGhpay5iaGFyZ2F2YW5AZ21haWwuY29tPj47IHRsc0BpZXRm Lm9yZzxtYWlsdG86dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIFByb3Bvc2FsOiBk b24ndCBjaGFuZ2Uga2V5cyBiZXR3ZWVuIGhhbmRzaGFrZSBhbmQgYXBwbGljYXRpb24gbGF5ZXIN Cg0KDQoNCk9uIEZyaSwgRmViIDE5LCAyMDE2IGF0IDM6NTggQU0sIElsYXJpIExpdXN2YWFyYSA8 aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29tPG1haWx0bzppbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20+ PiB3cm90ZToNCk9uIEZyaSwgRmViIDE5LCAyMDE2IGF0IDEwOjA0OjM4QU0gKzAxMDAsIEthcnRo aWtleWFuIEJoYXJnYXZhbiB3cm90ZToNCg0KPiBSZWdhcmRsZXNzIG9mIHdoZXRoZXIgd2UgbWFr ZSB0aGlzIGNoYW5nZSB0aG91Z2gsIEkgdGhpbmsgaXQgd291bGQgYmUNCj4gdXNlZnVsIGZvciB0 aGUgVExTIDEuMyBSRkMgdG8gY2xlYXJseSBsaW1pdCB0aGUgc2NvcGUgb2YgdmFyaW91cyBrZXlz DQo+IGdlbmVyYXRlZCBieSB0aGUgaGFuZHNoYWtlLiBEdXJpbmcgdGhlIGNvbm5lY3Rpb24gbGlm ZXRpbWUsIHdlIGdlbmVyYXRlDQo+IGEgc2VyaWVzIG9mIHJlY29yZCBlbmNyeXB0aW9uIGtleXM6 IGhhbmRzaGFrZSBhbmQgYXBwbGljYXRpb24ga2V5cyBmb3INCj4gMC1SVFQgYW5kIDEtUlRULCBh bmQgdGhlbiBhIHNlcXVlbmNlIG9mIGtleXMgZ2VuZXJhdGVkIGR1cmluZyByZWtleWluZy4NCj4g Tm9uZSBvZiB0aGVzZSBrZXlzIHNob3VsZCBiZSB1c2VkIG91dHNpZGUgdGhlaXIgaW50ZW5kZWQg dXNlIGNhc2VzIGluIGENCj4gc2luZ2xlIGNvbm5lY3Rpb24uICBUaGUgb25seSBjcm9zcy1jb25u ZWN0aW9uIHNlY3JldCBzcGVjaWZpZWQgaW4gdGhlDQo+IHByb3RvY29sIGlzIHRoZSByZXN1bXB0 aW9uIG1hc3RlciBzZWNyZXQsIGFuZCBpZiBhcHBsaWNhdGlvbnMgd2FudCBhDQo+IGtleSBmcm9t IFRMUyAxLjMsIHRoZXkgbXVzdCBvbmx5IHVzZSB0aGUgZXhwb3J0ZXIgbWFzdGVyIHNlY3JldC4g QWxsDQo+IG90aGVyIGtleXMgYXJlIGludGVybmFsIHRvIFRMUy4NCg0KSSB0aGluayBUTFMgMS4z IFJGQyBzaG91bGQgc3BlY2lmeSB3aGF0IHRoZSBwcm90b2NvbCBsb29rcyBsaWtlIGFuZCBob3cN Cml0IGNhbiBiZSB1c2VkIGZyb20gYXBwbGljYXRpb24gcGVyc3BlY3RpdmUuIFRoaXMgaW5jbHVk ZXMgc3BlY2lmeWluZw0Kd2hhdCBrZXlzIGNhbiBiZSBleHBvcnRlZCAoYW1vbmcgbWFueSBvdGhl ciB0aGluZ3MsIGxpa2UgaG93DQphdXRoZW50aWNhdGlvbiBjYW4gYmUgcGVyZm9ybWVkKS4NCg0K SSBhZ3JlZSB0aGF0IGV4cG9ydGluZyB0aGUgbWFpbiBlbmNyeXB0aW9uIGtleXMgb3Igc2VjcmV0 cyB0aG9zZSBhcmUNCmRlcml2ZWQgZnJvbSBmb3IgYW55IHB1cnBvc2UgaXMgYSByb3R0ZW4gaWRl YS4gSWYgeW91IG5lZWQga2V5aW5nIG9yDQphdXRoZW50aWNhdGlvbiBtYXRlcmlhbCwgdXNlIFRM UyBFWFBPUlRFUiAodGxzLXVuaXF1ZSBpcyBkZXByZWNhdGVkKQ0Kd2l0aCByZXF1aXJlbWVudCB0 byB1c2UgRU1TIG9uIHByaW9yIHZlcnNpb25zWzFdLg0KDQpUaGlzIGlzIHRoZSBpbnRlbnQuIEkg dGhpbmsgd2Ugd291bGQgYmUgd2VsbC1zZXJ2ZWQgdG8gc3RhdGUgdGhpcy4NCg0KDQpUaGVuIG9u ZSBtaWdodCBuZWVkIHRvIGV4cG9ydCBSTVMuIEkgdGhpbmsgaXQgc2hvdWxkIGJlIGV4cG9ydGVk IGFzDQpibG9iIHRoYXQgYWxzbyBjb250YWlucyBvdGhlciBhc3NvY2lhdGVkIGluZm9ybWF0aW9u IChlLmcgY2lwaGVyc3VpdGVzKS4NCkFuZCBwb3NzaWJseSBhbHNvIGVuY3J5cHRlZCwgdXNpbmcg c29tZSBNUkFFIGFsZ29yaXRobS4NCg0KDQoNClsxXSBDb21wYXRpYmxpdHkgaGFjazogT25lIG1p Z2h0IGNvbnNpZGVyIEVNUyBhbHdheXMgbmVnb3RpYXRlZCB3aGVuDQpUTFMgMS4zIGlzIG5lZ290 aWF0ZWQuIFRoaXMgY291bGQgcHJ2ZW50IGFwcGxpY2F0aW9ucyB0aGF0IGRvIGtub3cNCmFib3V0 IEVNUyBidXQgbm90IFRMUyAxLjMgZnJvbSBicmVha2luZyB3aGVuIHVwZ3JhZGluZyB0byBUTFMg MS4zLg0KDQpUaGF0IGlzLCBpZiBhcHBsaWNhdGlvbiBhc2tzIGFib3V0IFRMUyAxLjMgKFNlcnZl clZlcnNpb24gMy40KQ0KY29ubmVjdGlvbiAiaXMgRU1TIGVuYWJsZWQ/IiB0aGUgYW5zd2VyIHdp bGwgYmUgYWx3YXlzICJ5ZXMiDQooc2luY2UgdGhlIHBvaW50IG9mIHRoYXQgY2hlY2sgaXMgdG8g ZXhjbHVkZSBUSFMgYXR0YWNrcywgYW5kDQpUTFMgMS4zIGFscmVhZHkgZXhjbHVkZXMgdGhvc2Ug b24gYmFzZWxpbmUpLg0KDQpHb29kIHN1Z2dlc3Rpb24uIFRoaXMgaW4gZmFjdCBpcyB3aGF0IE5T UyBjdXJyZW50bHkgZG9lczoNCmh0dHBzOi8vZHhyLm1vemlsbGEub3JnL21vemlsbGEtY2VudHJh bC9zb3VyY2Uvc2VjdXJpdHkvbnNzL2xpYi9zc2wvc3NsaW5mby5jIzcwPGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmZHhyLm1v emlsbGEub3JnJTJmbW96aWxsYS1jZW50cmFsJTJmc291cmNlJTJmc2VjdXJpdHklMmZuc3MlMmZs aWIlMmZzc2wlMmZzc2xpbmZvLmMlMjM3MCZkYXRhPTAxJTdjMDElN2NGT1VSTkVUJTQwMDY0ZC5t Z2QubWljcm9zb2Z0LmNvbSU3Yzc2OTUxOWNkOTY3NTQxYzgzZTU4MDhkMzM5Mzc1OTI2JTdjNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJnNkYXRhPXlIVThBMVB4VjMwM0RGM2h4 TUxaMUJFUVJiR3FQZTFnamRucmpod1dIZTglM2Q+DQoNCi1Fa3INCg0KDQoNCg0KDQoNCg0KDQot SWxhcmkNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N ClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYub3JnPg0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8aHR0cHM6Ly9uYTAxLnNhZmVs aW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM2ElMmYlMmZ3d3cuaWV0Zi5v cmclMmZtYWlsbWFuJTJmbGlzdGluZm8lMmZ0bHMmZGF0YT0wMSU3YzAxJTdjRk9VUk5FVCU0MDA2 NGQubWdkLm1pY3Jvc29mdC5jb20lN2M3Njk1MTljZDk2NzU0MWM4M2U1ODA4ZDMzOTM3NTkyNiU3 YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZzZGF0YT1QUEY0SDd2JTJmdUdo bE5FMnIlMmJndFlZaHp0SnNDdnI5ZnRNTiUyZlByeGV2QnhRJTNkPg0KDQoNCg== --_000_4cfe8afe17a44ed096102aacf12dcbc3AM3PR30MB049064dmgdmsft_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpWZXJkYW5hOw0KCXBhbm9zZS0xOjIgMTEg NiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwg bGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29M aXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0K CXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0 OjBjbTsNCgltYXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2lu LWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNv bm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsN CgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjoj MUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNv bXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5XZSBoYXZlIHJhdGhlciBkaWZmZXJl bnQgdmlld3Mgb2YgdGhlIHByb3RvY29sLiBZb3Ugc2VlIHRoZSByZWNvcmQgbGF5ZXIgYXMgYSBz YW1wbGUgYXBwbGljYXRpb24gb3V0c2lkZSBUTFMsIHdoZXJlYXMgb3VyIG1vZGVsICh0aWVkDQog dG8gb3VyIGltcGxlbWVudGF0aW9uKSBjb21wb3NlcyB0aGUgaGFuZHNoYWtlIGFuZCB0aGUgcmVj b3JkLWxheWVyIHN1YnByb3RvY29scyB0byBnZXQgc2VjdXJpdHkgYXQgdGhlIFRMUyBBUEkuIFlv dSBhbHNvIHJlYXNvbiBhYm91dCDigJx0aGUgb3V0cHV0IHNlc3Npb24ga2V54oCdLCB3aGVyZWFz IHRoZSBoYW5kc2hha2Ugc3VjY2Vzc2l2ZWx5IHByb3ZpZGVzIGFsbCB0cmFmZmljIGtleXMgdG8g dGhlIHJlY29yZCBsYXllciBhbmQgdGhlbiBwcm92aWRlcw0KIGFuICZxdW90O2V4cG9ydGVyIHNl Y3JldCZxdW90OyB0byB0aGUgYXBwbGljYXRpb24uIEFjY29yZGluZ2x5LCB5b3UgYXNzdW1lIHRo ZSBoYW5kc2hha2UgZW5jcnlwdHMgaXRzIG93biBtZXNzYWdlcywgd2hlcmVhcyBUTFMgZGVsZWdh dGVzIHRoYXQgdGFzayB0byB0aGUgcmVjb3JkIGxheWVy4oCUc2VlIG15IHByZXZpb3VzIHBvc3Qg Zm9yIHRoZSBkZXRhaWxzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ SGVuY2UsIEkgdW5kZXJzdGFuZCB5b3VyIGdlbmVyYWwgYXJndW1lbnQsIGFuZCBJIHRoaW5rIGl0 IGFwcGxpZXMgcGVyZmVjdGx5IHRvIHRoZSAmcXVvdDtleHBvcnRlciBzZWNyZXQmcXVvdDssIGJ1 dCBub3QgdG8gdGhlIHByb3Bvc2VkIHNpbXBsaWZpY2F0aW9uDQogKGludm9sdmluZyB0d28gdHJh ZmZpYyBrZXlzIGludGVybmFsIHRvIFRMUywgc3VjY2Vzc2l2ZWx5IHVzZWQgYnkgdGhlIHNhbWUg cmVjb3JkLWxheWVyKSBhbmQgSSBkb27igJl0IHNlZSBob3cgdGhpcyBzaW1wbGlmaWNhdGlvbiB3 b3VsZCBjYXVzZSBhbnkgc2VjdXJpdHkgd2Vha2VuaW5nLg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj5CZXNpZGVzLCBpbiBvdXIgYW5hbHlzaXMgb2YgdGhlIGhhbmRz aGFrZSwgd2UgZ2V0IHByZWNpc2VseSB0aGUgc2FtZSDigJxmcmVzaCwgbmV2ZXItdXNlZCBzZWNy ZXTigJ0gcHJvcGVydHkgeW91IGFyZSBhZHZvY2F0aW5nLCB3aXRoIG9yDQogd2l0aG91dCB0aGUg c2ltcGxpZmljYXRpb24sIGVhY2ggdGltZSB0aGUgaGFuZHNoYWtlIHByb3ZpZGVzIGtleXMgdG8g dGhlIHJlY29yZCBsYXllci4gVGhlc2UgcG9pbnRzIGFyZSB3ZWxsLXNwZWNpZmllZCBhbmQgZGVs aW1pdGVkLiBUaGV5IGp1c3QgZG8gbm90IGNvaW5jaWRlIHdpdGggdGhlIGVuZCBvZiB0aGUgaGFu ZHNoYWtlLiBTbyBJIGRvbuKAmXQgc2VlIGFueSBmdW5kYW1lbnRhbCBkaWZmZXJlbmNlIGluIHRl cm0gb2YgZ2VuZXJpYy1zZWN1cml0eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPldlIGFyZSBsZWZ0IHdpdGggc2NlbmFyaW9zIHdoZXJlYnkgdGhlIHJlY29yZCBsYXll ciwgZ2l2ZW4gYm90aCB0aGUgaGFuZHNoYWtlIGFuZCBhcHBsaWNhdGlvbi1kYXRhIHRyYWZmaWMg a2V5cywgc29tZWhvdyBsZWFrcyBvbmx5DQogb25lIG9mIHRoZSB0d28uIEkgZG9u4oCZdCBtaW5k IGtlZXBpbmcgdGhlIGtleSBjaGFuZ2UgaWYgc29tZW9uZSBpcyBjb25jZXJuZWQgYWJvdXQgaXQu DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi1Dw6lkcmljPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0iX01haWxFbmRD b21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4NCjxzcGFuIHN0eWxlPSJt c28tYm9va21hcms6X01haWxFbmRDb21wb3NlIj48L3NwYW4+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IGh1Z29rcmF3QGdtYWlsLmNvbSBbbWFpbHRvOmh1Z29r cmF3QGdtYWlsLmNvbV0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+SHVnbyBLcmF3Y3p5azxicj4NCjxi PlNlbnQ6PC9iPiAxOSBGZWJydWFyeSAyMDE2IDE5OjU3PGJyPg0KPGI+VG86PC9iPiBDZWRyaWMg Rm91cm5ldCAmbHQ7Zm91cm5ldEBtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gRXJp YyBSZXNjb3JsYSAmbHQ7ZWtyQHJ0Zm0uY29tJmd0OzsgSWxhcmkgTGl1c3ZhYXJhICZsdDtpbGFy aWxpdXN2YWFyYUB3ZWxoby5jb20mZ3Q7OyBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gJmx0O2thcnRo aWsuYmhhcmdhdmFuQGdtYWlsLmNvbSZndDs7IHRsc0BpZXRmLm9yZzsgTWFya3VsZiBLb2hsd2Vp c3MgJmx0O21hcmt1bGZAbWljcm9zb2Z0LmNvbSZndDs7IEFudG9pbmUgRGVsaWduYXQtTGF2YXVk ICZsdDthbnRkbEBtaWNyb3NvZnQuY29tJmd0OzsgU2FudGlhZ28gWmFuZWxsYS1CZWd1ZWxpbg0K ICZsdDtzYW50aWFnb0BtaWNyb3NvZnQuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W1RMU10gUHJvcG9zYWw6IGRvbid0IGNoYW5nZSBrZXlzIGJldHdlZW4gaGFuZHNoYWtlIGFuZCBh cHBsaWNhdGlvbiBsYXllcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBGcmksIEZlYiAxOSwgMjAxNiBhdCAxMjo1OCBQTSwgQ2VkcmljIEZvdXJuZXQg Jmx0OzxhIGhyZWY9Im1haWx0bzpmb3VybmV0QG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5r Ij5mb3VybmV0QG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5BcyBwb2ludGVkIG91dCBieSBLYXJ0aGlrLCB3ZSBhcmUgbm90IHN0cm9uZ2x5IGFkdm9jYXRp bmcgdGhpcyBzaW1wbGlmaWNhdGlvbiwgYnV0IHdlIGRvIG5vdCB0aGluaw0KIGl0IHdvdWxkIHdl YWtlbiB0aGUgc2VjdXJpdHkgb2YgVExTLiBEZXRhaWxzIGJlbG93Ljwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZiI+SSBhbSBnbGFkIHlvdSBhcmUgbm90IHN0cm9uZ2x5IGFkdm9jYXRp bmcgdGhpcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj5JIHN0cm9uZ2x5IGFkdm9jYXRlIG5vdCB1c2luZyB0 aGUgYXBwbGljYXRpb24ga2V5cyB0byBwcm90ZWN0IGhhbmRzaGFrZSBtZXNzYWdlcy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90Oyxz YW5zLXNlcmlmIj5JIHdhbnQgYSB3ZWxsLWRlbGltaXRlZCBwb2ludCB3aGVyZSB0aGUgb3V0cHV0 IHNlc3Npb24ga2V5IGlzIGFzIGdvb2QgYXMgYSBmcmVzaCwgbmV2ZXItdXNlZCBzZWNyZXQga2V5 LCBhbmQgdGhhdCBzZXNzaW9uIGtleSBiZSB1c2VkIHRvIHByb3RlY3Qgc3Vic2VxdWVudCByZWNv cmQgbGF5ZXIgdHJhZmZpYy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+QXMgSSBzYWlkLCBJIGNhbm5vdCB3ZWln aCB0aGlzIGFnYWluc3QgaW1wbGVtZW50YXRpb24gYWR2YW50YWdlcyBvZiB0aGUgZnJlc2huZXNz LXZpb2xhdGlvbiBhcHByb2FjaDsgYnV0IHRoZXNlIGhhdmUgdG8gYmUgKnZlcnkqIHNpZ25pZmlj YW50IHRvIGJlIHdvcnRoIHRoZSBzZWN1cml0eSB3ZWFrZW5pbmcuJm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+QW5kIHllcywgSSB0aGluayB0aGlzIGlzIGEg c2VjdXJpdHkgd2Vha2VuaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+V2UgYXJlIHRhbGtpbmcgYWJvdXQgdHdvIGxl dmVscyBvZiBndWFyYW50ZWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPk9uZSwgd2hlcmUgdGhlIFRMUyBrZXkgZXhjaGFu Z2UgcHJvdG9jb2wgb3V0cHV0cyBhIHNlY3JldCBrZXkgdGhhdCBpcyBnb29kIGZvciAqYW55KiBh cHBsaWNhdGlvbiB0aGF0IHJlcXVpcmVzIHR3byBwYXJ0aWVzIHRvIHNoYXJlIGEgc2VjcmV0IGtl eS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFu YSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgb3RoZXIsIHdoZXJlIHRoZSB1c2Ugb2YgdGhlIGtleSBw cm9kdWNlZCBieSB0aGlzIHByb3RvY29sIGlzIHNlY3VyZSBlbm91Z2ggZm9yIGEgKnNwZWNpZmlj KiBhcHBsaWNhdGlvbiwgbmFtZWx5LCBUTFMgcmVjb3JkIGxheWVyIChhdCBsZWFzdCBpbiBpdHMg Y3VycmVudCBkZWZpbml0aW9uKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNl cmlmIj5UaGUgc2Vjb25kIGlzIGNsZWFybHkgd2Vha2VyLiBJdCBoYXMgYSBtb3JlIGxpbWl0ZWQg KHNlY3VyZSkgdXNlIHNjb3BlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPkZvciBleGFtcGxlLCBpdCBtZWFu cyB0aGF0IGNoYW5nZXMgdG8gdGhlIHJlY29yZCBsYXllciBwcm90b2NvbCBjb3VsZCByZXF1aXJl IGEgcmUtYXNzZXNzbWVudCBvZiB0aGUgc2VjdXJpdHkgb2YgdGhlIGhhbmRzaGFrZSwgYW5kIGNl cnRhaW5seSB0aGlzIGlzIHRoZSBjYXNlIGZvciBhIGRpZmZlcmVudCBhcHBsaWNhdGlvbiB0aGF0 DQogc29tZWhvdyBtb2RpZmllcyB0aGUgcmVjb3JkIGxheWVyIG9yIG1ha2VzIGFzc3VtcHRpb25z IGRpZmZlcmVudCB0aGFuIHRoZSBpbnRlbmRlZCB1c2Ugb2YgdGhlIHJlY29yZCBsYXllci48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90 OyxzYW5zLXNlcmlmIj5XaXRoIGEgJnF1b3Q7Z2VuZXJpY2FsbHkgc2VjdXJlJnF1b3Q7IGhhbmRz aGFrZSB0aGlzIHJlYXNzZXNzbWVudCBvZiB0aGUgaGFuZHNoYWtlIHdvdWxkIG5vdCBiZSBuZWVk ZWQsIHlvdSB3b3VsZCBvbmx5IG5lZWQgdG8gdmVyaWZ5IHRoYXQgeW91ciBhcHBsaWNhdGlvbiBp cyBzZWN1cmUgdW5kZXIgYW4gKGlkZWFsbHkpIHNoYXJlZCBzZWNyZXQNCiBrZXkuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fu cy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1ZlcmRhbmEmcXVvdDssc2Fucy1zZXJpZiI+SSBhbSBzdXJlIHdlIGFsbCBhZ3JlZSB0 aGF0IGNvbnNpZGVyaW5nIGZ1dHVyZSBjaGFuZ2VzIHRvIHRoZSByZWNvcmQgbGF5ZXIsIGNoYW5n ZXMgdG8gYXBwbGljYXRpb25zIHVzaW5nIHRoZSBoYW5kc2hha2UsIGV0YyBpcyBub3QgYSB0aGVv cmV0aWNhbCBjb25jZXJuLiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEm cXVvdDssc2Fucy1zZXJpZiI+VGhlIGxhc3QgdGhpbmcgeW91IHdhbnQgdG8gYXNzdW1lIGlzIHRo YXQgdGhlIFRMUyBlbnZpcm9ubWVudCBhbmQgdGhlIHByb3RvY29sIGV2b2x1dGlvbiBpcyBzdGF0 aWMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1ZlcmRhbmEmcXVv dDssc2Fucy1zZXJpZiI+SSB0aGluayB0aGF0IGEgY29uc2VydmF0aXZlIHRha2Ugb24gdGhpcyBp bXBvcnRhbnQgcG9pbnQgaXMgdGhlIHJpZ2h0IHdheSB0byBnby48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VmVyZGFuYSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkg8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp ZiI+4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtWZXJkYW5hJnF1b3Q7 LHNhbnMtc2VyaWYiPnVnbzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZiI+4oCLPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtWZXJkYW5hJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4tQ8OpZHJpYywg d2l0aCB0aGUgbWlUTFMgdGVhbTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkluIHRoZSBmb2xsb3dpbmcsIEkg b25seSBjb25zaWRlciB0aGUgcmVjb3JkIGxheWVyIGtleXMsIHdoaWNoIGFyZSB1c2VkIGZvciBh dXRoZW50aWNhdGVkIGVuY3J5cHRpb247DQogSSBpZ25vcmUgYWxsIG90aGVyIGRlcml2ZWQga2V5 IG1hdGVyaWFscy4gVGhlIFRMUyBsYXllcmVkIGRlc2lnbiBnb2VzIGFzIGZvbGxvd3M6PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+LSBUaGUgaGFuZHNoYWtlIHByb3ZpZGVzIGZyZXNoIGtleXMgdG8gdGhl IHJlY29yZCBsYXllciAoZGVwZW5kaW5nIG9uIGl0cyBpbnRlcm5hbCBzdGF0ZSBtYWNoaW5lKSBh bmQNCiBrZWVwcyBydW5uaW5nOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPi0gVGhlIHJlY29yZCBsYXll ciB1c2VzIHRoZSBjdXJyZW50IGtleXMgZm9yIGVuY3J5cHRpbmcgKmFsbCogdHJhZmZpYywgbWl4 aW5nIGhhbmRzaGFrZSBtZXNzYWdlcywgYWxlcnRzLA0KIGFuZCBhcHBsaWNhdGlvbiBkYXRhIChv bmNlIGVuYWJsZWQpLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPlRoZXNlIGtleXMgYXJlIHVzZWQgc2VxdWVudGlhbGx5LCBhbmQgb25seSBieSB0aGUgcmVj b3JkLWxheWVyLiBUaGV5IGFyZSBub3QgZGlyZWN0bHkgdXNlZCB3aXRoaW4gdGhlDQogaGFuZHNo YWtlIHByb3RvY29sIGl0c2VsZiwgb3IgYnkgdGhlIFRMUyBhcHBsaWNhdGlvbi4gPC9zcGFuPjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+LSBTaW5jZSB0aGUgc2VxdWVuY2Ugb2Yga2V5cyBpcyBtZWFudCB0byBwcm90 ZWN0IHRoZSB3aG9sZSBzdHJlYW0gb2YgVExTIGZyYWdtZW50cywgb25lIG5lZWRzIHRvIGF1dGhl bnRpY2F0ZQ0KIGVhY2ggcG9pbnQgaW4gdGhlIHN0cmVhbSB3aGVyZSB0aGVyZSBpcyBhIGtleSBj aGFuZ2UsIHRvIHByZXZlbnQgYW55IHRyYWZmaWMgdHJ1bmNhdGlvbi4gQXMgZGlzY3Vzc2VkIGlu IGFub3RoZXIgdGhyZWFkLCB3ZSBiZWxpZXZlIHRoaXMgaXMgY29ycmVjdGx5IGhhbmRsZWQgaW4g ZHJhZnQjMTEsIGJ1dCBlYWNoIGtleSBjaGFuZ2UgcmVtYWlucyBhIHNvdXJjZSBvZiBjb21wbGlj YXRpb24gWzFdLg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LSBUaGVyZSBhcmUgZXhjZWxsZW50IHJl YXNvbnMgdG8gY2hhbmdlIGtleXMgYmV0d2VlbiAwLVJUVCBhbmQgMS1SVFQgKHN0cm9uZ2VyIGtl eSBtYXRlcmlhbHMsIGZvcndhcmQNCiBzZWNyZWN5KS4gPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+LSBP dGhlcndpc2UsIHdoYXQgbWF0dGVycyBpcyB0aGUgcHJvdmVuYW5jZSBvZiB0aGUga2V5IChob3cg aXQgd2FzIGRlcml2ZWQsIHdoYXQgaWRlbnRpdGllcyBhcmUgYXNzb2NpYXRlZA0KIHdpdGggaXQp IGFuZCB0aGVyZSBpcyBubyBwb2ludCBjaGFuZ2luZyBrZXlzIHdpdGggdGhlIHNhbWUgcHJvdmVu YW5jZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUg c2l0dWF0aW9uIGlzIHBhcnRpY3VsYXJseSBjbGVhciBpbiAwLVJUVDogaW4gZHJhZnQjMTEsIHRo ZSBjbGllbnQgYWx3YXlzIGRlcml2ZXMgdHdvIHJlY29yZC1sYXllcg0KIGtleXMgZnJvbSB0aGUg c2FtZSBtYXRlcmlhbHMsIGFuZCB1c2VzIGVhY2ggb2YgdGhlc2Uga2V5cyBpbiB0dXJuIHRvIGVu Y3J5cHQgaGFsZiBvZiBpdHMgMC1SVFQgZmxpZ2h0LCB3aXRoIGEgRmluaXNoZWQgbWVzc2FnZSBp bi1iZXR3ZWVuIHRoYXQgc2lnbmFscyB0aGUga2V5IGNoYW5nZS4gVGhpcyBrZXkgY2hhbmdlIGRv ZXMgbm90IGRlZ3JhZGUgc2VjdXJpdHksIGJ1dCBzZWVtcyB1bm5lY2Vzc2FyeS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JbiAxLVJUVCwgdGhpcyBpcyBs ZXNzIG9idmlvdXMgYmVjYXVzZSwgaW4gZHJhZnQjMTEsIHRoZSBoYW5kc2hha2Uga2V5cyBhbmQg YXBwbGljYXRpb24tZGF0YSBrZXlzIGFyZQ0KIG5vdCBleGFjdGx5IGRlcml2ZWQgZnJvbSB0aGUg c2FtZSBtYXRlcmlhbHMuIFdlIGJlbGlldmUgdGhpcyBzaG91bGQgYmUgZml4ZWQgKHNlZSB0aGUg 4oCcc2ltcGxpZmllZCBrZXkgc2NoZWR1bGXigJ0gdGhyZWFkKS4gVGhlbiB0aGUgc2FtZSBhcmd1 bWVudCBhcHBsaWVzOiB0aGUga2V5IGNoYW5nZSBpcyBub3QgdGVycmlibGUsIGJ1dCBpdCBpcyBh biB1bm5lY2Vzc2FyeSBjb21wbGljYXRpb24uDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JIGRpc2FncmVlIHdpdGggSHVnbyB0aGF0IHVzaW5nIHRoZSBz YW1lIHJlY29yZC1sYXllciBrZXkgZm9yIGhhbmRzaGFrZSBhbmQgYXBwbGljYXRpb24gZGF0YSB5 aWVsZHMNCiBhIHByb29mIG9mIGEgd2Vha2VyIGd1YXJhbnRlZS4gQXMgZmFyIGFzIEkgY2FuIHRl bGwsIHRoaXMgaXMgYSB0ZWNobmljYWxpdHkgaW4gdGhlIGNyeXB0b2dyYXBoaWMgcHJvb2Ygb2Yg dGhlIGhhbmRzaGFrZSwgYW5kIHdlIHN0aWxsIGdldCB0aGUgc2FtZSBzZWN1cml0eSBndWFyYW50 ZWVzIGZvciBUTFMgdXNlcnMgWzJdLiBJIGFsc28gbGlrZSBzaW1wbGUgcHJvb2ZzIG9mIGdlbmVy aWMgc2VjdXJpdHkgZm9yIHRoZSBoYW5kc2hha2UgY29yZSwNCiBidXQgSSBkbyBub3Qgc2VlIGhv dyB0aGV5IGNhbiBjb3ZlciB0aGUgb3RoZXIgZmVhdHVyZXMgb2YgVExTIFtlLmcuIDMsIGFuZCBs YXRlIGhhbmRzaGFrZSBtZXNzYWdlc10gd2l0aCBvciB3aXRob3V0IHRoZSBzaW1wbGlmaWNhdGlv bi4gR2l2ZW4gdGhlIGNob2ljZSBiZXR3ZWVuIGEgc2ltcGxlciBwcm90b2NvbCB0aGF0IGl0IGlz IGVhc2llciB0byBpbXBsZW1lbnQgY29ycmVjdGx5LCBhbmQgc2ltcGxlciBwcm9vZnMgZm9yIGEg Y29yZSwgSSB3b3VsZA0KIHJhdGhlciBzaW1wbGlmeSB0aGUgb3ZlcmFsbCBwcm90b2NvbCBhbmQg ZG8gdGhlIGV4dHJhIHByb29mIHdvcmsuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+T25lIG1heSBhcmd1ZSBhYm91dCB3aGF0IHdvdWxkIGhhcHBlbiBpZiBz b21lIG9mIHRoZSByZWNvcmQtbGF5ZXIga2V5cyB3ZXJlIG1pcy11c2VkLCBhZ2FpbnN0IHRoZSBU TFMNCiBzcGVjaWZpY2F0aW9uIChkZXNwaXRlIGl0cyBleHBvcnQgbWVjaGFuaXNtKSBhbmQgY29u Y2x1ZGUgdGhhdCB3ZSBuZWVkIG1vcmUsIG5vdCBsZXNzIGtleSBjaGFuZ2VzIFszXS4gQnV0IEkg d291bGQgbm90IGNhbGwgaXQg4oCcYSBkaWZmZXJlbnQgYXBwbGljYXRpb27igJ0gYW5kIEkgYW0g c3RpbGwgdGVtcHRlZCB0byBzaW1wbGlmeSB0aGUga2V5IHNjaGVkdWxlIGZvciBpdHMgaW50ZW5k ZWQgdXNhZ2UgaW4gVExTLiZuYnNwOw0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+WzFdIEFuIGF0dGFja2Vy IG1heSwgZm9yIGluc3RhbmNlLCBkZWxldGUgdGhlIGxhc3QgZnJhZ21lbnQgZW5jcnlwdGVkIGJl Zm9yZSB0aGUga2V5IGNoYW5nZS4gU3VjaCBhDQogZGVsZXRpb24gd2lsbCBiZSBjYXVnaHQgYXQg dGhlIHByb3RvY29sIGxheWVyLCBlLmcuIGJlY2F1c2UgdGhlIGxhc3QgZnJhZ21lbnQgaXMgbm90 IGFuIOKAnGVuZF9vZl9lYXJseV9kYXRh4oCdIGFsZXJ0IG9yIGEgRmluaXNoZWQgbWVzc2FnZS4g V2l0aG91dCB0aGUga2V5IGNoYW5nZSwgYW55IGRlbGV0aW9uIHdvdWxkIGJlIGNhdWdodCBpbW1l ZGlhdGVseSwgYXMgdGhlIG5leHQgZnJhZ21lbnQgZGVjcnlwdGlvbiBmYWlscy48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bMl0gd2UgZG8gbm90IGhhdmUg YSBjb21wbGV0ZSBtb2RlbCBmb3IgVExTIDEuMyB5ZXQsIGJ1dCB3ZSBkZXZlbG9wZWQgYSBkZXRh aWxlZCBtb2RlbCBmb3IgVExTIDEuMg0KPC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHAlM2ElMmYlMmZlcHJpbnQuaWFj ci5vcmclMmYyMDE0JTJmMTgyJmFtcDtkYXRhPTAxJTdjMDElN2NGT1VSTkVUJTQwMDY0ZC5tZ2Qu bWljcm9zb2Z0LmNvbSU3YzA2OTUzZWRjN2IxMzQzZWM1OTM3MDhkMzM5NjZkYTgwJTdjNzJmOTg4 YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1hQTBlNm9oVHUlMmJVOGtu RHgyM0RvbFZOazB4Q2UlMmZnZjUxSHNRRTZqRlRLWSUzZCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+aHR0cDovL2VwcmludC5pYWNyLm9yZy8yMDE0LzE4Mjwvc3Bhbj48L2E+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPg0KIHNpbWlsYXJseSBjb3ZlcmluZyByZWNvcmQt bGF5ZXIga2V5IGNoYW5nZXMgKGZvciByZW5lZ290aWF0aW9ucykgYW5kIHRoZSBmYWN0IHRoYXQg dGhvc2Uga2V5cyB3ZXJlIHVzZWQgdG8gcHJvdGVjdCB0aGUgRmluaXNoZWQgbWVzc2FnZXMgKmJl Zm9yZSoga2V5IGNvbmZpcm1hdGlvbiBhbmQgYXBwbGljYXRpb24tZGF0YSB0cmFmZmljLiBUaGUg bWFpbiBkaWZmZXJlbmNlIHdpdGggY2xhc3NpYyBtb2RlbHMgZm9yIGtleSBleGNoYW5nZSwgd2hl cmUNCiB0aGUgcHJvdG9jb2wgcnVucyB0byBjb21wbGV0aW9uIGFuZCByZXR1cm5zIOKAnHRoZeKA nSBhcHBsaWNhdGlvbiBrZXksIGlzIHRoYXQgaW4gb3VyIG1vZGVsIHRoZSBob25lc3QgaW5zdGFu Y2VzIHByb3ZpZGUga2V5cyBkdXJpbmcgdGhlIHByb3RvY29sIHJ1bi4NCjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlszXSBhcyByZWNlbnRseSBkaXNjdXNz ZWQgYXMgMC41LVJUVCwgdGhlIHNwZWMgZW5hYmxlcyB0aGUgdXNlIG9mIDEtUlRUIGtleXMgYmVm b3JlIGNvbXBsZXRpbmcgdGhlDQogaGFuZHNoYWtlLCB3aXRoIHdlYWtlciBndWFyYW50ZWVzIG9u IHRoZSBlbmNyeXB0ZWQgYXBwbGljYXRpb24gZGF0YS4gSG93ZXZlciwgYW4gZXh0cmEga2V5IGNo YW5nZSB3b3VsZCByZXF1aXJlIGFkZGl0aW9uYWwgc2lnbmFsbGluZyBtZXNzYWdlcy48L3NwYW4+ PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxhIG5hbWU9Ii0zMzMwOTg0NzJfX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJv bTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMNCiBbbWFpbHRv Ojwvc3Bhbj48YSBocmVmPSJtYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj50bHMtYm91bmNlc0BpZXRmLm9yZzwv c3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+XQ0KPGI+T24gQmVoYWxmIE9m IDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2VudDo8L2I+IDE5IEZlYnJ1YXJ5IDIwMTYgMTQ6 MTY8YnI+DQo8Yj5Ubzo8L2I+IElsYXJpIExpdXN2YWFyYSAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1h aWx0bzppbGFyaWxpdXN2YWFyYUB3ZWxoby5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj5pbGFyaWxpdXN2YWFyYUB3ZWxoby5jb208L3NwYW4+PC9hPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQo8Yj5DYzo8L2I+IEthcnRoaWtl eWFuIEJoYXJnYXZhbiAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzprYXJ0aGlrLmJoYXJnYXZh bkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5rYXJ0aGlrLmJoYXJnYXZhbkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDs7DQo8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnRsc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPnRsc0BpZXRmLm9y Zzwvc3Bhbj48L2E+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPGI+U3ViamVj dDo8L2I+IFJlOiBbVExTXSBQcm9wb3NhbDogZG9uJ3QgY2hhbmdlIGtleXMgYmV0d2VlbiBoYW5k c2hha2UgYW5kIGFwcGxpY2F0aW9uIGxheWVyPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgRmViIDE5LCAyMDE2IGF0IDM6NTggQU0sIElsYXJp IExpdXN2YWFyYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbSIg dGFyZ2V0PSJfYmxhbmsiPmlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbTwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207bWFyZ2luLWJvdHRvbTo1 LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk9uIEZyaSwgRmViIDE5LCAyMDE2IGF0IDEw OjA0OjM4QU0gJiM0MzswMTAwLCBLYXJ0aGlrZXlhbiBCaGFyZ2F2YW4gd3JvdGU6PGJyPg0KPGJy Pg0KJmd0OyBSZWdhcmRsZXNzIG9mIHdoZXRoZXIgd2UgbWFrZSB0aGlzIGNoYW5nZSB0aG91Z2gs IEkgdGhpbmsgaXQgd291bGQgYmU8YnI+DQomZ3Q7IHVzZWZ1bCBmb3IgdGhlIFRMUyAxLjMgUkZD IHRvIGNsZWFybHkgbGltaXQgdGhlIHNjb3BlIG9mIHZhcmlvdXMga2V5czxicj4NCiZndDsgZ2Vu ZXJhdGVkIGJ5IHRoZSBoYW5kc2hha2UuIER1cmluZyB0aGUgY29ubmVjdGlvbiBsaWZldGltZSwg d2UgZ2VuZXJhdGU8YnI+DQomZ3Q7IGEgc2VyaWVzIG9mIHJlY29yZCBlbmNyeXB0aW9uIGtleXM6 IGhhbmRzaGFrZSBhbmQgYXBwbGljYXRpb24ga2V5cyBmb3I8YnI+DQomZ3Q7IDAtUlRUIGFuZCAx LVJUVCwgYW5kIHRoZW4gYSBzZXF1ZW5jZSBvZiBrZXlzIGdlbmVyYXRlZCBkdXJpbmcgcmVrZXlp bmcuPGJyPg0KJmd0OyBOb25lIG9mIHRoZXNlIGtleXMgc2hvdWxkIGJlIHVzZWQgb3V0c2lkZSB0 aGVpciBpbnRlbmRlZCB1c2UgY2FzZXMgaW4gYTxicj4NCiZndDsgc2luZ2xlIGNvbm5lY3Rpb24u Jm5ic3A7IFRoZSBvbmx5IGNyb3NzLWNvbm5lY3Rpb24gc2VjcmV0IHNwZWNpZmllZCBpbiB0aGU8 YnI+DQomZ3Q7IHByb3RvY29sIGlzIHRoZSByZXN1bXB0aW9uIG1hc3RlciBzZWNyZXQsIGFuZCBp ZiBhcHBsaWNhdGlvbnMgd2FudCBhPGJyPg0KJmd0OyBrZXkgZnJvbSBUTFMgMS4zLCB0aGV5IG11 c3Qgb25seSB1c2UgdGhlIGV4cG9ydGVyIG1hc3RlciBzZWNyZXQuIEFsbDxicj4NCiZndDsgb3Ro ZXIga2V5cyBhcmUgaW50ZXJuYWwgdG8gVExTLjxicj4NCjxicj4NCkkgdGhpbmsgVExTIDEuMyBS RkMgc2hvdWxkIHNwZWNpZnkgd2hhdCB0aGUgcHJvdG9jb2wgbG9va3MgbGlrZSBhbmQgaG93PGJy Pg0KaXQgY2FuIGJlIHVzZWQgZnJvbSBhcHBsaWNhdGlvbiBwZXJzcGVjdGl2ZS4gVGhpcyBpbmNs dWRlcyBzcGVjaWZ5aW5nPGJyPg0Kd2hhdCBrZXlzIGNhbiBiZSBleHBvcnRlZCAoYW1vbmcgbWFu eSBvdGhlciB0aGluZ3MsIGxpa2UgaG93PGJyPg0KYXV0aGVudGljYXRpb24gY2FuIGJlIHBlcmZv cm1lZCkuPGJyPg0KPGJyPg0KSSBhZ3JlZSB0aGF0IGV4cG9ydGluZyB0aGUgbWFpbiBlbmNyeXB0 aW9uIGtleXMgb3Igc2VjcmV0cyB0aG9zZSBhcmU8YnI+DQpkZXJpdmVkIGZyb20gZm9yIGFueSBw dXJwb3NlIGlzIGEgcm90dGVuIGlkZWEuIElmIHlvdSBuZWVkIGtleWluZyBvcjxicj4NCmF1dGhl bnRpY2F0aW9uIG1hdGVyaWFsLCB1c2UgVExTIEVYUE9SVEVSICh0bHMtdW5pcXVlIGlzIGRlcHJl Y2F0ZWQpPGJyPg0Kd2l0aCByZXF1aXJlbWVudCB0byB1c2UgRU1TIG9uIHByaW9yIHZlcnNpb25z WzFdLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPlRoaXMgaXMgdGhlIGludGVudC4gSSB0aGluayB3ZSB3b3VsZCBiZSB3ZWxs LXNlcnZlZCB0byBzdGF0ZSB0aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGVuIG9uZSBtaWdodCBuZWVkIHRvIGV4cG9ydCBSTVMuIEkgdGhpbmsg aXQgc2hvdWxkIGJlIGV4cG9ydGVkIGFzPGJyPg0KYmxvYiB0aGF0IGFsc28gY29udGFpbnMgb3Ro ZXIgYXNzb2NpYXRlZCBpbmZvcm1hdGlvbiAoZS5nIGNpcGhlcnN1aXRlcykuPGJyPg0KQW5kIHBv c3NpYmx5IGFsc28gZW5jcnlwdGVkLCB1c2luZyBzb21lIE1SQUUgYWxnb3JpdGhtLjxicj4NCjxi cj4NCjxicj4NCjxicj4NClsxXSBDb21wYXRpYmxpdHkgaGFjazogT25lIG1pZ2h0IGNvbnNpZGVy IEVNUyBhbHdheXMgbmVnb3RpYXRlZCB3aGVuPGJyPg0KVExTIDEuMyBpcyBuZWdvdGlhdGVkLiBU aGlzIGNvdWxkIHBydmVudCBhcHBsaWNhdGlvbnMgdGhhdCBkbyBrbm93PGJyPg0KYWJvdXQgRU1T IGJ1dCBub3QgVExTIDEuMyBmcm9tIGJyZWFraW5nIHdoZW4gdXBncmFkaW5nIHRvIFRMUyAxLjMu PGJyPg0KPGJyPg0KVGhhdCBpcywgaWYgYXBwbGljYXRpb24gYXNrcyBhYm91dCBUTFMgMS4zIChT ZXJ2ZXJWZXJzaW9uIDMuNCk8YnI+DQpjb25uZWN0aW9uICZxdW90O2lzIEVNUyBlbmFibGVkPyZx dW90OyB0aGUgYW5zd2VyIHdpbGwgYmUgYWx3YXlzICZxdW90O3llcyZxdW90Ozxicj4NCihzaW5j ZSB0aGUgcG9pbnQgb2YgdGhhdCBjaGVjayBpcyB0byBleGNsdWRlIFRIUyBhdHRhY2tzLCBhbmQ8 YnI+DQpUTFMgMS4zIGFscmVhZHkgZXhjbHVkZXMgdGhvc2Ugb24gYmFzZWxpbmUpLjxvOnA+PC9v OnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pkdvb2Qgc3VnZ2VzdGlvbi4gVGhpcyBpbiBmYWN0IGlzIHdoYXQgTlNTIGN1cnJlbnRseSBkb2Vz OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3Vy bD1odHRwcyUzYSUyZiUyZmR4ci5tb3ppbGxhLm9yZyUyZm1vemlsbGEtY2VudHJhbCUyZnNvdXJj ZSUyZnNlY3VyaXR5JTJmbnNzJTJmbGliJTJmc3NsJTJmc3NsaW5mby5jJTIzNzAmYW1wO2RhdGE9 MDElN2MwMSU3Y0ZPVVJORVQlNDAwNjRkLm1nZC5taWNyb3NvZnQuY29tJTdjNzY5NTE5Y2Q5Njc1 NDFjODNlNTgwOGQzMzkzNzU5MjYlN2M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 YzEmYW1wO3NkYXRhPXlIVThBMVB4VjMwM0RGM2h4TUxaMUJFUVJiR3FQZTFnamRucmpod1dIZTgl M2QiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2R4ci5tb3ppbGxhLm9yZy9tb3ppbGxhLWNlbnRy YWwvc291cmNlL3NlY3VyaXR5L25zcy9saWIvc3NsL3NzbGluZm8uYyM3MDwvYT48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi1Fa3I8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBj bSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDow Y207bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2 LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowY207 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxl PSJjb2xvcjojODg4ODg4Ij48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQotSWxhcmk8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpUTFMg bWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9y ZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyZhbXA7ZGF0YT0wMSU3YzAxJTdjRk9VUk5FVCU0 MDA2NGQubWdkLm1pY3Jvc29mdC5jb20lN2M3Njk1MTljZDk2NzU0MWM4M2U1ODA4ZDMzOTM3NTky NiU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdjMSZhbXA7c2RhdGE9UFBGNEg3 diUyZnVHaGxORTJyJTJiZ3RZWWh6dEpzQ3ZyOWZ0TU4lMmZQcnhldkJ4USUzZCIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_4cfe8afe17a44ed096102aacf12dcbc3AM3PR30MB049064dmgdmsft_-- From nobody Sat Feb 20 11:59:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B0A01AD0EA for ; Sat, 20 Feb 2016 11:59:19 -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, SPF_HELO_PASS=-0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UlBHUdEHuIPO for ; Sat, 20 Feb 2016 11:59:16 -0800 (PST) Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0631.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::631]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0592E1AD16B for ; Sat, 20 Feb 2016 11:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9gbIYJw5ep6NpnbuXPxBSL4Jrs36K5eD/ZApNuHe0r0=; b=dvmayJ0ozIz6XIhUetqL318jtn80b/3M7MdXiWiZgaHoRNSBHX0j0HAgY1Zs3UOae9i1LUvCfcYYm+qPajNql5bp+pxf6PuxJ/DUFemyRjyrYPJpipTZ6yvKlmCeUf5KSeTL4xIxODyTzrOgm/ASeVuOiYPq/wD0CTOnpDvzf+w= Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 19:58:54 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0409.022; Sat, 20 Feb 2016 19:58:54 +0000 From: "Paterson, Kenny" To: Cedric Fournet , Hugo Krawczyk Thread-Topic: [TLS] Proposal: don't change keys between handshake and application layer Thread-Index: AQHRallUDdODj83lLkuzfZ3i8yNhJp8x48sAgAAfHgCAARGDAIAAH+mAgAA3KwCAAD4SAIAAIQIAgAGAxACAABIDAA== Date: Sat, 20 Feb 2016 19:58:53 +0000 Message-ID: References: <20160219105851.GA14585@LK-Perkele-V2.elisa-laajakaista.fi> <4cfe8afe17a44ed096102aacf12dcbc3@AM3PR30MB049.064d.mgd.msft.net> In-Reply-To: <4cfe8afe17a44ed096102aacf12dcbc3@AM3PR30MB049.064d.mgd.msft.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 authentication-results: microsoft.com; dkim=none (message not signed) header.d=none;microsoft.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [67.52.140.5] x-microsoft-exchange-diagnostics: 1; DBXPR03MB383; 5:+8ZpTtBtGbj0GeQZmQ5LCCMqkXTgXZnNYxjDaMU4RnKSdh5A0/g8M5TLCqtVHjMuYFL1kpnXZ9Yf8I9r7HFC9s5G+3YdaD+zcM61BVHZxqY/7SZRgk1dRYibHAi3O6q2SOcR72CD3iXZEhu/tiXz6g==; 24:FDrZqChlrtZ6GLX4vISxsRT8m73pWmWMPkiTUTOmO3dxeJEpweIqzZEXLxG/OaN+hGgh0p0BdsPUIvp8sQxa9ExzjR2N5Tsn+ArwIcPvlIo= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB383; x-ms-office365-filtering-correlation-id: ed68df06-e859-4eff-417f-08d33a3042a1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DBXPR03MB383; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB383; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(24454002)(479174004)(87936001)(5008740100001)(77096005)(83506001)(5001770100001)(86362001)(5002640100001)(19580395003)(19580405001)(11100500001)(50986999)(2561002)(4001350100001)(2950100001)(76176999)(54356999)(106116001)(2900100001)(93886004)(36756003)(3660700001)(10400500002)(5004730100002)(3846002)(102836003)(6116002)(1096002)(586003)(1220700001)(189998001)(4326007)(40100003)(66066001)(122556002)(1511001)(3280700002)(92566002)(5001960100002)(2906002)(74482002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB383; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2016 19:58:53.9296 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB383 Archived-At: Cc: Antoine Delignat-Lavaud , Karthikeyan Bhargavan , Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 19:59:19 -0000 SGkNCg0KTXkgMmMgYmVsb3cuLi4NCg0KT24gMjAvMDIvMjAxNiAxODo1MywgIlRMUyBvbiBiZWhh bGYgb2YgQ2VkcmljIEZvdXJuZXQiDQo8dGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGZvdXJuZXRAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+DQo+IA0KPkJlc2lkZXMsIGluIG91ciBh bmFseXNpcyBvZiB0aGUgaGFuZHNoYWtlLCB3ZSBnZXQgcHJlY2lzZWx5IHRoZSBzYW1lDQo+4oCc ZnJlc2gsIG5ldmVyLXVzZWQgc2VjcmV04oCdIHByb3BlcnR5IHlvdSBhcmUgYWR2b2NhdGluZywg d2l0aCBvcg0KPiB3aXRob3V0IHRoZSBzaW1wbGlmaWNhdGlvbiwgZWFjaCB0aW1lIHRoZSBoYW5k c2hha2UgcHJvdmlkZXMga2V5cyB0byB0aGUNCj5yZWNvcmQgbGF5ZXIuIFRoZXNlIHBvaW50cyBh cmUgd2VsbC1zcGVjaWZpZWQgYW5kIGRlbGltaXRlZC4gVGhleSBqdXN0IGRvDQo+bm90IGNvaW5j aWRlIHdpdGggdGhlIGVuZCBvZiB0aGUgaGFuZHNoYWtlLiBTbyBJIGRvbuKAmXQgc2VlIGFueQ0K PmZ1bmRhbWVudGFsIGRpZmZlcmVuY2UgaW4gdGVybSBvZiBnZW5lcmljLXNlY3VyaXR5Lg0KPiAN Cj5XZSBhcmUgbGVmdCB3aXRoIHNjZW5hcmlvcyB3aGVyZWJ5IHRoZSByZWNvcmQgbGF5ZXIsIGdp dmVuIGJvdGggdGhlDQo+aGFuZHNoYWtlIGFuZCBhcHBsaWNhdGlvbi1kYXRhIHRyYWZmaWMga2V5 cywgc29tZWhvdyBsZWFrcyBvbmx5DQo+IG9uZSBvZiB0aGUgdHdvLiBJIGRvbuKAmXQgbWluZCBr ZWVwaW5nIHRoZSBrZXkgY2hhbmdlIGlmIHNvbWVvbmUgaXMNCj5jb25jZXJuZWQgYWJvdXQgaXQu DQoNCkxpa2UgSHVnbywgSSBhbSBhbHNvIGNvbmNlcm5lZCBhYm91dCByZW1vdmluZyB0aGUga2V5 IGNoYW5nZS4gTGV0IG1lIHRyeQ0KdG8gZXhwbGFpbiB3aHkuDQoNCkkgd291bGQgZW1waGFzaXNl IHRoZSBwb2ludCB0aGF0IHdoaWxlIHdlICpjYW4qIHByb3ZpZGUgZm9ybWFsIHNlY3VyaXR5DQph bmFseXNlcyBpbiB0aGUgc2l0dWF0aW9uIHdoZXJlIHRoZSBhcHBsaWNhdGlvbiBrZXkgaXMgdXNl ZCBkdXJpbmcgdGhlDQpoYW5kc2hha2UgaXRzZWxmLCBpdCBpcyBtYWRlIHNpZ25pZmljYW50bHkg bW9yZSBjb21wbGV4Lg0KDQpJbiBwYXJ0aWN1bGFyLCBpdCBtZWFucyB3ZSBjYW5ub3Qgc2ltcGx5 IGNvbWJpbmUgc2VjdXJpdHkgcmVzdWx0cyBhcmlzaW5nDQpmcm9tIHNlcGFyYXRlIGFuYWx5c2Vz IG9mIHRoZSBIYW5kc2hha2UgUHJvdG9jb2wgYW5kIG9mIHRoZSBSZWNvcmQNClByb3RvY29sIHRv IG9idGFpbiBzZWN1cml0eSBndWFyYW50ZWVzIGZvciB0aGUgY29tcG9zaXRpb24gb2YgdGhlc2Ug dHdvDQpwcm90b2NvbHMuIFNvIGZvciBleGFtcGxlLCBpZiB3ZSBjaG9zZSB0byByZWZpbmUgb3Vy IG1vZGVsbGluZyBvZiB0aGUNClJlY29yZCBQcm90b2NvbCBpbiBzb21lIHdheSwgdGhlbiB3ZSB3 b3VsZCBuZWVkIHRvIHJlLWRvIHRoZSBhbmFseXNpcyBvZg0KVExTIChIYW5kc2hha2UgKyBSZWNv cmQgUHJvdG9jb2xzKSBhcyBhIG1vbm9saXRoaWMgZWZmb3J0LiBUaGF0J3MgaGFyZA0Kd29yayBh bmQgZXJyb3IgcHJvbmUuIFRoaXMgc2l0dWF0aW9uIHdvdWxkIG5vdCBhcmlzZSBpZiB0aGUgYXBw bGljYXRpb24NCmtleXMgd2VyZSBOT1QgdXNlZCBpbiB0aGUgaGFuZHNoYWtlLg0KDQpUaGlzIGlz IG5vdCBtZXJlbHkgYSBjb25qZWN0dXJlZCBpc3N1ZS4gQXMgb25lIGV4YW1wbGUsIHNldmVyYWwg cGFwZXJzDQooaW5jbHVkaW5nIFsxLDJdKSBpbiB0aGUgInByb3ZhYmxlIHNlY3VyaXR5IiBwYXJh ZGlnbSBoYXZlIHVzZWQgdGhlIEFDQ0UNCmZyYW1ld29yayBhcyBhIHNlY3VyaXR5IG1vZGVsIHdp dGhpbiB3aGljaCB0byBjb25kdWN0IGFuYWx5c2lzIG9mDQpmcmFnbWVudHMgb2YgcHJldmlvdXMg dmVyc2lvbnMgb2YgVExTLiBBQ0NFIHdhcyBzcGVjaWZpY2FsbHkgZGVzaWduZWQgdG8NCmRlYWwg d2l0aCBrZXlzIHRoYXQgYXJlIHVzZWQgYWNyb3NzIHRoZSBIYW5kc2hha2UgYW5kIHRoZSBSZWNv cmQNCnByb3RvY29scy4gQnV0IEFDQ0Ugdmlld3MgdGhlIFJlY29yZCBQcm90b2NvbCBpbiBhIHBh cnRpY3VsYXIgd2F5IC0NCmVzc2VudGlhbGx5IGFzIGEgc3RhdGVmdWwgZW5jcnlwdGlvbiBzY2hl bWUgdGhhdCBwcm9jZXNzZXMgImF0b21pYyINCm1lc3NhZ2VzLiBUaGlzIG1vZGVsbGluZyBkb2Vz IG5vdCB0YWtlIGludG8gZnVsbCBhY2NvdW50IHRoZSBzdHJlYW1pbmcNCm5hdHVyZSBvZiB0aGUg VExTIFJlY29yZCBQcm90b2NvbCAtIGluIGZhY3QsIHdoYXQgdGhlIFJlY29yZCBQcm90b2NvbA0K YWN0dWFsbHkgZ3VhcmFudGVlcyBpcyBzaWduaWZpY2FudGx5IGRpZmZlcmVudCBmcm9tIHdoYXQg aXMgaW1wbGllZCBieSB0aGUNCkFDQ0UgbW9kZWxsaW5nIG9mIGl0IC0gc2VlIFszXSBmb3IgZGV0 YWlscywgYW5kIGFsc28gdGhlIGNvb2tpZSBjdXR0ZXINCmF0dGFjayBmcm9tIHRoZSBUcmlwbGUg SGFuZHNoYWtlcyBwYXBlciBmb3IgYW4gZXhhbXBsZSBvZiB3aGF0IGNhbiBnbw0Kd3JvbmcuDQoN Ck9uZSBpbXBsaWNhdGlvbiBvZiB0aGlzIGlzIHRoYXQgdGhlIHJlc3VsdHMgb2YgWzEsMl0gZm9y IGV4aXN0aW5nIHZlcnNpb25zDQpvZiBUTFMgcmVhbGx5IG5lZWQgdG8gYmUgcmV3b3JrZWQgaW4g YSBtb2RpZmllZCB2ZXJzaW9uIG9mIHRoZSBBQ0NFDQpmcmFtZXdvcmsgdGhhdCBiZXR0ZXIgcmVm bGVjdHMgdGhlIHN0cmVhbWluZyBuYXR1cmUgb2YgdGhlIFJlY29yZA0KUHJvdG9jb2wuIFRoYXQg bmVlZCBmb3IgcmV3b3JrIHdvdWxkIGhhdmUgYmVlbiBhdm9pZGVkIGhhZCBUTFMgbm90IHVzZWQN CmFwcGxpY2F0aW9uIGtleXMgaW4gdGhlIEhhbmRzaGFrZSBQcm90b2NvbCwgYmVjYXVzZSB0aGUg Y29tcG9zaXRpb25hbA0KZ3VhcmFudGVlcyB3b3VsZCBoYXZlIGVuYWJsZWQgdXMgdG8gInBsdWcg YW5kIHBsYXkiIHdpdGggb3VyIHJlc3VsdHMuDQoNClRoZSBzYW1lIHBlcnRhaW5zIGluIFRMUyAx LjMgZ29pbmcgZm9yd2FyZDoga2VlcGluZyB0aGUgc3RyaWN0IGtleQ0Kc2VwYXJhdGlvbiAtIG5v IHVzZSBvZiB0aGUgYXBwbGljYXRpb24ga2V5cyBpbiB0aGUgSGFuZHNoYWtlIC0gd2lsbCBtYWtl DQpmdXR1cmUgLSBhbmQgb24tZ29pbmcgLSBhbmFseXNlcyBvZiBUTFMgMS4zIGVhc2llci4gVGhp cyBpcw0Kbm90d2l0aHN0YW5kaW5nIHRoZSBmYWN0IHRoYXQgc2V2ZXJhbCByZXNlYXJjaCB0ZWFt cywgaW5jbHVkaW5nIENlZHJpYydzDQphbmQgWzEsMl0gYmVsb3csIGhhdmUgbWFuYWdlZCB0byBw cm9kdWNlIGFuYWx5c2VzIHRoYXQgZG8gaGFuZGxlIHRoZSB1c2UNCm9mIHRoZSBhcHBsaWNhdGlv biBrZXkgaW4gdGhlIEhhbmRzaGFrZS4NCg0KUmVnYXJkcywNCg0KS2VubnkgDQoNClsxXSBUaWJv ciBKYWdlciwgRmxvcmlhbiBLb2hsYXIsIFN2ZW4gU2Now6RnZSwgSsO2cmcgU2Nod2Vuay4gT24g dGhlDQpTZWN1cml0eSBvZiBUTFMtREhFIGluIHRoZSBTdGFuZGFyZCBNb2RlbC4gQ1JZUFRPIDIw MTIuDQpbMl0gSHVnbyBLcmF3Y3p5aywgS2VubmV0aCBHLiBQYXRlcnNvbiwgSG9ldGVjayBXZWUu IE9uIHRoZSBTZWN1cml0eSBvZg0KdGhlIFRMUyBQcm90b2NvbDogQSBTeXN0ZW1hdGljIEFuYWx5 c2lzLiBDUllQVE8gKDEpIDIwMTMuDQpbM10gTWFyYyBGaXNjaGxpbiwgRmVsaXggR8O8bnRoZXIs IEdpb3JnaWEgQXp6dXJyYSBNYXJzb24sIEtlbm5ldGggRy4NClBhdGVyc29uOiBEYXRhIElzIGEg U3RyZWFtOiBTZWN1cml0eSBvZiBTdHJlYW0tQmFzZWQgQ2hhbm5lbHMuIENSWVBUTyAoMikNCjIw MTUuDQoNCg0K From nobody Sat Feb 20 12:30:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE4CE1A1B2B for ; Sat, 20 Feb 2016 12:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=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 3deo-CeX_inD for ; Sat, 20 Feb 2016 12:30:47 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCDF1B29AA for ; Sat, 20 Feb 2016 12:30:47 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id u200so92483594ywf.0 for ; Sat, 20 Feb 2016 12:30:47 -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:content-type; bh=OmU6To/nf2zvoWUwcf3UbLthQI8lTdVgrKT4eFkYKeI=; b=ZBK/ysOl6s/aLsJuMB6RLW/Ca7J7xfa2wARIjociZUT2yIIftvvAZjF7APWmefzUXH tz6IVkxsSNFhGcAgUDQnCFpnGBvyOhEYIvZoanSwMf9iTO14nt8Fn/H8pL97ZU8ZuMnp NnNSl/NzMLzJm4RSa6apOobEvOZoA8MgZiAP/0pyXcoIwye+oiGIKKYXp2Gf2i2xMd6F Pr5vMvNqmlNAKa9OUgxNF0P2TkTCuYrQZeOZ08aU4Pxh4S3sLgtGTfKhI+qQtfZNgp9z WKgO0IlTMo1+dhfXDfMDEhL3g+xvt0lsqu70RIJ3CmJSUvRS0dP9+bR6mXUbyqayHj1S EBZg== 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-type; bh=OmU6To/nf2zvoWUwcf3UbLthQI8lTdVgrKT4eFkYKeI=; b=jd9Av05rLEoIU41PP2KPb7nL0gLi5f4uEsgR9D8M96BlEsvXM60nbxyEdKzyhsCsL+ lpKVJCv0Kw0lFRVmDnqd2SqqbSCZLxJhDoVxqMw2DIe9MzSVuJKPmNuuLOuzwjlIE+Ki 0uBLwcbD0yTEUG7lOMfGlhr6sC/Fo9Ni5lXFQWwfZPx2xRNafFCeAsY4lx89G3cBgc7r Fzs0eLSdCBZw22vTl7sgsx1wDxeXPNGj7CMf0TMUhVM/mzQO6Nq49ahsk3H+E4YkAinT cKwStkmYHXHKtHmGcIPciNa31hXsJXiMqy19LiZtuXx2sYomx2Q3A4+rhIxI2D6zX+ji KpMQ== X-Gm-Message-State: AG10YOThUqfihOwZgx+8GI8wLzWs/qC571q+O6xmtWqTNgxS9Fm8NYBOacihrEW/XIaQHc6xVAcx7SkuQI+GOQ== X-Received: by 10.129.73.207 with SMTP id w198mr11133239ywa.223.1456000246302; Sat, 20 Feb 2016 12:30:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sat, 20 Feb 2016 12:30:06 -0800 (PST) In-Reply-To: References: <20160219105851.GA14585@LK-Perkele-V2.elisa-laajakaista.fi> <4cfe8afe17a44ed096102aacf12dcbc3@AM3PR30MB049.064d.mgd.msft.net> From: Eric Rescorla Date: Sat, 20 Feb 2016 12:30:06 -0800 Message-ID: To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=001a114dc91c797eb7052c3979be Archived-At: Cc: Karthikeyan Bhargavan , Markulf Kohlweiss , "tls@ietf.org" , Antoine Delignat-Lavaud Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 20:30:50 -0000 --001a114dc91c797eb7052c3979be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Kenny, Would you have a problem with doing as Karthik suggests and generating separate traffic and handshake keys but at the same time? -Ekr On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny wrote: > Hi > > My 2c below... > > On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet" > wrote: > > > > > >Besides, in our analysis of the handshake, we get precisely the same > >=E2=80=9Cfresh, never-used secret=E2=80=9D property you are advocating, = with or > > without the simplification, each time the handshake provides keys to th= e > >record layer. These points are well-specified and delimited. They just d= o > >not coincide with the end of the handshake. So I don=E2=80=99t see any > >fundamental difference in term of generic-security. > > > >We are left with scenarios whereby the record layer, given both the > >handshake and application-data traffic keys, somehow leaks only > > one of the two. I don=E2=80=99t mind keeping the key change if someone = is > >concerned about it. > > Like Hugo, I am also concerned about removing the key change. Let me try > to explain why. > > I would emphasise the point that while we *can* provide formal security > analyses in the situation where the application key is used during the > handshake itself, it is made significantly more complex. > > In particular, it means we cannot simply combine security results arising > from separate analyses of the Handshake Protocol and of the Record > Protocol to obtain security guarantees for the composition of these two > protocols. So for example, if we chose to refine our modelling of the > Record Protocol in some way, then we would need to re-do the analysis of > TLS (Handshake + Record Protocols) as a monolithic effort. That's hard > work and error prone. This situation would not arise if the application > keys were NOT used in the handshake. > > This is not merely a conjectured issue. As one example, several papers > (including [1,2]) in the "provable security" paradigm have used the ACCE > framework as a security model within which to conduct analysis of > fragments of previous versions of TLS. ACCE was specifically designed to > deal with keys that are used across the Handshake and the Record > protocols. But ACCE views the Record Protocol in a particular way - > essentially as a stateful encryption scheme that processes "atomic" > messages. This modelling does not take into full account the streaming > nature of the TLS Record Protocol - in fact, what the Record Protocol > actually guarantees is significantly different from what is implied by th= e > ACCE modelling of it - see [3] for details, and also the cookie cutter > attack from the Triple Handshakes paper for an example of what can go > wrong. > > One implication of this is that the results of [1,2] for existing version= s > of TLS really need to be reworked in a modified version of the ACCE > framework that better reflects the streaming nature of the Record > Protocol. That need for rework would have been avoided had TLS not used > application keys in the Handshake Protocol, because the compositional > guarantees would have enabled us to "plug and play" with our results. > > The same pertains in TLS 1.3 going forward: keeping the strict key > separation - no use of the application keys in the Handshake - will make > future - and on-going - analyses of TLS 1.3 easier. This is > notwithstanding the fact that several research teams, including Cedric's > and [1,2] below, have managed to produce analyses that do handle the use > of the application key in the Handshake. > > Regards, > > Kenny > > [1] Tibor Jager, Florian Kohlar, Sven Sch=C3=A4ge, J=C3=B6rg Schwenk. On = the > Security of TLS-DHE in the Standard Model. CRYPTO 2012. > [2] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee. On the Security of > the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013. > [3] Marc Fischlin, Felix G=C3=BCnther, Giorgia Azzurra Marson, Kenneth G. > Paterson: Data Is a Stream: Security of Stream-Based Channels. CRYPTO (2) > 2015. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dc91c797eb7052c3979be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kenny,

Would you have a problem wit= h doing as Karthik suggests and generating
separate traffic and h= andshake keys but at the same time?

-Ekr


= On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny <Kenny.Paterson@= rhul.ac.uk> wrote:
Hi

My 2c below...

On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet"
<tls-bounces@ie= tf.org on behalf of fournet@mi= crosoft.com> wrote:
>
>
>Besides, in our analysis of the handshake, we get precisely the same >=E2=80=9Cfresh, never-used secret=E2=80=9D property you are advocating,= with or
> without the simplification, each time the handshake provides keys to t= he
>record layer. These points are well-specified and delimited. They just = do
>not coincide with the end of the handshake. So I don=E2=80=99t see any<= br> >fundamental difference in term of generic-security.
>
>We are left with scenarios whereby the record layer, given both the
>handshake and application-data traffic keys, somehow leaks only
> one of the two. I don=E2=80=99t mind keeping the key change if someone= is
>concerned about it.

Like Hugo, I am also concerned about removing the key change. Let me= try
to explain why.

I would emphasise the point that while we *can* provide formal security
analyses in the situation where the application key is used during the
handshake itself, it is made significantly more complex.

In particular, it means we cannot simply combine security results arising from separate analyses of the Handshake Protocol and of the Record
Protocol to obtain security guarantees for the composition of these two
protocols. So for example, if we chose to refine our modelling of the
Record Protocol in some way, then we would need to re-do the analysis of TLS (Handshake + Record Protocols) as a monolithic effort. That's hard<= br> work and error prone. This situation would not arise if the application
keys were NOT used in the handshake.

This is not merely a conjectured issue. As one example, several papers
(including [1,2]) in the "provable security" paradigm have used t= he ACCE
framework as a security model within which to conduct analysis of
fragments of previous versions of TLS. ACCE was specifically designed to deal with keys that are used across the Handshake and the Record
protocols. But ACCE views the Record Protocol in a particular way -
essentially as a stateful encryption scheme that processes "atomic&quo= t;
messages. This modelling does not take into full account the streaming
nature of the TLS Record Protocol - in fact, what the Record Protocol
actually guarantees is significantly different from what is implied by the<= br> ACCE modelling of it - see [3] for details, and also the cookie cutter
attack from the Triple Handshakes paper for an example of what can go
wrong.

One implication of this is that the results of [1,2] for existing versions<= br> of TLS really need to be reworked in a modified version of the ACCE
framework that better reflects the streaming nature of the Record
Protocol. That need for rework would have been avoided had TLS not used
application keys in the Handshake Protocol, because the compositional
guarantees would have enabled us to "plug and play" with our resu= lts.

The same pertains in TLS 1.3 going forward: keeping the strict key
separation - no use of the application keys in the Handshake - will make future - and on-going - analyses of TLS 1.3 easier. This is
notwithstanding the fact that several research teams, including Cedric'= s
and [1,2] below, have managed to produce analyses that do handle the use of the application key in the Handshake.

Regards,

Kenny

[1] Tibor Jager, Florian Kohlar, Sven Sch=C3=A4ge, J=C3=B6rg Schwenk. On th= e
Security of TLS-DHE in the Standard Model. CRYPTO 2012.
[2] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee. On the Security of
the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013.
[3] Marc Fischlin, Felix G=C3=BCnther, Giorgia Azzurra Marson, Kenneth G. Paterson: Data Is a Stream: Security of Stream-Based Channels. CRYPTO (2) 2015.


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

--001a114dc91c797eb7052c3979be-- From nobody Sat Feb 20 14:45:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5141A8A7D for ; Sat, 20 Feb 2016 14:45:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TbsTaEacOGrD for ; Sat, 20 Feb 2016 14:45:20 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991D21A8A5A for ; Sat, 20 Feb 2016 14:45:20 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id g127so93734905ywf.2 for ; Sat, 20 Feb 2016 14:45: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:date:message-id:subject:from:to :cc:content-type; bh=YXna7aLo0xENY/bVb2t+p6nTndmcWspgL+UdZXUhGAY=; b=e9C4W5vpuYHISyTFJPhIEWHXF9Ezp8VHCSFWwflFJzmc9hfFKTO2b0O7IaXUgsy+LN PLRtT7sJE+mEk7l+Po5RCXhwLiwXYO1JrFQoOqIyHOUHUOJT3p8wwjMKBoGWX6l0+E/B 6pyRkdP9l2T2WHnf9iDhRXlZCL9KoLAcXmRHX2OV+3sZkiaMec6WYeJzvsIm2SL4mbRY lhYO67gxDkkNmG6VhpPb8mjayqSiluKkk9mjDu+OBmNG62qzcRnT4ChheYO17jHQTOez 6gLij7LGwoqpvUHZOdrfxkbvDpNs+lW14dUETbnHIz77S0wyxR0Bhm21vi9eEQqu/2cE jFQw== 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:date :message-id:subject:from:to:cc:content-type; bh=YXna7aLo0xENY/bVb2t+p6nTndmcWspgL+UdZXUhGAY=; b=TopqrSqIMG2PQC2KS0LQrl0M01j0bLs40bDWB+aTcrplqKsDTgu3J2D3Q8+jotgKtN +/z2d/BTnIeXZW3zVCRQVW+KaTRMYCZCznkFouLDsSe5by9/NAovrJpqnFlaKFaH0HfZ raKQH8WLnqrrb8ahdpokVCo9fkWJ4PPf8b+AJH8o0xS55xL7IsJ5fsRkyTUXgybD+a6l RnWaYFHgb4l4Y4Lb26BueK4CzqKxfzKnIQk5vwHT/v1A9k1Xiw8SS+1ab1hob+yzFXi+ HgoS5zRm5VR4zgI3rIFt0jNn887ANx5KXHdhovYCbpYYGauTm6JavrXVOpo9KQLwRQ8+ 6BrA== X-Gm-Message-State: AG10YOSu7K6gGq77gl2g0jH4/70hhJoOevW554dltjyJQosjmeTTPtoXMsKONN0vVpHP2CGHqG+WDt4Px4MGgQ== MIME-Version: 1.0 X-Received: by 10.13.226.86 with SMTP id l83mr11449191ywe.239.1456008319928; Sat, 20 Feb 2016 14:45:19 -0800 (PST) Received: by 10.13.216.138 with HTTP; Sat, 20 Feb 2016 14:45:19 -0800 (PST) Received: by 10.13.216.138 with HTTP; Sat, 20 Feb 2016 14:45:19 -0800 (PST) In-Reply-To: References: <20160219105851.GA14585@LK-Perkele-V2.elisa-laajakaista.fi> <4cfe8afe17a44ed096102aacf12dcbc3@AM3PR30MB049.064d.mgd.msft.net> Date: Sat, 20 Feb 2016 14:45:19 -0800 Message-ID: From: Watson Ladd To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114fc152b31170052c3b5a07 Archived-At: Cc: Antoine Delignat-Lavaud , Markulf Kohlweiss , Karthikeyan Bhargavan , tls@ietf.org Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 22:45:23 -0000 --001a114fc152b31170052c3b5a07 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Feb 20, 2016 12:31 PM, "Eric Rescorla" wrote: > > Kenny, > > Would you have a problem with doing as Karthik suggests and generating > separate traffic and handshake keys but at the same time? This solves all the problems completely, as the traffic key is fresh. > > -Ekr > > > On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny < Kenny.Paterson@rhul.ac.uk> wrote: >> >> Hi >> >> My 2c below... >> >> On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet" >> wrote: >> > >> > >> >Besides, in our analysis of the handshake, we get precisely the same >> >=E2=80=9Cfresh, never-used secret=E2=80=9D property you are advocating,= with or >> > without the simplification, each time the handshake provides keys to the >> >record layer. These points are well-specified and delimited. They just do >> >not coincide with the end of the handshake. So I don=E2=80=99t see any >> >fundamental difference in term of generic-security. >> > >> >We are left with scenarios whereby the record layer, given both the >> >handshake and application-data traffic keys, somehow leaks only >> > one of the two. I don=E2=80=99t mind keeping the key change if someone= is >> >concerned about it. >> >> Like Hugo, I am also concerned about removing the key change. Let me try >> to explain why. >> >> I would emphasise the point that while we *can* provide formal security >> analyses in the situation where the application key is used during the >> handshake itself, it is made significantly more complex. >> >> In particular, it means we cannot simply combine security results arisin= g >> from separate analyses of the Handshake Protocol and of the Record >> Protocol to obtain security guarantees for the composition of these two >> protocols. So for example, if we chose to refine our modelling of the >> Record Protocol in some way, then we would need to re-do the analysis of >> TLS (Handshake + Record Protocols) as a monolithic effort. That's hard >> work and error prone. This situation would not arise if the application >> keys were NOT used in the handshake. >> >> This is not merely a conjectured issue. As one example, several papers >> (including [1,2]) in the "provable security" paradigm have used the ACCE >> framework as a security model within which to conduct analysis of >> fragments of previous versions of TLS. ACCE was specifically designed to >> deal with keys that are used across the Handshake and the Record >> protocols. But ACCE views the Record Protocol in a particular way - >> essentially as a stateful encryption scheme that processes "atomic" >> messages. This modelling does not take into full account the streaming >> nature of the TLS Record Protocol - in fact, what the Record Protocol >> actually guarantees is significantly different from what is implied by the >> ACCE modelling of it - see [3] for details, and also the cookie cutter >> attack from the Triple Handshakes paper for an example of what can go >> wrong. >> >> One implication of this is that the results of [1,2] for existing versions >> of TLS really need to be reworked in a modified version of the ACCE >> framework that better reflects the streaming nature of the Record >> Protocol. That need for rework would have been avoided had TLS not used >> application keys in the Handshake Protocol, because the compositional >> guarantees would have enabled us to "plug and play" with our results. >> >> The same pertains in TLS 1.3 going forward: keeping the strict key >> separation - no use of the application keys in the Handshake - will make >> future - and on-going - analyses of TLS 1.3 easier. This is >> notwithstanding the fact that several research teams, including Cedric's >> and [1,2] below, have managed to produce analyses that do handle the use >> of the application key in the Handshake. >> >> Regards, >> >> Kenny >> >> [1] Tibor Jager, Florian Kohlar, Sven Sch=C3=A4ge, J=C3=B6rg Schwenk. On= the >> Security of TLS-DHE in the Standard Model. CRYPTO 2012. >> [2] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee. On the Security of >> the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013. >> [3] Marc Fischlin, Felix G=C3=BCnther, Giorgia Azzurra Marson, Kenneth G= . >> Paterson: Data Is a Stream: Security of Stream-Based Channels. CRYPTO (2= ) >> 2015. >> >> >> _______________________________________________ >> 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 > --001a114fc152b31170052c3b5a07 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 20, 2016 12:31 PM, "Eric Rescorla" <ekr@rtfm.com> wrote:
>
> Kenny,
>
> Would you have a problem with doing as Karthik suggests and generating=
> separate traffic and handshake keys but at the same time?

This solves all the problems completely, as the traffic key = is fresh.

>
> -Ekr
>
>
> On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk> wrote:
>>
>> Hi
>>
>> My 2c below...
>>
>> On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet" >> <tls-bounces@ietf.org on behalf of fournet@microsoft.= com> wrote:
>> >
>> >
>> >Besides, in our analysis of the handshake, we get precisely th= e same
>> >=E2=80=9Cfresh, never-used secret=E2=80=9D property you are ad= vocating, with or
>> > without the simplification, each time the handshake provides = keys to the
>> >record layer. These points are well-specified and delimited. T= hey just do
>> >not coincide with the end of the handshake. So I don=E2=80=99t= see any
>> >fundamental difference in term of generic-security.
>> >
>> >We are left with scenarios whereby the record layer, given bot= h the
>> >handshake and application-data traffic keys, somehow leaks onl= y
>> > one of the two. I don=E2=80=99t mind keeping the key change i= f someone is
>> >concerned about it.
>>
>> Like Hugo, I am also concerned about removing the key change. Let = me try
>> to explain why.
>>
>> I would emphasise the point that while we *can* provide formal sec= urity
>> analyses in the situation where the application key is used during= the
>> handshake itself, it is made significantly more complex.
>>
>> In particular, it means we cannot simply combine security results = arising
>> from separate analyses of the Handshake Protocol and of the Record=
>> Protocol to obtain security guarantees for the composition of thes= e two
>> protocols. So for example, if we chose to refine our modelling of = the
>> Record Protocol in some way, then we would need to re-do the analy= sis of
>> TLS (Handshake + Record Protocols) as a monolithic effort. That= 9;s hard
>> work and error prone. This situation would not arise if the applic= ation
>> keys were NOT used in the handshake.
>>
>> This is not merely a conjectured issue. As one example, several pa= pers
>> (including [1,2]) in the "provable security" paradigm ha= ve used the ACCE
>> framework as a security model within which to conduct analysis of<= br> >> fragments of previous versions of TLS. ACCE was specifically desig= ned to
>> deal with keys that are used across the Handshake and the Record >> protocols. But ACCE views the Record Protocol in a particular way = -
>> essentially as a stateful encryption scheme that processes "a= tomic"
>> messages. This modelling does not take into full account the strea= ming
>> nature of the TLS Record Protocol - in fact, what the Record Proto= col
>> actually guarantees is significantly different from what is implie= d by the
>> ACCE modelling of it - see [3] for details, and also the cookie cu= tter
>> attack from the Triple Handshakes paper for an example of what can= go
>> wrong.
>>
>> One implication of this is that the results of [1,2] for existing = versions
>> of TLS really need to be reworked in a modified version of the ACC= E
>> framework that better reflects the streaming nature of the Record<= br> >> Protocol. That need for rework would have been avoided had TLS not= used
>> application keys in the Handshake Protocol, because the compositio= nal
>> guarantees would have enabled us to "plug and play" with= our results.
>>
>> The same pertains in TLS 1.3 going forward: keeping the strict key=
>> separation - no use of the application keys in the Handshake - wil= l make
>> future - and on-going - analyses of TLS 1.3 easier. This is
>> notwithstanding the fact that several research teams, including Ce= dric's
>> and [1,2] below, have managed to produce analyses that do handle t= he use
>> of the application key in the Handshake.
>>
>> Regards,
>>
>> Kenny
>>
>> [1] Tibor Jager, Florian Kohlar, Sven Sch=C3=A4ge, J=C3=B6rg Schwe= nk. On the
>> Security of TLS-DHE in the Standard Model. CRYPTO 2012.
>> [2] Hugo Krawczyk, Kenneth G. Paterson, Hoeteck Wee. On the Securi= ty of
>> the TLS Protocol: A Systematic Analysis. CRYPTO (1) 2013.
>> [3] Marc Fischlin, Felix G=C3=BCnther, Giorgia Azzurra Marson, Ken= neth G.
>> Paterson: Data Is a Stream: Security of Stream-Based Channels. CRY= PTO (2)
>> 2015.
>>
>>
>> _______________________________________________
>> 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
>

--001a114fc152b31170052c3b5a07-- From nobody Sat Feb 20 15:24:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F3581ACDE4 for ; Sat, 20 Feb 2016 15:24:28 -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_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yiyExLFBmEri for ; Sat, 20 Feb 2016 15:24:23 -0800 (PST) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0642.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::642]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A2D71AC42C for ; Sat, 20 Feb 2016 15:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rhul.onmicrosoft.com; s=selector1-rhul-ac-uk; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=O2Cj0LNfFTxF8pdiBFI2LNhrJBGinc3az1Xp7yetmB0=; b=yxGAD8moLjs5xlkXXkhpVo7lvi9hcvpDo80NdXVJkzNToQ3H/UBzcLRC3jJr0/d43eDW0keV+fR5RqGK8SewKEdYEqpmg7jPZnW5r2jeiJN3lRWUWXBs9oWWy0g69+k+lbzQEqZkuE1lecLzbTdAmnATh4Ay01LKm2EfF/2VshI= Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB381.eurprd03.prod.outlook.com (10.141.10.11) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sat, 20 Feb 2016 23:24:05 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.01.0409.022; Sat, 20 Feb 2016 23:24:05 +0000 From: "Paterson, Kenny" To: Eric Rescorla Thread-Topic: [TLS] Proposal: don't change keys between handshake and application layer Thread-Index: AQHRallUDdODj83lLkuzfZ3i8yNhJp8x48sAgAAfHgCAARGDAIAAH+mAgAA3KwCAAD4SAIAAIQIAgAGAxACAABIDAIAACOoAgAAwf4A= Date: Sat, 20 Feb 2016 23:24:05 +0000 Message-ID: References: <20160219105851.GA14585@LK-Perkele-V2.elisa-laajakaista.fi> <4cfe8afe17a44ed096102aacf12dcbc3@AM3PR30MB049.064d.mgd.msft.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.0.151221 authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=rhul.ac.uk; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [67.52.140.5] x-microsoft-exchange-diagnostics: 1; DBXPR03MB381; 5:wm8FO31Reu6mtfI3QKoxpv8Lu0E52DuMCuXDGboWKAP8WpSBWEr6AUYYHVIwnjGV3NvPz8Yy2hXlI/MuSRa4f/HG+uKvrvI7bd2tZymR6hbpc6QPkSO7QZlXw4btlZDP46XlAwxFtrq1mU2ISRkNcg==; 24:nceFKeMcEflaZG95xqo1+aVT6kNH1BJI9+UHYxZ4veI8XRnoaj7dt9+UqmzeUa5QoL2T61xP29k7lLBPqzQrjsZ9Gsm9Wu5miiOQJxc1Uu8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR03MB381; x-ms-office365-filtering-correlation-id: 35ea8b05-36c5-4cda-e0e1-08d33a4cece0 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(58933420132496); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:DBXPR03MB381; BCL:0; PCL:0; RULEID:; SRVR:DBXPR03MB381; x-forefront-prvs: 0858FF8026 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(479174004)(377454003)(24454002)(15975445007)(1096002)(11100500001)(5002640100001)(77096005)(122556002)(93886004)(1220700001)(74482002)(40100003)(76176999)(54356999)(50986999)(66066001)(5008740100001)(5004730100002)(4326007)(92566002)(19580405001)(3280700002)(2906002)(3660700001)(10400500002)(106116001)(86362001)(36756003)(586003)(6116002)(83506001)(102836003)(3846002)(19580395003)(189998001)(5001960100002)(110136002)(2900100001)(87936001)(4001350100001)(2950100001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB381; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; Content-Type: text/plain; charset="utf-8" Content-ID: <0B49AB1F45276748980C9C916E292C28@eurprd03.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2016 23:24:05.3739 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2efd699a-1922-4e69-b601-108008d28a2e X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR03MB381 Archived-At: Cc: Karthikeyan Bhargavan , Markulf Kohlweiss , "tls@ietf.org" , Antoine Delignat-Lavaud Subject: Re: [TLS] Proposal: don't change keys between handshake and application layer X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Feb 2016 23:24:28 -0000 SGkgRXJpYywNCg0KTG9va3MgbGlrZSBXYXRzb24gYWxyZWFkeSBnYXZlIGEgZGVmaW5pdGl2ZSBy ZXBseSBvbiBteSBiZWhhbGYuIFRoYW5rcw0KV2F0c29uLCBmb3IgYmVpbmcgc3VjaCBhbiBlZmZl Y3RpdmUgYW5kIHByb2FjdGl2ZSBhbWFudWVuc2lzLg0KDQpGb3IgdGhlIGF2b2lkYW5jZSBvZiBk b3VidDogd2hhdCBLYXJ0aGlrIHN1Z2dlc3RzIHdvdWxkIGF2b2lkIHRoZSBwcm9ibGVtDQp3ZSd2 ZSBiZWVuIGRpc2N1c3NpbmcsIHNvIEknZCBiZSBxdWl0ZSBoYXBweSB3aXRoIGl0Lg0KDQpDaGVl cnMNCg0KS2VubnkgDQoNCk9uIDIwLzAyLzIwMTYgMjA6MzAsICJFcmljIFJlc2NvcmxhIiA8ZWty QHJ0Zm0uY29tPiB3cm90ZToNCg0KPktlbm55LA0KPg0KPg0KPldvdWxkIHlvdSBoYXZlIGEgcHJv YmxlbSB3aXRoIGRvaW5nIGFzIEthcnRoaWsgc3VnZ2VzdHMgYW5kIGdlbmVyYXRpbmcNCj5zZXBh cmF0ZSB0cmFmZmljIGFuZCBoYW5kc2hha2Uga2V5cyBidXQgYXQgdGhlIHNhbWUgdGltZT8NCj4N Cj4NCj4tRWtyDQo+DQo+DQo+DQo+DQo+T24gU2F0LCBGZWIgMjAsIDIwMTYgYXQgMTE6NTggQU0s IFBhdGVyc29uLCBLZW5ueQ0KPjxLZW5ueS5QYXRlcnNvbkByaHVsLmFjLnVrPiB3cm90ZToNCj4N Cj5IaQ0KPg0KPk15IDJjIGJlbG93Li4uDQo+DQo+T24gMjAvMDIvMjAxNiAxODo1MywgIlRMUyBv biBiZWhhbGYgb2YgQ2VkcmljIEZvdXJuZXQiDQo+PHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJl aGFsZiBvZg0KPmZvdXJuZXRAbWljcm9zb2Z0LmNvbT4gd3JvdGU6DQo+Pg0KPj4NCj4+QmVzaWRl cywgaW4gb3VyIGFuYWx5c2lzIG9mIHRoZSBoYW5kc2hha2UsIHdlIGdldCBwcmVjaXNlbHkgdGhl IHNhbWUNCj4+4oCcZnJlc2gsIG5ldmVyLXVzZWQgc2VjcmV04oCdIHByb3BlcnR5IHlvdSBhcmUg YWR2b2NhdGluZywgd2l0aCBvcg0KPj4gd2l0aG91dCB0aGUgc2ltcGxpZmljYXRpb24sIGVhY2gg dGltZSB0aGUgaGFuZHNoYWtlIHByb3ZpZGVzIGtleXMgdG8gdGhlDQo+PnJlY29yZCBsYXllci4g VGhlc2UgcG9pbnRzIGFyZSB3ZWxsLXNwZWNpZmllZCBhbmQgZGVsaW1pdGVkLiBUaGV5IGp1c3Qg ZG8NCj4+bm90IGNvaW5jaWRlIHdpdGggdGhlIGVuZCBvZiB0aGUgaGFuZHNoYWtlLiBTbyBJIGRv buKAmXQgc2VlIGFueQ0KPj5mdW5kYW1lbnRhbCBkaWZmZXJlbmNlIGluIHRlcm0gb2YgZ2VuZXJp Yy1zZWN1cml0eS4NCj4+DQo+PldlIGFyZSBsZWZ0IHdpdGggc2NlbmFyaW9zIHdoZXJlYnkgdGhl IHJlY29yZCBsYXllciwgZ2l2ZW4gYm90aCB0aGUNCj4+aGFuZHNoYWtlIGFuZCBhcHBsaWNhdGlv bi1kYXRhIHRyYWZmaWMga2V5cywgc29tZWhvdyBsZWFrcyBvbmx5DQo+PiBvbmUgb2YgdGhlIHR3 by4gSSBkb27igJl0IG1pbmQga2VlcGluZyB0aGUga2V5IGNoYW5nZSBpZiBzb21lb25lIGlzDQo+ PmNvbmNlcm5lZCBhYm91dCBpdC4NCj4NCj5MaWtlIEh1Z28sIEkgYW0gYWxzbyBjb25jZXJuZWQg YWJvdXQgcmVtb3ZpbmcgdGhlIGtleSBjaGFuZ2UuIExldCBtZSB0cnkNCj50byBleHBsYWluIHdo eS4NCj4NCj5JIHdvdWxkIGVtcGhhc2lzZSB0aGUgcG9pbnQgdGhhdCB3aGlsZSB3ZSAqY2FuKiBw cm92aWRlIGZvcm1hbCBzZWN1cml0eQ0KPmFuYWx5c2VzIGluIHRoZSBzaXR1YXRpb24gd2hlcmUg dGhlIGFwcGxpY2F0aW9uIGtleSBpcyB1c2VkIGR1cmluZyB0aGUNCj5oYW5kc2hha2UgaXRzZWxm LCBpdCBpcyBtYWRlIHNpZ25pZmljYW50bHkgbW9yZSBjb21wbGV4Lg0KPg0KPkluIHBhcnRpY3Vs YXIsIGl0IG1lYW5zIHdlIGNhbm5vdCBzaW1wbHkgY29tYmluZSBzZWN1cml0eSByZXN1bHRzIGFy aXNpbmcNCj5mcm9tIHNlcGFyYXRlIGFuYWx5c2VzIG9mIHRoZSBIYW5kc2hha2UgUHJvdG9jb2wg YW5kIG9mIHRoZSBSZWNvcmQNCj5Qcm90b2NvbCB0byBvYnRhaW4gc2VjdXJpdHkgZ3VhcmFudGVl cyBmb3IgdGhlIGNvbXBvc2l0aW9uIG9mIHRoZXNlIHR3bw0KPnByb3RvY29scy4gU28gZm9yIGV4 YW1wbGUsIGlmIHdlIGNob3NlIHRvIHJlZmluZSBvdXIgbW9kZWxsaW5nIG9mIHRoZQ0KPlJlY29y ZCBQcm90b2NvbCBpbiBzb21lIHdheSwgdGhlbiB3ZSB3b3VsZCBuZWVkIHRvIHJlLWRvIHRoZSBh bmFseXNpcyBvZg0KPlRMUyAoSGFuZHNoYWtlICsgUmVjb3JkIFByb3RvY29scykgYXMgYSBtb25v bGl0aGljIGVmZm9ydC4gVGhhdCdzIGhhcmQNCj53b3JrIGFuZCBlcnJvciBwcm9uZS4gVGhpcyBz aXR1YXRpb24gd291bGQgbm90IGFyaXNlIGlmIHRoZSBhcHBsaWNhdGlvbg0KPmtleXMgd2VyZSBO T1QgdXNlZCBpbiB0aGUgaGFuZHNoYWtlLg0KPg0KPlRoaXMgaXMgbm90IG1lcmVseSBhIGNvbmpl Y3R1cmVkIGlzc3VlLiBBcyBvbmUgZXhhbXBsZSwgc2V2ZXJhbCBwYXBlcnMNCj4oaW5jbHVkaW5n IFsxLDJdKSBpbiB0aGUgInByb3ZhYmxlIHNlY3VyaXR5IiBwYXJhZGlnbSBoYXZlIHVzZWQgdGhl IEFDQ0UNCj5mcmFtZXdvcmsgYXMgYSBzZWN1cml0eSBtb2RlbCB3aXRoaW4gd2hpY2ggdG8gY29u ZHVjdCBhbmFseXNpcyBvZg0KPmZyYWdtZW50cyBvZiBwcmV2aW91cyB2ZXJzaW9ucyBvZiBUTFMu IEFDQ0Ugd2FzIHNwZWNpZmljYWxseSBkZXNpZ25lZCB0bw0KPmRlYWwgd2l0aCBrZXlzIHRoYXQg YXJlIHVzZWQgYWNyb3NzIHRoZSBIYW5kc2hha2UgYW5kIHRoZSBSZWNvcmQNCj5wcm90b2NvbHMu IEJ1dCBBQ0NFIHZpZXdzIHRoZSBSZWNvcmQgUHJvdG9jb2wgaW4gYSBwYXJ0aWN1bGFyIHdheSAt DQo+ZXNzZW50aWFsbHkgYXMgYSBzdGF0ZWZ1bCBlbmNyeXB0aW9uIHNjaGVtZSB0aGF0IHByb2Nl c3NlcyAiYXRvbWljIg0KPm1lc3NhZ2VzLiBUaGlzIG1vZGVsbGluZyBkb2VzIG5vdCB0YWtlIGlu dG8gZnVsbCBhY2NvdW50IHRoZSBzdHJlYW1pbmcNCj5uYXR1cmUgb2YgdGhlIFRMUyBSZWNvcmQg UHJvdG9jb2wgLSBpbiBmYWN0LCB3aGF0IHRoZSBSZWNvcmQgUHJvdG9jb2wNCj5hY3R1YWxseSBn dWFyYW50ZWVzIGlzIHNpZ25pZmljYW50bHkgZGlmZmVyZW50IGZyb20gd2hhdCBpcyBpbXBsaWVk IGJ5IHRoZQ0KPkFDQ0UgbW9kZWxsaW5nIG9mIGl0IC0gc2VlIFszXSBmb3IgZGV0YWlscywgYW5k IGFsc28gdGhlIGNvb2tpZSBjdXR0ZXINCj5hdHRhY2sgZnJvbSB0aGUgVHJpcGxlIEhhbmRzaGFr ZXMgcGFwZXIgZm9yIGFuIGV4YW1wbGUgb2Ygd2hhdCBjYW4gZ28NCj53cm9uZy4NCj4NCj5PbmUg aW1wbGljYXRpb24gb2YgdGhpcyBpcyB0aGF0IHRoZSByZXN1bHRzIG9mIFsxLDJdIGZvciBleGlz dGluZyB2ZXJzaW9ucw0KPm9mIFRMUyByZWFsbHkgbmVlZCB0byBiZSByZXdvcmtlZCBpbiBhIG1v ZGlmaWVkIHZlcnNpb24gb2YgdGhlIEFDQ0UNCj5mcmFtZXdvcmsgdGhhdCBiZXR0ZXIgcmVmbGVj dHMgdGhlIHN0cmVhbWluZyBuYXR1cmUgb2YgdGhlIFJlY29yZA0KPlByb3RvY29sLiBUaGF0IG5l ZWQgZm9yIHJld29yayB3b3VsZCBoYXZlIGJlZW4gYXZvaWRlZCBoYWQgVExTIG5vdCB1c2VkDQo+ YXBwbGljYXRpb24ga2V5cyBpbiB0aGUgSGFuZHNoYWtlIFByb3RvY29sLCBiZWNhdXNlIHRoZSBj b21wb3NpdGlvbmFsDQo+Z3VhcmFudGVlcyB3b3VsZCBoYXZlIGVuYWJsZWQgdXMgdG8gInBsdWcg YW5kIHBsYXkiIHdpdGggb3VyIHJlc3VsdHMuDQo+DQo+VGhlIHNhbWUgcGVydGFpbnMgaW4gVExT IDEuMyBnb2luZyBmb3J3YXJkOiBrZWVwaW5nIHRoZSBzdHJpY3Qga2V5DQo+c2VwYXJhdGlvbiAt IG5vIHVzZSBvZiB0aGUgYXBwbGljYXRpb24ga2V5cyBpbiB0aGUgSGFuZHNoYWtlIC0gd2lsbCBt YWtlDQo+ZnV0dXJlIC0gYW5kIG9uLWdvaW5nIC0gYW5hbHlzZXMgb2YgVExTIDEuMyBlYXNpZXIu IFRoaXMgaXMNCj5ub3R3aXRoc3RhbmRpbmcgdGhlIGZhY3QgdGhhdCBzZXZlcmFsIHJlc2VhcmNo IHRlYW1zLCBpbmNsdWRpbmcgQ2VkcmljJ3MNCj5hbmQgWzEsMl0gYmVsb3csIGhhdmUgbWFuYWdl ZCB0byBwcm9kdWNlIGFuYWx5c2VzIHRoYXQgZG8gaGFuZGxlIHRoZSB1c2UNCj5vZiB0aGUgYXBw bGljYXRpb24ga2V5IGluIHRoZSBIYW5kc2hha2UuDQo+DQo+UmVnYXJkcywNCj4NCj5LZW5ueQ0K Pg0KPlsxXSBUaWJvciBKYWdlciwgRmxvcmlhbiBLb2hsYXIsIFN2ZW4gU2Now6RnZSwgSsO2cmcg U2Nod2Vuay4gT24gdGhlDQo+U2VjdXJpdHkgb2YgVExTLURIRSBpbiB0aGUgU3RhbmRhcmQgTW9k ZWwuIENSWVBUTyAyMDEyLg0KPlsyXSBIdWdvIEtyYXdjenlrLCBLZW5uZXRoIEcuIFBhdGVyc29u LCBIb2V0ZWNrIFdlZS4gT24gdGhlIFNlY3VyaXR5IG9mDQo+dGhlIFRMUyBQcm90b2NvbDogQSBT eXN0ZW1hdGljIEFuYWx5c2lzLiBDUllQVE8gKDEpIDIwMTMuDQo+WzNdIE1hcmMgRmlzY2hsaW4s IEZlbGl4IEfDvG50aGVyLCBHaW9yZ2lhIEF6enVycmEgTWFyc29uLCBLZW5uZXRoIEcuDQo+UGF0 ZXJzb246IERhdGEgSXMgYSBTdHJlYW06IFNlY3VyaXR5IG9mIFN0cmVhbS1CYXNlZCBDaGFubmVs cy4gQ1JZUFRPICgyKQ0KPjIwMTUuDQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj5UTFMgbWFpbGluZyBsaXN0DQo+VExTQGlldGYub3JnDQo+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCj4NCj4NCj4NCj4NCj4N Cj4NCj4NCg0K From nobody Sun Feb 21 09:29:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522201A8994 for ; Sun, 21 Feb 2016 09:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 bPBQ7p0su8q4 for ; Sun, 21 Feb 2016 09:29:50 -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 DA1DD1A898C for ; Sun, 21 Feb 2016 09:29:49 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id g127so103115615ywf.2 for ; Sun, 21 Feb 2016 09:29:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=TH/mg8/vfZkbiDQ09zR9MUJydi87RpEdqN/H8iZA4Iw=; b=m9uUMAjbMAGlyT/j/u6k7ycjMLJl+9X+lMLP7Pfvssbn+3OYpW00GK7grZJk1PaUJi TZiez5bau0qnu5W/pvmBoDpY4wQOP8Mvlr2N8n2dKAiHo53rL9hW44eUyNrdtpiDY5c8 5Y8ycLjXN7wEblwCudc0yJ3zGmo/7+1HQY2cI= 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-type; bh=TH/mg8/vfZkbiDQ09zR9MUJydi87RpEdqN/H8iZA4Iw=; b=lyF/0r+tLUJ/zZfwQqxoCEsN73aKeiiQYCZl60GrQ/A7vuvpRZ+Q/uzXJw41m8Ld+C GuZ43IYUI6k3/8wczkMNUih/sSvwGxJ5FalxQ3obMnYFI3VcqXtrasCxnlNtRePV0O4g iw7HHQ8b1kMCEPf4xlQZdxTkL8tC/YmAp7GITe2iXHdVPYeNUCl4/d4Au5jLmRkjHLPY hInhjFlIM3qXQw/HmQnk08IHBX3V9Semefkh7IqD27kT37altncY9PzVo0yqi9c7kXpe Utd5BsMQmd+c+gNLoyYbQbzsPReeNyupSwve0P0rzQDtTOj6WmgkJW0+yFSwIpjVv3Jk dhXg== X-Gm-Message-State: AG10YOT50TXerKtFF+NqZPUPTMKDDs/tQSYQPZ8a2M2IfI9EqSZa5wmuJWJgFxgYFR1ZuLVoDItdfD8TVHxuTOE5 X-Received: by 10.13.225.5 with SMTP id k5mr13431274ywe.316.1456075789153; Sun, 21 Feb 2016 09:29:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.86.67 with HTTP; Sun, 21 Feb 2016 09:29:29 -0800 (PST) In-Reply-To: <201602191815.10375.davemgarrett@gmail.com> References: <201602191708.20869.davemgarrett@gmail.com> <201602191815.10375.davemgarrett@gmail.com> From: Nick Sullivan Date: Sun, 21 Feb 2016 09:29:29 -0800 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=94eb2c0765fa2dc3ee052c4b106b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Do we actually need semi-static DHE-based 0-RTT? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 17:29:52 -0000 --94eb2c0765fa2dc3ee052c4b106b Content-Type: text/plain; charset=UTF-8 On Fri, Feb 19, 2016 at 3:15 PM, Dave Garrett wrote: > On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote: > > My impression is exactly the opposite. All the infrastructure to > PSK-resumption and > > hence PSK-0RTT is already in place for TLS 1.2. And of course > PSK-resumption > > is also much faster. > > That's good to hear. The perf advantage is why I'm not advocating dropping > it; merely saying that I too would prefer a single method if it didn't > loose capability. Dropping PSK resumption drops less than dropping DHE > 0RTT, but keeping both seems like the best option at the moment. > > > On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett > wrote: > > > It would mean that TLS only has 0RTT resumption and not actually have > any 0RTT sessions. > > > > Why do you think that this makes a material difference? > > One of the fundamental complaints about TLS, performance-wise, is the > added round trip time over plaintext. That's why the WG made a point to > focus on adding 0RTT in the first place. Someone considering upgrading from > HTTP to HTTPS generally has this concern (or any other protocol to a > variant over TLS). With only PSK resumption, we can still always have a > 1RTT hit on first connection, and revert to that after the session is > considered expired. With DHE 0RTT we have a longer term config that could > allow for more generic caching and distribution and thus not have to get > that 1RTT hit in many scenarios. > > The lack of a current ability to easily distribute a new config system > should not be used as evidence against creating a new config system that we > would want to create a way to easily distribute. Even dumping the top few > dozen sites' 0RTT DHE config into a static file in a client update would be > a noticeable improvement over not doing so. Coming up with a better method > can come next. > I don't think distributing the 0RTT semi-static DHE config for a set of top sites using a file is a realistic use case. As Eric said, for each active DH share, the server has a long-term key floating around which is a risk to PFS. Keeping these keys around for longer than the recommended 7 days is not a good practice. If the semi-static secrets are rotated at this rate, this increases the rate at which clients will have to download the configuration file. For everything other than these few dozen sites, the first connection will still be 1RTT. Clients who want 0RTT with these top sites might as well just establish a session out of band and then use 0RTT PSK. > > People should be using TLS or encryption in general as a matter of > responsibility, but they don't. Softening *all* barriers to them upgrading > is very necessary to get more to switch. 0RTT PSK only gets rid of a delay > in continuing a session, which in some use-cases might be minimally > noticeable. 0RTT DHE allows for a first-connect with comparable speed to > plaintext (in scenarios where 0RTT data is safe, namely most HTTP). Within > the context of HTTP, which is singled out as a focus in the TLS WG charter, > 0RTT DHE will provide a more noticeable latency reduction in comparison to > 0RTT PSK only This assumes that there is a reasonable concrete scenario for distributing the semi-static DH share. It is not clear that this use case exists. Any use case we find to distribute semi-static secrets out of band needs to handle authentication, key freshness, and provide a latency improvement over simply priming the connection with a full handshake. At the very least, we should consider removing the ServerConfiguration distribution as part of the TLS handshake. It is only useful for establishing 0-RTT in resumption connections, and there is already a method for 0-RTT resumption using PSK. Having a two ways in TLS to distribute key material to prime 0-RTT for resumed connections is redundant. > > Another issue is that of privacy with session resumption. If the only way > to get 0RTT is to keep sessions alive, then clearing that cache on the > client side costs a future 1RTT. You can, however, cache 0RTT DHE configs > safely for a longer time because they are not specific to the user agent. > (we should probably narrow the spec to state that configs SHOULD NOT be > per-client) In order to reliably get 0RTT without DHE configs, > applications/services would need to cache PSK resumption sessions for as > long as possible, which leaves a distinct per-user marker on both the > client and server. Anyone trying to optimize away the 1RTT hit of > first-connect will be required to maintain a system that keeps more user > identifiable information than we should want. > > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0765fa2dc3ee052c4b106b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 19, 2016 at 3:15 PM, Dave Garrett <davemgarrett@gmail= .com> wrote:
On Friday, February 19, 2016 05:24:25 pm Eric Rescorl= a wrote:
> My impression is exactly the opposite. All the infrastructure to PSK-r= esumption and
> hence PSK-0RTT is already in place for TLS 1.2. And of course PSK-resu= mption
> is also much faster.

That's good to hear. The perf advantage is why I'm not advoc= ating dropping it; merely saying that I too would prefer a single method if= it didn't loose capability. Dropping PSK resumption drops less than dr= opping DHE 0RTT, but keeping both seems like the best option at the moment.=

> On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett <davemgarrett@gmail.com> wrote:
> > It would mean that TLS only has 0RTT resu= mption and not actually have any 0RTT sessions.
>
> Why do you think that this makes a material difference?

One of the fundamental complaints about TLS, performance-wise, is th= e added round trip time over plaintext. That's why the WG made a point = to focus on adding 0RTT in the first place. Someone considering upgrading f= rom HTTP to HTTPS generally has this concern (or any other protocol to a va= riant over TLS). With only PSK resumption, we can still always have a 1RTT = hit on first connection, and revert to that after the session is considered= expired. With DHE 0RTT we have a longer term config that could allow for m= ore generic caching and distribution and thus not have to get that 1RTT hit= in many scenarios.

The lack of a current ability to easily distribute a new config system shou= ld not be used as evidence against creating a new config system that we wou= ld want to create a way to easily distribute. Even dumping the top few doze= n sites' 0RTT DHE config into a static file in a client update would be= a noticeable improvement over not doing so. Coming up with a better method= can come next.

I don't think distributing the= 0RTT semi-static DHE config for a set of=20 top sites using a file is a realistic use case. As Eric said, for each acti= ve DH=20 share, the=C2=A0server has a long-term key= =C2=A0floating around which is a risk to PFS. Keeping these keys around for longer=20 than the recommended 7 days is not a good practice. If the semi-static=20 secrets are rotated at this rate, this increases the rate at which=20 clients will have to download the configuration file. For everything=20 other than these few dozen sites, the first connection will still be=20 1RTT. Clients who want 0RTT with these top sites might as well just=20 establish a session out of band and then use 0RTT PSK.
=C2=A0

People should be using TLS or encryption in general as a matter of responsi= bility, but they don't. Softening *all* barriers to them upgrading is v= ery necessary to get more to switch. 0RTT PSK only gets rid of a delay in c= ontinuing a session, which in some use-cases might be minimally noticeable.= 0RTT DHE allows for a first-connect with comparable speed to plaintext (in= scenarios where 0RTT data is safe, namely most HTTP). Within the context o= f HTTP, which is singled out as a focus in the TLS WG charter, 0RTT DHE wil= l provide a more noticeable latency reduction in comparison to 0RTT PSK onl= y

=
This assumes that there is a reasonable concrete scenario for distributing the semi-static DH share. It is not clear that this use case exists. Any use case we find to distrib= ute semi-static secrets out of band needs to handle authentication, key fre= shness, and provide a latency improvement over simply priming the connectio= n with a full handshake.

At the very least, we should con= sider removing the ServerConfiguration distribution as part of the TLS hand= shake. It is only useful for establishing 0-RTT in resumption connections, = and there is already a method for 0-RTT resumption using PSK. Having a two = ways in TLS to distribute key material to prime 0-RTT for resumed connectio= ns is redundant.
=C2=A0

Another issue is that of privacy with session resumption. If the only way t= o get 0RTT is to keep sessions alive, then clearing that cache on the clien= t side costs a future 1RTT. You can, however, cache 0RTT DHE configs safely= for a longer time because they are not specific to the user agent. (we sho= uld probably narrow the spec to state that configs SHOULD NOT be per-client= ) In order to reliably get 0RTT without DHE configs, applications/services = would need to cache PSK resumption sessions for as long as possible, which = leaves a distinct per-user marker on both the client and server. Anyone try= ing to optimize away the 1RTT hit of first-connect will be required to main= tain a system that keeps more user identifiable information than we should = want.

=C2=A0


Dave

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

--94eb2c0765fa2dc3ee052c4b106b-- From nobody Sun Feb 21 11:31:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D28C1A21A1 for ; Sun, 21 Feb 2016 11:31:06 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tDBZf52a5Wxw for ; Sun, 21 Feb 2016 11:31:05 -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 DB9011A8748 for ; Sun, 21 Feb 2016 11:31:04 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id g203so157388382iof.2 for ; Sun, 21 Feb 2016 11:31:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SVS4nvvldvkYEVrkmUOgb3i8BNRup6eXiObJoEpQ+u0=; b=GEkwoEFZOvUtd1LC/OLvCeCL5Y6MOt+NhVVA9RDHmyp6NTKuzCooVYHvFTheioxsy0 liO0rG+9g37Nk7xmqjA1DSBI9nniFhzzTyFjd6D3H9u07T62dlq5082AGn8XqmHcwjIv /KMnqbnA/+ikNQx1dnrdhrtAwer9/SOrPHIqCKgQeEcTpqsDbCf3eDBBVBP21NP9eglB 9cUZAp2UUnHtyKI3CPkQhMpHGjL2V/cC+qDsU1+pBs7QK29D4VPTEP0vSxwW4zg8BMIW zQGfnvXhHWjMjwJXxjHTD4Baa7XDQaIKvYMKWXIYzrYPyHq8fdubAZXgUTyP4dyXB1wQ iH3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=SVS4nvvldvkYEVrkmUOgb3i8BNRup6eXiObJoEpQ+u0=; b=fdXQT2ZW5Ixw4x/bOj2PGeKn+MTAT1EDUsdo4dVeODf95FYt+rO4h7729GEg3WEW3d MJtifRneS8pi9QhQwnm/DAHSGqUM99JwyJLm9zFDrgfj3YuUiaeS2EZjbhxdEEPpesF0 L6ZX63+83tEOyvlAgt0amGZG4rrLNr9GLxLExTZfTtUfN1SXc6quN+w/rjj/kMG4dJMt yl0o3CxGE2LmXi36u1PdRW3EbVRpNi0Nu1QaGQRWPzZzCtsvI1QDkbzMmvzdwzLN6ZeU dQDWP1Uzq4OJ1k6cuH2dfMX9jNNaDnAYmZpAS7GiAOe64bvSPkVAy6kXl+NEB4PpmUrg LemA== X-Gm-Message-State: AG10YOSmVQ7Ms1FVhGnIiP2f0bLAiXTMzx5S05l9FWkCTxHSUlSnN+PmOLIEJWkC5+uR2wJm2VyemclaUzez6Q== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr26137298iod.190.1456083064278; Sun, 21 Feb 2016 11:31:04 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 21 Feb 2016 11:31:04 -0800 (PST) Date: Sun, 21 Feb 2016 11:31:04 -0800 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:31:06 -0000 I'm sitting here in TRON listening to Karthik describe all the various ways in which client authentication in 0-RTT is bad. I'm particularly sympathetic to the perpetual impersonation attack that arises when the client's ephemeral key is compromised. We originally thought that we might want to do this for WebRTC/real-time. As it so happens, we have an alternative design that doesn't need this, so... I propose that we remove client authentication from 0-RTT. This should simplify the protocol considerably. https://github.com/tlswg/tls13-spec/issues/420 [1] Compromising the server's long term key has the same impact, but that's interesting for other, worse reasons. From nobody Sun Feb 21 11:34:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9726D1A8963 for ; Sun, 21 Feb 2016 11:33:59 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lDcsWbANs6cI for ; Sun, 21 Feb 2016 11:33:58 -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 404BC1A88C7 for ; Sun, 21 Feb 2016 11:33:58 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id e63so103876192ywc.3 for ; Sun, 21 Feb 2016 11:33:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=8ZEjEhc6BHxNMju4YEuDHnX1TVoz5nn2/lAdPTCdEDo=; b=sfJKKjyPIMevB2MSvIlKhzRu7kfnoMqRDPRjH/4DvsNGHwug9cd9N5lAeujn7OSlG4 YIFk8tAibs7z8S4ZYK98hv3F1XmMkMcyUIRxzRv9OCIxr+6ONt/tjXfH0jkooI0dV3M3 TkcDNXtUTh+X8hQCMSt0LZlQz13lhkcNaVq6XK/IZkijsnOZ6vXQDN2kJt21yu/i4h4D kI9byNe/3cMJwoz9eI6FRkFrACAVwLRA8HY5ZLk/6zUMEFQ1bTceNxMonnz5ZDZYJxVv vqlwXZB5R/W0MvLBUdzr7ZVyaEHx1L6kcKvR2r3VoZjstp7i3NvHxb2+JOUP0Dm+3e+a yFsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=8ZEjEhc6BHxNMju4YEuDHnX1TVoz5nn2/lAdPTCdEDo=; b=D/dp6CgTos8Lzo+sgB6lSaaXTbvgJdbh1ADhjjHl3vCOIm1GFkl4SCXjdkZBz0jX1r 04ZKc+zdsJufSe46+v3cSXgeuYEIiNonFVYV+obiSAR2ZAZ+w0F8TdOmZ7lLfSeMXhhD +OC3ihOhcMaZv4vrD2BRN/piGfklpRP4nECFlratn65oYV8RjLLQ5UjYr4GsfT2HQxdz sUl8VVD9Wj1UF9QfKXlDGE3Daxw5y4l0SOZWpn9cL0VDIPx9+R/cRacQQJuH7zR9ztJd zUyqb5eCVfShQ+zFUrwdC//pgZf71+2MdOuxsQ7bAvHEWGRmNiVlyA1uXDmXGZxoCMit x4/A== X-Gm-Message-State: AG10YOQiLYAObeZiki125/ctkNRJuco2gq3EdJb+/X5TrACj5ZWpBCg7fa5JJ8YEeXJaXZjRcox9cWx2vPLB1w== MIME-Version: 1.0 X-Received: by 10.129.45.2 with SMTP id t2mr12135916ywt.182.1456083237581; Sun, 21 Feb 2016 11:33:57 -0800 (PST) Received: by 10.13.216.138 with HTTP; Sun, 21 Feb 2016 11:33:57 -0800 (PST) Date: Sun, 21 Feb 2016 11:33:57 -0800 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Unified Client Authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:33:59 -0000 Currently we client authenticate after handshake and during handshake. Why not unify these by making all client authentication take place after the handshake? This will simplify the state machine. https://github.com/tlswg/tls13-spec/issues/421 talks about this in the last sentence. From nobody Sun Feb 21 11:37:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 283F51A884E for ; Sun, 21 Feb 2016 11:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 h34jR64nOydh for ; Sun, 21 Feb 2016 11:37:46 -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 BAC161A8769 for ; Sun, 21 Feb 2016 11:37:46 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id h129so104254384ywb.1 for ; Sun, 21 Feb 2016 11:37:46 -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:content-type; bh=1faBscK4w0afw71tgt2QSShusrPf6cm3Ee+5kC7PkXU=; b=mhWhuAlAXx+P5IR35DaUebAvclHPoELoNnEyRgfhmrypgQJu4c1troNS0sQWlXEq4t hTfII3flliGjVviDu3fiXg+hprn2Pms1EMvefupZrjtnEiYYwcCkgNZr2AHbPtEcqYin CBUDx6TGo2rS7W0sNlN/6xamEheir8COLq9hefk1/soursNPxhd1oMOo/bBr5o+hnFQa q6upatMSlgp77Ca9mE83ozTkGdP/rzk73x375y7KSyTK6ktqnli2TYYF3tfHm76x+MOD 8PX0JzfWg0Q7ha02suw99JDbl3I3Z9P454hv9SOlmr+6PJAr9KPYUq9i+4CVNL5fUz6V TmJQ== 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-type; bh=1faBscK4w0afw71tgt2QSShusrPf6cm3Ee+5kC7PkXU=; b=N1BCwYGU9NMl/TqQ7PQDkmHh+ayo7mXv2sxhpxz/vCg+rbSyC9knuZHEHepmd5mTNj XgDFtYr8Teuh00cQKE3mtdbajmwu5e7ToFIuWy1AfsrV8T++thKwIMZnnURDbylQBnry a1buhT/rnCLrEeoo+yjPnfqbNfsMdbOoHe5usPg9RHUi9QWfuSx3ehBEGOWpHPPGqjB1 qbQuQsBTSd0hUa8tNdLuNe7wEKlAPiViqCGK6RFq22XM5FHjTXnl3zTXVqw6R5hWRd8f XQ6fOqcN9KQLaKdQ85vuQIfyLMb0uY20bCq2K2kpFpMbIj/WN29O1zPCsQ5mQT2eWavl MZKA== X-Gm-Message-State: AG10YOTO7Z2R8yCnZSj2nwm7P2/Kc1kjrddomr1Y4xHK/Nkd5siE9kcReNa1H3Ee7mu9pBg6Sv3ghiH5VeX6bA== X-Received: by 10.13.221.132 with SMTP id g126mr13992037ywe.231.1456083465995; Sun, 21 Feb 2016 11:37:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 21 Feb 2016 11:37:06 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 21 Feb 2016 11:37:06 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0613b8c1ec9c052c4cd984 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:37:48 -0000 --94eb2c0613b8c1ec9c052c4cd984 Content-Type: text/plain; charset=UTF-8 +1 On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson wrote: > I'm sitting here in TRON listening to Karthik describe all the various > ways in which client authentication in 0-RTT is bad. I'm particularly > sympathetic to the perpetual impersonation attack that arises when the > client's ephemeral key is compromised. > > We originally thought that we might want to do this for > WebRTC/real-time. As it so happens, we have an alternative design > that doesn't need this, so... > > I propose that we remove client authentication from 0-RTT. > > This should simplify the protocol considerably. > > https://github.com/tlswg/tls13-spec/issues/420 > > [1] Compromising the server's long term key has the same impact, but > that's interesting for other, worse reasons. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0613b8c1ec9c052c4cd984 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
I'm sitting here in TRON listening= to Karthik describe all the various
ways in which client authentication in 0-RTT is bad.=C2=A0 I'm particul= arly
sympathetic to the perpetual impersonation attack that arises when the
client's ephemeral key is compromised.

We originally thought that we might want to do this for
WebRTC/real-time.=C2=A0 As it so happens, we have an alternative design
that doesn't need this, so...

I propose that we remove client authentication from 0-RTT.

This should simplify the protocol considerably.

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

[1] Compromising the server's long term key has the same impact, but that's interesting for other, worse reasons.

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

--94eb2c0613b8c1ec9c052c4cd984-- From nobody Sun Feb 21 11:39:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 841111A90BD for ; Sun, 21 Feb 2016 11:39:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 1yN5_OiLzEmC for ; Sun, 21 Feb 2016 11:39:39 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52CEF1A90BA for ; Sun, 21 Feb 2016 11:39:39 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id h129so104273314ywb.1 for ; Sun, 21 Feb 2016 11:39: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:content-type; bh=PmZPlr79JvXT2QN2X3oPhwoQXaukjb/qwg8+HqLXM/I=; b=PrdlYB0GX5OiUQzaTDzr4dudL8JQDmZuAYLRcQixdjweWO0EwPXwiuzwtksborPRQc tjHlKHC8bC1rcQQzRTfK7MMCBJLuiAtm990uc56sYuuiwAe7Mn84sDQL8vRjzSbgk1ah uLVfZII+cVMjm1YZV0KA553TLstr3i9hJSGFkNZBsITjWAXoESD+whQ36m5N3ZjH4YNC sepDeVCNesownFbt5qn7fDXLq3JE1P0WENPQw/L461OfQmrDuiu2JDknyWOMrv8wFt/s 02Y3SGgYC1b2n5QPYB0tglt6V9GmdOA/4y2KdtAHOJHbl3S/6oG9UCQTVMib7RHKbSQE IXGA== 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-type; bh=PmZPlr79JvXT2QN2X3oPhwoQXaukjb/qwg8+HqLXM/I=; b=O8XIgWstRNvq6FKZCCKI80GBvO4GdFewpLUdq9IYCmwb+jydcJSXeMHRfNniuUApKx eVDC/Sq8AbUevtB5a9WNEzz7fYVvmRLtklGFZF8eyeT7FsFZSDSFTaFuiKPxkWMqDMWv 0FnBYot3k8XbHmV9azE+sreVquGAUW+4+o9BswjMAGlnOgZVDP/wilN+E9FBkPStPmb0 NGH/ug2e49vfxFwQ1vPSyBDITAZ0akKl/s1ahlslBX5dsIsnntRFYUzaVwhqGmqpK9wM KZeJ9GQ1l/OQCfmf4jXsJXsHYb3EoX2W5Fo/Ic78FSnSeGsWEk6U82j3eGvohH++m3a2 cfCg== X-Gm-Message-State: AG10YOTmo4+G6D10XKKb0eaY9QTFiCA4NXVI1m+rtjUbTxJDpHi9PAC/kZXr0TaElDtvVcKFsnI6luy+NW6LVg== X-Received: by 10.129.38.135 with SMTP id m129mr11871584ywm.155.1456083578718; Sun, 21 Feb 2016 11:39:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 21 Feb 2016 11:38:59 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 21 Feb 2016 11:38:59 -0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1141618c793b43052c4ce07a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Unified Client Authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:39:40 -0000 --001a1141618c793b43052c4ce07a Content-Type: text/plain; charset=UTF-8 This was discussed at the TLS interim and the argument against was that there was limited demand for the post-handshake mode and that people wanted to have a mode they were very comfortable with as the "main" thing. Of course, it may be time to revisit that decision. -Ekr On Sun, Feb 21, 2016 at 11:33 AM, Watson Ladd wrote: > Currently we client authenticate after handshake and during handshake. > Why not unify these by making all client authentication take place > after the handshake? This will simplify the state machine. > > https://github.com/tlswg/tls13-spec/issues/421 talks about this in the > last sentence. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1141618c793b43052c4ce07a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This was discussed at the TLS interim and the argument aga= inst was that
there was limited demand for the post-handshake mode and = that people
wanted to have a mode they were very comfortable with= as the "main"
thing. Of course, it may be time to revi= sit that decision.

-Ekr

=

On Sun, Feb 21, 2= 016 at 11:33 AM, Watson Ladd <watsonbladd@gmail.com> wro= te:
Currently we client authenticate afte= r handshake and during handshake.
Why not unify these by making all client authentication take place
after the handshake? This will simplify the state machine.

https://github.com/tlswg/tls13-spec/issues/421 tal= ks about this in the
last sentence.

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

--001a1141618c793b43052c4ce07a-- From nobody Sun Feb 21 11:39:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428661A90E0 for ; Sun, 21 Feb 2016 11:39:54 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mD13E55NgHgL for ; Sun, 21 Feb 2016 11:39:52 -0800 (PST) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001: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 204231A90F7 for ; Sun, 21 Feb 2016 11:39:52 -0800 (PST) Received: by mail-ig0-x235.google.com with SMTP id y8so72827313igp.0 for ; Sun, 21 Feb 2016 11:39:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wwKoZbfI92UYAuW3vMa7urhz2HtyToGn4YOX5iXbQk8=; b=z3WLZr2zGlLh/G9nJGwo4a/DR425zlABISGjzgZwdsIggsyTdMDJcywwwXb5uIEQMe T7hLapLks+B5jqyjwOvetATV+ko6oF8eAc9980bj1clqrgn4nRWkIMxkPyf/TlYBLN3X L8Vlcytu4xuT6OhQmcCQMpmlY+sPM8MFKYJAWkTNxBV0Q+ZHSkxfSI49Vxk1QM3Sf4Rp JKw5Mhcp0YWT072bOxnZHGLrLG6LLeFa5cIMSzfNWaQ1L9xXF85jSMFnWsiYdoWnIlNp xCCV3t02+q/MngNBDk3ff4l/yanCqbZXVRPPOmhqifjUzV4sQIsWGpq1wLbKOnrbvHEh IvHA== 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:date :message-id:subject:from:to:cc:content-type; bh=wwKoZbfI92UYAuW3vMa7urhz2HtyToGn4YOX5iXbQk8=; b=TGZiq6rE4BAda0gD5rL/S6+GvkXEMnZRNSE8OIdKwhWJlOUKHM94/j6BEZYy2j9aVg iPYoq2nixqHF03loYYLcHYfuy44t6mvOdgaYgnSkhiu7E53Prr2Ncy7mrUGQ5f0viypH YneXh3ZrlW5HfZKEJ28/yvn5vQ1BtPOe6gSesOM8WlMrQqrhEMhDcqBqWnnVlSmLuI14 5WDKwi/PvEQuu9Bm5VppoZRc8M3OHQgR8OlWSgUi0nQoN9igbjxrolYpDodmmxm/HbvH GoanC5EKmK1lkqn3R4gm6Pbdh5GaLckpE8Kzebq5yPWJKyZmSSxbExt80u7BUWd3ygDz y6ug== X-Gm-Message-State: AG10YOQUi+DrdjkDlM3MYOCRIJ7EHnGxFwp4/ie7nQHqNzvyciBgbmJh1LR3Oqj3HlHN0NYXcCb/fvxKJ+ZsnQ== MIME-Version: 1.0 X-Received: by 10.50.131.227 with SMTP id op3mr948507igb.94.1456083591561; Sun, 21 Feb 2016 11:39:51 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 21 Feb 2016 11:39:51 -0800 (PST) In-Reply-To: References: Date: Sun, 21 Feb 2016 11:39:51 -0800 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Unified Client Authentication X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:39:54 -0000 On 21 February 2016 at 11:33, Watson Ladd wrote: > Currently we client authenticate after handshake and during handshake. > Why not unify these by making all client authentication take place > after the handshake? This will simplify the state machine. I believe that we discussed this extensively at the last interim. I believe that two views held: 1. post-handshake client auth is an abomination that only exists to support a few niche use cases. 2. doing it after the handshake creates a period of uncertainty for clients, who might receive the server Finished and start to transmit unauthenticated messages before receiving the request Excuse my colloquial description of the problems. From nobody Sun Feb 21 11:42:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 676F11A911A for ; Sun, 21 Feb 2016 11:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wm8uW8g1H20R for ; Sun, 21 Feb 2016 11:42:18 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0709.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::709]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E441A892E for ; Sun, 21 Feb 2016 11:42:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9yr5OUDRkkt8qmN0ckxT8zDlU4f9OMGngY6JCtFMFnA=; b=Q9Z0eX2i5ZPwQi1lGWo2aOYpXk1gITgZYiOikP4tnVrm7U6cSaq66rW2sqKQG+T0LzXZQEcjO+S9mFqu7E+KDNC08vuEVV53neCrTD4Fx6v4zl5hPbLITHPaAbGxfVT3yqh2tWLJKc5LA43SdTqkblDh9ttuvBdYk+VYxLoyFiI= Received: from CH1PR03CA010.namprd03.prod.outlook.com (10.255.156.155) by CY1PR0301MB0619.namprd03.prod.outlook.com (10.160.142.26) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sun, 21 Feb 2016 19:42:01 +0000 Received: from BY2FFO11FD017.protection.gbl (10.255.156.132) by CH1PR03CA010.outlook.office365.com (10.255.156.155) with Microsoft SMTP Server (TLS) id 15.1.409.15 via Frontend Transport; Sun, 21 Feb 2016 19:42:00 +0000 Authentication-Results: spf=pass (sender IP is 206.191.249.68) smtp.mailfrom=microsoft.com; rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=pass action=none header.from=microsoft.com; Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 206.191.249.68 as permitted sender) receiver=protection.outlook.com; client-ip=206.191.249.68; helo=064-smtp-out.microsoft.com; Received: from 064-smtp-out.microsoft.com (206.191.249.68) by BY2FFO11FD017.mail.protection.outlook.com (10.1.14.105) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Sun, 21 Feb 2016 19:41:58 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net (141.251.48.82) by AM3PR30MB052.064d.mgd.msft.net (141.251.48.86) with Microsoft SMTP Server (TLS) id 15.1.415.9; Sun, 21 Feb 2016 19:41:57 +0000 Received: from AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) by AM3PR30MB049.064d.mgd.msft.net ([141.251.48.82]) with mapi id 15.01.0415.019; Sun, 21 Feb 2016 19:41:57 +0000 From: Cedric Fournet To: Eric Rescorla , Martin Thomson Thread-Topic: [TLS] Remove 0-RTT client auth Thread-Index: AQHRbN50NBvYSkhHM0m6iukPWsKB7J825MAAgAAAUjA= Date: Sun, 21 Feb 2016 19:41:56 +0000 Message-ID: <3391c710317b419ab097a291f426b25d@AM3PR30MB049.064d.mgd.msft.net> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.50.5] X-MS-Office365-Filtering-Correlation-Id: 61ea68b0-15cd-40b2-d821-08d33af71016 Content-Type: multipart/alternative; boundary="_000_3391c710317b419ab097a291f426b25dAM3PR30MB049064dmgdmsft_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BY2FFO11FD017; 1:oVCc4Dv6fIwCBDlRJzgajBxTqwo7bqkI0Nk3JXEhv9LAnX6+IHkUdv6YWAa56e9RdMOUV+pv78vwm+K+fBEQKqH/1lgQ5Qmie1rTVdSkejDzrT4qUVP00p/deD0aIrJEgJ05cN5RwnxF3knl6EvdPwUNjPtwrD+6umgi7xJuiHZM/7EqVPeSdtCvaIuFSGbUTs8Z0xD7plFu95jYPAjhqzM6SJyqC3rUwiH7D5xPe6r6tU/hsH6wIk7+Z1CWXk34m68UXrJEfXH82sE+Y4jSd/+31sFNcwiq44xlB0n13Lwh6soJcJRwWHOzp++jVmA4fA6WaDH+gmF1F0GNA1AydmUfjgKleBHlEA8bXaHJDjdlxp117z0loHsmhJxYdR9Z X-Forefront-Antispam-Report: CIP:206.191.249.68; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(2980300002)(438002)(3905003)(377454003)(199003)(24454002)(189002)(586003)(2950100001)(2900100001)(16236675004)(5005710100001)(108616004)(300700001)(6116002)(102836003)(19617315012)(3846002)(790700001)(2906002)(4326007)(92566002)(24736003)(1220700001)(19300405004)(1096002)(19580395003)(16796002)(19580405001)(33646002)(66066001)(15975445007)(50986999)(54356999)(512874002)(5001770100001)(86362001)(575784001)(87936001)(84326002)(5001960100002)(76176999)(11100500001)(19625215002)(189998001)(5003600100002)(10090500001)(6806005)(5008740100001)(106116001)(86612001)(10290500002)(106466001)(10400500002)(86146001)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0301MB0619; H:064-smtp-out.microsoft.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0619; 2:/NQe0g5PZRtXooZ0fQ1BQFPde7PScG4DxNd6z49XQNSv466YpqXoIx5LaniQXWSsD7SgeNBJRczF823dtt9rLxQRf7S0E5M9sm2pCFvIlPjqCNLZMmIFZ4qxz2i+fR0o7+DXERztu2nTyUPva4oEEL6om9q0HLWAmSmJMEZUXYqRr2kbnlMaBxSwe8oWV0vr; 3:aOS2iY1fTUc/pXEHHFKsdaxKD1Sz7ey4xE8Emk4940+iTJ0iNZJdD7HHTxQV2BoF4AsyghZwOsQ0CMG0kb+KYX6b1BRcWaOsmqX7y3frMKMQHsc2AHRPHSa8l2p99p79MMoAQOY9EZ/EKuXNNecjWermSbSgO02smWY7Fr1Tf3GhKv6EFjEtd2xyn71i+EAEbZIsxkVBQh86UVEghqlcLl8PTZk0bHE1pPJe0pa8xxt8ocqTQYlfh+Wu7ibM/0lC98Hw+MdQPDHdi45hTaKsDw==; 25:cUQUMaPz+VZAMlxyRi/bF+dVLlcp6CFX+IG/aqpoQRODOKd7+q/oq6Ji3PfO/RScfnvFnosVWwk2zoLRvHBY0ccFKIr2hHFCdI6aTPtnZOeXSwGnyJiT1oicGhzZNrCgHXQr1iYR9yBNfA6IpYrUzJOrF5cdpv0JFKl73I8oJYw30Jn4Ku5ke+k8U9DJ0+9HuRp0mPXmiYW3+snSl7td0G6r1tGZwHJoXpnuo2THISrqa5YftbpohELe4yqMZA4HGtH/n5mUTB0BeftCzc5Oin1UEShmE2IBJ4gE5bdSYwzAxz5X95yNVNcEhPumK1SwnY6mvJPX2a0GzRgwTGLgbRLZ9HW3MdN0fWokW+QS4oM= X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:CY1PR0301MB0619; X-O365EOP-Header: O365_EOP: Allow for Unauthenticated Relay X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0619; 20:yUzzUrmjqQONKgfBBZ+x9bsWHkxC/2YAaCWvRWlWrahX+HxnDuCwdxVOduTZmFYml30Y6Uf29u2kjH2aUXmH1gmI/oBcT2SFhjWE7CLyODWRR/pqF+ukx9LJQv0VjtALCXXFRUf/FZ87nvJMdR889y4almbcY9ta/r44gM9mxM6IEK61BlMFwk1OV/NITsojLgB/CP16CGu0Ij0CxhI3qeuHaN1oM9hldqf873fNblz70SzIjMARE4Arx/Y2TFkfWl/t1+Chu8iWj7vcZXBf8JuxMizSItLS27em2I5y6prFuIxGhmUoMzbO7VYy+Gr1fzoKG4fGPyD5KZB28hs195bxL6I2QW6IzBrktdMLPQZMF7rIgOXLEWP7cO+TRWNX08pnYBT3miiIeRtZPhdaQwaJxRGkM3dmQK7yIvuXN7nVUXNBrR6i1rUbQCP8IjQND4auZAsuyF+PEfxF0tECD4516i4Az8Om/tRyzh019QqxY21lbhfM9aKJTGkMldKOUzIySdJRy4TpVNaETEnY01+uKVp3/kkc2U5pqHFJoDMCrx7mYnh+s4bCATjZvEd0d8qfTOrtzDE/SwNLjwEqh34xagh4qgHqzTeDnJ4jZ1Q= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(13018025)(5005006)(13021025)(13016025)(13013025)(8121501046)(13023025)(13024025)(3002001)(10201501046)(61426038)(61427038); SRVR:CY1PR0301MB0619; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0301MB0619; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0619; 4:vsIwJ3lZ2VOFKfFsD9oWYdM86UU0ZzVRavls3Iyd7yFc12eZBwcNrYI8TUVNvToRdut2dO1i26nq0OMr1k2IkrG80URXq5rZRDMaYl/obP/YuB55jMS1jrCMZgyEhVJExRhVw8U7S/y4aHa4WlZ36O7sW4APljAmCyRkmmt2Q67iZ8CIRhlnZ1OD709FG0aJg0IHuNFXa7cSjD3oSS86zDG30wtK5LbXQzuGoI8vQrNu+0zQ2iawDKcbxrW/YK/b2uy03iAhB9jGrbN7cXD/iY9e/uBCDaNCbCCqDlybsr/CTeXwor+z/jLqog0PcYv3CgCAF6xdhhAnbbV6kOdJvmYVKWhYMSiOD3eB+q3W30qqK9Hwqtg0cHy4ON6DI1LeUnH16R+41yW0scu5clvGqysDzEEzJWAT1QaxXKOWCVwU0SkXNWC9NZKf70vQZiznDskV6jKMA32dHd8csEKGdaOKgLl9xVz0sy2iYxzLcTy0aUyqbHQWJk2zPVUdfXJJW5vNA9KgDekHg7Pb2/HITFzFv9DjffSKFpY7EHCZq5s= X-Forefront-PRVS: 085956473E X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0301MB0619; 23:l3bwQ1n4KuqGnAiLB2n7AUhqNhML+w3Etbz8QOB?= =?us-ascii?Q?xUI6aQzdK6iymtYhjrxsaP7YKCPowZnkoO7uTeH5q4qjl9X/Mqq49p7s1Xhu?= =?us-ascii?Q?YJoDbZ0ILbFsw1MoSlNiZ9PQopAx8F4Q+JePVsorJKY+ygnP6/dntJ4Ye5i7?= =?us-ascii?Q?frVDfcdldXxCo02ORbpY7Jl/s92NTab9Kj2j/LgPjL/YIhuCkp9ODJgKWBQe?= =?us-ascii?Q?JlfULnK9mll6arePMZTYsCYo4uNe2x5xKyRz/Y1HVhq2hZzJSdqb05rKHN+8?= =?us-ascii?Q?8xbMDHBwJGnTrLmX2LIpNS/TCEWRCP6RnQOV5rqt8ClBKWjmcog1/EITHReD?= =?us-ascii?Q?TyvmFchum6PZG3SkwJqS9Ga8bBpIIpF/pKu/2F2nugTfiEj5M+d71xGDxJ79?= =?us-ascii?Q?O+EtyoALTMcbEhVLlSp4hWsnY5xwQP72WwVN9skQ+c7nTJeOdCh8zxell6j4?= =?us-ascii?Q?/34lwSlqFi2iUxrF5izSm0hlhgNj1tv0ar/KZAkkTHZhnMOHkHBwfZJyUsWs?= =?us-ascii?Q?l17y9rfAk+A3jcu7GbtQRqDoAhkz0mfY8kbNpxVff5T2FmXD0YMZ5dy3afXF?= =?us-ascii?Q?jKfmkivMVHXHGUUABW1pTl2jRv2MqEWAZDuLmuwfYsBtLHAfhHnOazZgXZLB?= =?us-ascii?Q?n81IU3taGxHFYW6MR3KcUCoF5UZtteqDAuNUhIsnoG1pOm7m4R4qWw0hLErB?= =?us-ascii?Q?l2f0D+oFnVfidVV+yOqSaIdPa9IAoPWeOqwV4FE9UuZRD5beITJjVxsfJRDx?= =?us-ascii?Q?fifQL0tP7YLmNNlZJx7ZQeR/lcL4cBb3PHYvSxyT0k1SMdir/59iXe9Rc2bg?= =?us-ascii?Q?kDs7kNrzyht2ANUCuJdWjL/lH5xttjVKDuuyv50jRNra8OW9uZVe99n4TTXh?= =?us-ascii?Q?oK6T4X557zyNJCuK5Vh5it7tCTzPd5/RQxdf87zNSqm1xoBd/FCJwLrf8Pfy?= =?us-ascii?Q?0V9SvyJpvgWTFzPsqdSynlgk+J0dvltveN3EneFEpmCjW+MvucZziguZ/ogD?= =?us-ascii?Q?T8XZV2k6oLdciP0dIVf1TLeRAvEhscsCKtq4lgBsqRV2Py8Y3491yHEJmi6o?= =?us-ascii?Q?twDyqtV8OGvqsRU6eW2k/fI+4cwocXwMh3CAHWidDZCrLjgcS8zTPm6hGj5f?= =?us-ascii?Q?/VTbJPhtQ/aHugzxDcUtGfW6WHEq0cthS4oV2PN4GAw/wNi3NqIJuSVnwisB?= =?us-ascii?Q?auX/3MAZV47oWwsFDQLXwAf+4H3s7bwGRUGLNrfgxzYvnBeqrqVrZd7Zu5gp?= =?us-ascii?Q?5pA2uRKnLKix0c+bYo4E9gv/05dM8cAGur+UcH9Cp+WeIsDNJIMYutYQaNY8?= =?us-ascii?Q?Imr4D7p7PI+SE8VKjArQJy0vn+HR/+u+qJPIi8h8wkU4SL1TeLXlAVIklPLq?= =?us-ascii?Q?BTq/QeihM66+FELqIlDBOEgohczKyPis87pUzvICvhanTf1og7DLE0uCX+w8?= =?us-ascii?Q?rl1nmJiGWgxfM63mmcf1sCVUURMqQxnVOXp79Z0oee6ksmAjg+yJsJvITDpp?= =?us-ascii?Q?85mEaT6CAM+c9Ug=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0301MB0619; 5:npspkzzKhsYFARwLRrBAZov1+lnQ1ij0+D0noC84RqZm33yP9JLRU4zf7/lvpuD2MpRCCrmIhyLVtHd3ZLWVxo89kS+KFrW3Q6T2pFaXFm5UzRZECjnm/qWT4YZWjui7TOVazmJwApbv6SS8C27e0g==; 24:0uRycyeDmZ375Kr6oBPc1Ee+rrZL/kzEUE/WzRDO2xEc3eO1FJK1G6tYJmVgDEJUr00+asG/XSqorf5l7NOmxlbte361i5a245c33y+19V4= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 Feb 2016 19:41:58.7517 (UTC) X-MS-Exchange-CrossTenant-Id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=72f988bf-86f1-41af-91ab-2d7cd011db47; Ip=[206.191.249.68]; Helo=[064-smtp-out.microsoft.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0301MB0619 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:42:24 -0000 --_000_3391c710317b419ab097a291f426b25dAM3PR30MB049064dmgdmsft_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkLiBGb3Igd2hhdCBpdCBpcyB3b3J0aCwgMC1SVFQgd2l0aCBQU0sgd291bGQgc3RpbGwg cHJvdmlkZSBpbXBsaWNpdCBjbGllbnQgYXV0aGVudGljYXRpb24uDQoNCg0KDQpGcm9tOiBUTFMg W21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGEN ClNlbnQ6IDIxIEZlYnJ1YXJ5IDIwMTYgMTk6MzcNClRvOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGlu LnRob21zb25AZ21haWwuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNd IFJlbW92ZSAwLVJUVCBjbGllbnQgYXV0aA0KDQorMQ0KDQpPbiBTdW4sIEZlYiAyMSwgMjAxNiBh dCAxMTozMSBBTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWls dG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpJJ20gc2l0dGluZyBoZXJlIGlu IFRST04gbGlzdGVuaW5nIHRvIEthcnRoaWsgZGVzY3JpYmUgYWxsIHRoZSB2YXJpb3VzDQp3YXlz IGluIHdoaWNoIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiAwLVJUVCBpcyBiYWQuICBJJ20gcGFy dGljdWxhcmx5DQpzeW1wYXRoZXRpYyB0byB0aGUgcGVycGV0dWFsIGltcGVyc29uYXRpb24gYXR0 YWNrIHRoYXQgYXJpc2VzIHdoZW4gdGhlDQpjbGllbnQncyBlcGhlbWVyYWwga2V5IGlzIGNvbXBy b21pc2VkLg0KDQpXZSBvcmlnaW5hbGx5IHRob3VnaHQgdGhhdCB3ZSBtaWdodCB3YW50IHRvIGRv IHRoaXMgZm9yDQpXZWJSVEMvcmVhbC10aW1lLiAgQXMgaXQgc28gaGFwcGVucywgd2UgaGF2ZSBh biBhbHRlcm5hdGl2ZSBkZXNpZ24NCnRoYXQgZG9lc24ndCBuZWVkIHRoaXMsIHNvLi4uDQoNCkkg cHJvcG9zZSB0aGF0IHdlIHJlbW92ZSBjbGllbnQgYXV0aGVudGljYXRpb24gZnJvbSAwLVJUVC4N Cg0KVGhpcyBzaG91bGQgc2ltcGxpZnkgdGhlIHByb3RvY29sIGNvbnNpZGVyYWJseS4NCg0KaHR0 cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvaXNzdWVzLzQyMA0KDQpbMV0gQ29tcHJv bWlzaW5nIHRoZSBzZXJ2ZXIncyBsb25nIHRlcm0ga2V5IGhhcyB0aGUgc2FtZSBpbXBhY3QsIGJ1 dA0KdGhhdCdzIGludGVyZXN0aW5nIGZvciBvdGhlciwgd29yc2UgcmVhc29ucy4NCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0 DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vdGxzPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5v dXRsb29rLmNvbS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxp c3RpbmZvJTJmdGxzJmRhdGE9MDElN2MwMSU3Y0ZPVVJORVQlNDAwNjRkLm1nZC5taWNyb3NvZnQu Y29tJTdjYjhhZmUzNWE2YzhhNGRkN2U0MTMwOGQzM2FmNjdkZTclN2M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3YzEmc2RhdGE9SmlJTlclMmZVb3VMV2NKbjBiJTJmR2pnN21WWkgl MmZHUXhJMVF2T2hBNDJZZHl3RSUzZD4NCg0K --_000_3391c710317b419ab097a291f426b25dAM3PR30MB049064dmgdmsft_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGku TXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlBsYWluVGV4 dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0 IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUg bXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2 IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFw ZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4N CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9 IkVOLUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BZ3JlZWQuIEZvciB3aGF0IGl0IGlzIHdv cnRoLCAwLVJUVCB3aXRoIFBTSyB3b3VsZCBzdGlsbCBwcm92aWRlIGltcGxpY2l0IGNsaWVudCBh dXRoZW50aWNhdGlvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFp bEVuZENvbXBvc2UiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0 Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50Ojwv Yj4gMjEgRmVicnVhcnkgMjAxNiAxOTozNzxicj4NCjxiPlRvOjwvYj4gTWFydGluIFRob21zb24g Jmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IHRsc0BpZXRm Lm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gUmVtb3ZlIDAtUlRUIGNsaWVudCBh dXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIEZlYiAyMSwgMjAx NiBhdCAxMTozMSBBTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSdt IHNpdHRpbmcgaGVyZSBpbiBUUk9OIGxpc3RlbmluZyB0byBLYXJ0aGlrIGRlc2NyaWJlIGFsbCB0 aGUgdmFyaW91czxicj4NCndheXMgaW4gd2hpY2ggY2xpZW50IGF1dGhlbnRpY2F0aW9uIGluIDAt UlRUIGlzIGJhZC4mbmJzcDsgSSdtIHBhcnRpY3VsYXJseTxicj4NCnN5bXBhdGhldGljIHRvIHRo ZSBwZXJwZXR1YWwgaW1wZXJzb25hdGlvbiBhdHRhY2sgdGhhdCBhcmlzZXMgd2hlbiB0aGU8YnI+ DQpjbGllbnQncyBlcGhlbWVyYWwga2V5IGlzIGNvbXByb21pc2VkLjxicj4NCjxicj4NCldlIG9y aWdpbmFsbHkgdGhvdWdodCB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gZG8gdGhpcyBmb3I8YnI+DQpX ZWJSVEMvcmVhbC10aW1lLiZuYnNwOyBBcyBpdCBzbyBoYXBwZW5zLCB3ZSBoYXZlIGFuIGFsdGVy bmF0aXZlIGRlc2lnbjxicj4NCnRoYXQgZG9lc24ndCBuZWVkIHRoaXMsIHNvLi4uPGJyPg0KPGJy Pg0KSSBwcm9wb3NlIHRoYXQgd2UgcmVtb3ZlIGNsaWVudCBhdXRoZW50aWNhdGlvbiBmcm9tIDAt UlRULjxicj4NCjxicj4NClRoaXMgc2hvdWxkIHNpbXBsaWZ5IHRoZSBwcm90b2NvbCBjb25zaWRl cmFibHkuPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL3RsczEz LXNwZWMvaXNzdWVzLzQyMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3 Zy90bHMxMy1zcGVjL2lzc3Vlcy80MjA8L2E+PGJyPg0KPGJyPg0KWzFdIENvbXByb21pc2luZyB0 aGUgc2VydmVyJ3MgbG9uZyB0ZXJtIGtleSBoYXMgdGhlIHNhbWUgaW1wYWN0LCBidXQ8YnI+DQp0 aGF0J3MgaW50ZXJlc3RpbmcgZm9yIG90aGVyLCB3b3JzZSByZWFzb25zLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4N CjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBo cmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0aW5mbyUyZnRscyZhbXA7 ZGF0YT0wMSU3YzAxJTdjRk9VUk5FVCU0MDA2NGQubWdkLm1pY3Jvc29mdC5jb20lN2NiOGFmZTM1 YTZjOGE0ZGQ3ZTQxMzA4ZDMzYWY2N2RlNyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSZhbXA7c2RhdGE9SmlJTlclMmZVb3VMV2NKbjBiJTJmR2pnN21WWkglMmZHUXhJMVF2 T2hBNDJZZHl3RSUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3391c710317b419ab097a291f426b25dAM3PR30MB049064dmgdmsft_-- From nobody Sun Feb 21 11:43:32 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F731A9152 for ; Sun, 21 Feb 2016 11:43:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuDvicKYRWXl for ; Sun, 21 Feb 2016 11:43:29 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001: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 1D5A91A916C for ; Sun, 21 Feb 2016 11:43:29 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id y8so72859554igp.0 for ; Sun, 21 Feb 2016 11:43:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=SB1w9qkKi68l2IgE2Iq+S3xSVk3jlpAk9bnGJLevVGg=; b=h1yD6mtRQgWbPGuA/r+LT7dHOnNS48SWK8Jk7QcA6nTYSY6ZOHwMEPU8zpe79oBrqi JOnppJlXU5gvPPOVDrr4zcW7GuldWUhZd/qh/6kzgNp6cQH74xfgKLKiNUC3/UchGX19 cYq8hqx3nIMi6J2JgmyzcNd6XIB0zm2vDr5G4rhnOE3XfiMt2bRBbswaL/cY5mChsPeS 2pLUW1GLbnwxi72R+lsuY/fne78+W+gosXoCcFD3D2KfeDCOHQnTXPHmr6yQlacaQy1i Zz24d66Pn3zAXZkdE6TJptE/3wwYCla05sMc6NrdMfMifhKM+8V37HB3fqNecc/cyqu6 nrKw== 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:date :message-id:subject:from:to:cc; bh=SB1w9qkKi68l2IgE2Iq+S3xSVk3jlpAk9bnGJLevVGg=; b=MJqPcgkIOESlEIzFt5FjHlLdxhAEaYscfSuUZErcgQ8In79Cs9/AqBlS2K3kLLVCsu nhi3CYmmZHtlWTv8XUEI28FMkn8vIxzXtX2N30caFcprf/4c+3XKdAPY71mFOEfzQGnW GAaO/0wBnesWOtLZFHnXmfAmT+HMBWgp1X/kPn3+w+1O+UqyP6vabKfF6VZV0SEeFxw4 u5WvFMb6ezpVWmGLo0UVlpzRk+hlElS9fEf1/BJn1+4BFxTrQDsqjCoZZVDRwuYMc47e Xv+YCF1lHo6HIdlyYMbl1sq5k0AP3P7siydVq79AyF+iC00gLjAt+KjhHlmXtYidRwsp on5Q== X-Gm-Message-State: AG10YOThN1vALK/1pCN70EGxhzHG36GnjpakHTSyGVrXGLdt86bfF/EzkueyC7ZW1bWCSZuPPfjQAOJbTTVwbg== MIME-Version: 1.0 X-Received: by 10.50.28.105 with SMTP id a9mr8016911igh.94.1456083808539; Sun, 21 Feb 2016 11:43:28 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 21 Feb 2016 11:43:28 -0800 (PST) In-Reply-To: <3391c710317b419ab097a291f426b25d@AM3PR30MB049.064d.mgd.msft.net> References: <3391c710317b419ab097a291f426b25d@AM3PR30MB049.064d.mgd.msft.net> Date: Sun, 21 Feb 2016 11:43:28 -0800 Message-ID: From: Martin Thomson To: Cedric Fournet Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:43:31 -0000 On 21 February 2016 at 11:41, Cedric Fournet wrote: > Agreed. For what it is worth, 0-RTT with PSK would still provide implicit > client authentication. s/would/could That implies many of the hazards that we were talking about here, so none of this makes 0-RTT any less of a hazard. From nobody Sun Feb 21 11:44:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F1E61A9244 for ; Sun, 21 Feb 2016 11:44:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 8_GOGxAs5lrK for ; Sun, 21 Feb 2016 11:44:02 -0800 (PST) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20A941A9241 for ; Sun, 21 Feb 2016 11:44:02 -0800 (PST) Received: by mail-yk0-x22d.google.com with SMTP id r207so54523455ykd.2 for ; Sun, 21 Feb 2016 11:44: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:content-type; bh=82a94COq5S62+yO6PfwdLnzG6IElOJ9Wctmb+lX8c4o=; b=Q8HrnANMwLbQgSu+3cslfR6W/cSu/FD2Cqb4s+fyEv4HDx1ClvmHTs6JGRRFHwZ7UK VpfJuobTpY9VCj0/ZLxvhPBdUcmDYSoF+J2jCztf6KpvfyTgqr5hkEBODtUbQ3KOM1gi trvJFkpl/vMVsbzG4bXXciEa3C3GpzXrokk9Dj9NQJfvxvg4qDPaBquDaTUoROP4j+Ka kNG1lce44hli3D1EWPB3oiOUTfBhpiAboUwK9mk8annynqy+DkyyqSVyYPSKXMUqPMke bg0SL55TgsJJ1pg8runnX95vOO3VfsGR12+k76YvYOXA4xAWBXb5y9TxYpfqhX3DPbA8 yqaQ== 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-type; bh=82a94COq5S62+yO6PfwdLnzG6IElOJ9Wctmb+lX8c4o=; b=LE8Hx5LpoHEm+Z4HHUbQyxm09MF+/NSSxG9PBuhx33SWrUh08Ae/1t8cmqavDhkL60 s63WLZbugF48FhqHtL20VULefm8tIZw9z7HKL7ay/Sm0kYiYCRMWfG5mrG/axKEqK9us JgVQjia/sHHLI36LEL6/5Y1p7Ed0tvlxAwM/9AdaKa0glu4uwE2Hv5n0QjmUpTNkJ50k 6x0we5Yrb6RYbIrpjgyFwS1ijlZsHXMR+iSN3rqwUhLh6/q4KYpLWcmYu446GVCAyYR6 abPN8qDxg8lYDai5M1U+77cCj0LwUpiRkUhrlaVDKJmNZSe3ZvjoX5CP8XkDjqWPCu0L 4hGw== X-Gm-Message-State: AG10YOQGSn6hSWkNXr63ZrIRQtpZv3OUO2OwAoMW+WFViRXq9SRDRn0+rm561YBd1VsQrx+iDLafxM4D1Jxo2A== X-Received: by 10.37.231.1 with SMTP id e1mr12640112ybh.130.1456083841452; Sun, 21 Feb 2016 11:44:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 21 Feb 2016 11:43:21 -0800 (PST) In-Reply-To: <3391c710317b419ab097a291f426b25d@AM3PR30MB049.064d.mgd.msft.net> References: <3391c710317b419ab097a291f426b25d@AM3PR30MB049.064d.mgd.msft.net> From: Eric Rescorla Date: Sun, 21 Feb 2016 11:43:21 -0800 Message-ID: To: Cedric Fournet Content-Type: multipart/alternative; boundary=94eb2c0b14ba223ff7052c4cf007 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 19:44:03 -0000 --94eb2c0b14ba223ff7052c4cf007 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Correct. -Ekr On Sun, Feb 21, 2016 at 11:41 AM, Cedric Fournet wrote: > Agreed. For what it is worth, 0-RTT with PSK would still provide implicit > client authentication. > > > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* 21 February 2016 19:37 > *To:* Martin Thomson > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Remove 0-RTT client auth > > > > +1 > > > > On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson > wrote: > > I'm sitting here in TRON listening to Karthik describe all the various > ways in which client authentication in 0-RTT is bad. I'm particularly > sympathetic to the perpetual impersonation attack that arises when the > client's ephemeral key is compromised. > > We originally thought that we might want to do this for > WebRTC/real-time. As it so happens, we have an alternative design > that doesn't need this, so... > > I propose that we remove client authentication from 0-RTT. > > This should simplify the protocol considerably. > > https://github.com/tlswg/tls13-spec/issues/420 > > [1] Compromising the server's long term key has the same impact, but > that's interesting for other, worse reasons. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > --94eb2c0b14ba223ff7052c4cf007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Correct.

-Ekr


On Sun, Feb 21, 2016 at 11:= 41 AM, Cedric Fournet <fournet@microsoft.com> wrote:
=

Agreed. For what it is worth, 0-RTT with PSK would still provide implici= t client authentication.

=C2=A0

=C2=A0

From: = TLS [mailto:tls-b= ounces@ietf.org] On Behalf Of Eric Rescorla
Sent: 21 February 2016 19:37
To: Martin Thomson <martin.thomson@gmail.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Remove 0-RTT client auth

=

=C2=A0

+1

=C2=A0

On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:

I'm sitting here = in TRON listening to Karthik describe all the various
ways in which client authentication in 0-RTT is bad.=C2=A0 I'm particul= arly
sympathetic to the perpetual impersonation attack that arises when the
client's ephemeral key is compromised.

We originally thought that we might want to do this for
WebRTC/real-time.=C2=A0 As it so happens, we have an alternative design
that doesn't need this, so...

I propose that we remove client authentication from 0-RTT.

This should simplify the protocol considerably.

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

[1] Compromising the server's long term key has the same impact, but that's interesting for other, worse reasons.

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

=C2=A0


--94eb2c0b14ba223ff7052c4cf007-- From nobody Sun Feb 21 12:01:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E66E01A00E8 for ; Sun, 21 Feb 2016 12:01:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=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 1WZheZbNwyHB for ; Sun, 21 Feb 2016 12:01:33 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7769F1A0193 for ; Sun, 21 Feb 2016 12:01:33 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id x1so49243269qkc.1 for ; Sun, 21 Feb 2016 12:01:33 -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:date:message-id:subject :from:to:cc:content-type; bh=6Rh1DeMCwm7yzAJRsf1gt5qDn8VgRBGAhvMNmvJYYPw=; b=UDEoaabh4aJDYC0Bx11dPbU9k2yHXdCAnAT8I0ZswBR1ZEjbH0mKMAHveDNBt5G6oc Dz+cyYPshzHGCMAaDq/P1k1XsQMyvaefzXxW5Vdf0TbQhSg4vTY5EBLMhkxr5NMoXQdN OJktjW2NoW9k19tZr8sKJGXRdppxYmxA/aH9n8SmjVABzgzmS41r1hBxHoFRpH+IN6y0 ja9u0lulrp7nRKOb55Fb4Ps/HuIWLX78FEskZGvHnhZrkYTuepDOKFtWKZDcYx1EjBjC SVDzb5Z4ZdEHXVMTiGBTN9inxrowA5zNVt+Tv1uBtdQ7g2k5xiWBieWPaOsiGMRkl0Tc RzGA== 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:date :message-id:subject:from:to:cc:content-type; bh=6Rh1DeMCwm7yzAJRsf1gt5qDn8VgRBGAhvMNmvJYYPw=; b=MAxosr6MAPumRHbaF6KosriagQ190Stez1K8F4wkLH5nhf0ArYXjOwwwL5ns/9y90b 9ZpBJkWNmoNay5fVRKYiiPSb/k+vlLUF3l9tQFVUGJxDYGJ7DDOB0XLZI3t9I9jNhdUc /pObDoWwh6F/cJiLT/xqOJBbQZytE6NXp8X+4WPEYiYM6LNmtXBLJUGm6GaLMVZCJuB6 fpmsbfe8IEJLBjko0l/j1DL+/Lptn2iePqHato555MhGAOvXGcAd/5FbLEWXX9DDfvz9 qBwyndh629v0r5ACZwwokkNw+hjMgOoYdSG2zHbrBk/oPjDJpKgDKFrTWo1cF4b3yvLG u3bg== X-Gm-Message-State: AG10YOR3A8Bt/EAZVD3U2QrHtjgI7W0KeJwah0nx5toD707gRKmhnPQeK+0Q+2y2emHZ2NGKr4+pd/fNwz+Qhw== MIME-Version: 1.0 X-Received: by 10.55.71.146 with SMTP id u140mr29326097qka.14.1456084892507; Sun, 21 Feb 2016 12:01:32 -0800 (PST) Sender: alangley@gmail.com Received: by 10.140.93.22 with HTTP; Sun, 21 Feb 2016 12:01:32 -0800 (PST) In-Reply-To: References: Date: Sun, 21 Feb 2016 12:01:32 -0800 X-Google-Sender-Auth: CG7fvTW1En2rNGBwhnWaU4F5-bE Message-ID: From: Adam Langley To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:01:35 -0000 On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson wrote: > I'm sitting here in TRON listening to Karthik describe all the various > ways in which client authentication in 0-RTT is bad. I'm particularly > sympathetic to the perpetual impersonation attack that arises when the > client's ephemeral key is compromised. > > We originally thought that we might want to do this for > WebRTC/real-time. As it so happens, we have an alternative design > that doesn't need this, so... > > I propose that we remove client authentication from 0-RTT. > > This should simplify the protocol considerably. The token-binding(*) folks care about authenticating 0-RTT requests, although they are currently working at the application-layer[1] and so would be recreating 0-RTT client authentication on top of TLS. (They would thus have all the same issues, but we already knew that.) If there was still a channel-binding value available at 0-RTT time, they should be happy. (* To recap, token-binding wants to eliminate the bearer-token nature of cookies in order to avoid several issues. For example, Heartbleed-like leaks of cookie data, origin confusion attacks[2] etc.) Cheers AGL [1] https://tools.ietf.org/html/draft-ietf-tokbind-protocol-04 [2] http://antoine.delignat-lavaud.fr/doc/www15.pdf -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Sun Feb 21 12:05:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B8A31AC405 for ; Sun, 21 Feb 2016 12:05:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X1YoykSg5JRo for ; Sun, 21 Feb 2016 12:05:03 -0800 (PST) Received: from mail-ig0-x231.google.com (mail-ig0-x231.google.com [IPv6:2607:f8b0:4001: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 B9DD41AC402 for ; Sun, 21 Feb 2016 12:05:03 -0800 (PST) Received: by mail-ig0-x231.google.com with SMTP id y8so67652729igp.1 for ; Sun, 21 Feb 2016 12:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=n7qKp5IEPQkCEKvZOXk0rqjBG7zRpd2mY2TZPrxOcIk=; b=kl961tZTnOhJwGVDyCqPu4Nt4kXoEY6W0IGD+5H1B+2UTddTc0ayJzI/ci/DwSWC68 beOFY7NFHVLKyrtk/HiwyjihfMfgi6SNyvX6bOw6jVx2tO30pTp0CCArsIICutsU83fV NT6aZo/uExAIupACloX6SBG09iYpP4uy/toEzZ96ZTYPMyxVA7j+P8H1wJgWEi5Ubdyg ZtTS4mDRudAb4ueAD4KYaItXJmudTX8OdyC5g7CLOYHkXxZLHT9xSq3VWNm3u/iC2Hdm 9XbtOBiTII3b08cHZBh81t0rcp7mGKFxZd48C1P+TSKcY93vJGrzy7bQSC6DuA+BeVHv GLwg== 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:date :message-id:subject:from:to:cc; bh=n7qKp5IEPQkCEKvZOXk0rqjBG7zRpd2mY2TZPrxOcIk=; b=C5YqGtanRvnXbZQpfr6O6pJuksQ1XPqTAFa/6e6er2nb9cPAMYVSzVYLUPAlsWxcuz MbYObY6hmb2LZhR4s4RA4lPhKY7MSYdN3d3Gcyxy0bfPX34rtrCV6wsvEhMEMEG/1S6v L2GE120QhlvhzGt5Q21h1qW8m629gWCzlI1HRVW6j138vSmxE5DCHaXvTMToaHgWR7hP 6CgERxM3YAXuf1MGzhNxovtrvEu20Qg0CNfoShf3i4YMdVCvO8jWfMdrvuW1gQNSv0Ri oN7l+8sHWIcsPJU9D2khGbpZDGD8DHdu4mEDP3GNBAyQYXst8J/eTlZzc+cEdCwPdJ0l D4sw== X-Gm-Message-State: AG10YOR1EyTfbZ/OICVWdH+C7QH3Xq3pNz7L89rl0/GOrC5LUehCvhpXtC5vcnNk7CV9Bu8KBsOae+0A16ZZWw== MIME-Version: 1.0 X-Received: by 10.50.6.104 with SMTP id z8mr7843122igz.58.1456085103268; Sun, 21 Feb 2016 12:05:03 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 21 Feb 2016 12:05:03 -0800 (PST) In-Reply-To: References: Date: Sun, 21 Feb 2016 12:05:03 -0800 Message-ID: From: Martin Thomson To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:05:05 -0000 On 21 February 2016 at 12:01, Adam Langley wrote: > The token-binding(*) folks care about authenticating 0-RTT requests, > although they are currently working at the application-layer[1] and so > would be recreating 0-RTT client authentication on top of TLS. (They > would thus have all the same issues, but we already knew that.) You can't run an exporter until the handshake is complete, so how were you imagining that this would work? From nobody Sun Feb 21 12:07:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 611B01A92B2 for ; Sun, 21 Feb 2016 12:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 YmjtJGVna8I7 for ; Sun, 21 Feb 2016 12:06:57 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F8191A9103 for ; Sun, 21 Feb 2016 12:06:57 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id z7so54065714yka.3 for ; Sun, 21 Feb 2016 12:06:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=PvBiC76q3KHQSbGr3IkOu/mkzD2yZPQFQMpj3oEaR2g=; b=aHlvIhkK1vkwO5/VXw0yFZHECqhe9F3V0aDAE891ixRQ/UAV2Yy6FiGKXs3Yz3b9Rx kDrvNrao3DegAzs3q5RLx3GbsZETF1sj1YqScHvI1ESXZjw4mm+DXzCXG1pQEUvQ33Vr sSQfQzO2zWRGV0hJisatTySwjh4sJ3V/qGvofIDBIuzFI5TfOFXFoHmyA/N5XKIYcmP1 bC4wbUAL6UT3Pd2516AW4lvtavs94Eaf3olXCMGkUnospusHwzZLOPryme4jG3Eigwdi xif+sXwChhCjFas9xHHcJlgAlsmG88Po9n6W81pS/5awK5cs421S1T7akL5dkDwydmJq BrTA== 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-type; bh=PvBiC76q3KHQSbGr3IkOu/mkzD2yZPQFQMpj3oEaR2g=; b=KJvQYeTwjA7CLNQbeLDpDUUZWBFDA9CKfLqKG28N79e6mK0IPfps+iAMSNFJlfUx11 Z5DUidWDh/NHIb7HzyIpvcKiBNrQaNnyHS+DFkVcfxDcn1nZPtkYt5t3fUunnwaydrOy S59zknMkCCm33AaYJz6GHzW9+RlnMDBU08et0mb5x0apOjABPZiqdjdbxx6gOVQ9+0E3 eC37l6LpwbbQPw3QtTy9VNiyi8o+3jBO456W33ghTH/yfEinCqUmCQgzdKyuN4rq02j0 hoFweMmcmlGaOrMPa6GM5M7zHhyn+HH1Rf6fPSCCdtjWKY8xZIO4AOoHLV0sWJ8mr6Br MAEQ== X-Gm-Message-State: AG10YOSM1/Bl2DtzSMkyS9qEFNt3+MTxPFjnIK3GvVYBTdAW2jZGwCPi0VM0XoPcUvSzzuSliyYQ4V8sD2ofSw== X-Received: by 10.37.230.79 with SMTP id d76mr12819474ybh.74.1456085216494; Sun, 21 Feb 2016 12:06:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sun, 21 Feb 2016 12:06:17 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 21 Feb 2016 12:06:17 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0b1c7817c188052c4d424c Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:06:58 -0000 --94eb2c0b1c7817c188052c4d424c Content-Type: text/plain; charset=UTF-8 On Sun, Feb 21, 2016 at 12:05 PM, Martin Thomson wrote: > On 21 February 2016 at 12:01, Adam Langley wrote: > > The token-binding(*) folks care about authenticating 0-RTT requests, > > although they are currently working at the application-layer[1] and so > > would be recreating 0-RTT client authentication on top of TLS. (They > > would thus have all the same issues, but we already knew that.) > > You can't run an exporter until the handshake is complete, so how were > you imagining that this would work? I think we're going to have to invent a 0-RTT exporter (yes, I understand that this requires care). -Ekr _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0b1c7817c188052c4d424c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Feb 21, 2016 at 12:05 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
O= n 21 February 2016 at 12:01, Adam Langley <agl@imperialviolet.org> wrote:
> The token-binding(*) folks care about authenticating 0-RTT requests, > although they are currently working at the application-layer[1] and so=
> would be recreating 0-RTT client authentication on top of TLS. (They > would thus have all the same issues, but we already knew that.)

You can't run an exporter until the handshake is complete, so ho= w were
you imagining that this would work?

I think= we're going to have to invent a 0-RTT exporter (yes, I understand that= this
requires care).

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

--94eb2c0b1c7817c188052c4d424c-- From nobody Sun Feb 21 12:08:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87F41ACC86 for ; Sun, 21 Feb 2016 12:08:50 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztKuMxvYH6qF for ; Sun, 21 Feb 2016 12:08:49 -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 4C0011ACC7F for ; Sun, 21 Feb 2016 12:08:49 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id 9so158921362iom.1 for ; Sun, 21 Feb 2016 12:08: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:date:message-id:subject:from:to :cc:content-type; bh=Dk2ZabMH5/JbIGF4be6spaEJu4lInAF/X6rROAlSqTo=; b=wfdqVTw8dAe7OcvOgqnDpByALsxFFWGkZIdF4SNgJq6FSYdSBPMmvuwMCjj9wZWgsa LK1w4NiKJcUpQAnmxzAOXqw7cqdJ595I5WUXCNetrrLjnQd+gHUvxWhI4BJJkLsmnq90 TMBi/7tIaTLcpluSUR3F7Cet6W6ryh+5L/PrdLQlEttumKzUyHydgXM96V1PyQhf74e+ ijgxsVVjKNWnUrynFOhGUDKutmw0iixeOBCYFg8/ZJAC0CJtlm6lUmLBadBqZVHB8TEJ NSkd0PDFf/Zb0cUUHjuC1nMroLWsZckyyR/W6nGCS3kP/mc7FLS9U/q4tURKWSlafDNn hIyA== 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:date :message-id:subject:from:to:cc:content-type; bh=Dk2ZabMH5/JbIGF4be6spaEJu4lInAF/X6rROAlSqTo=; b=bURRnF0pyknFC3MxscKOrpepyc9h5xITvA5ttzZZpIwrVjbZ6tH2AHkQ4C568pLfOi ULZT5UK+DHnTrVy3wEiHkFp5VRnNepgMOeQ6p8SD7CTV7UtWvRJJ/6Yj8OGfFGopXzry vs+w9YYt+OG1iS7cxOrFLqTxjRgkX5+m6W4TGKctaOpGDGfjFNS417T9jbR9sCdk74x7 1IaUdDNp+6q+IbYwU7RJN+QiIYx4G9qXhTkgl6far0F5L0pk//f90rZSN+cYHPoBgrcC OGszIpr75VdpAgGgNl9+slxbORDno+HZaL56J9esY0Zh8CO5M6KRh8USkod0R8pI7fd8 j6fw== X-Gm-Message-State: AG10YORm1o5+vOSv6Ue3JA9otFsxzvWSwxXJjBFw8vMOQZI7n6dUFNbkpUUtEi/wPh9L4nHS2h0DAP/uI1tuHA== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr22719468ioi.108.1456085328788; Sun, 21 Feb 2016 12:08:48 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 21 Feb 2016 12:08:48 -0800 (PST) In-Reply-To: References: Date: Sun, 21 Feb 2016 12:08:48 -0800 Message-ID: From: Martin Thomson To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Adam Langley , "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:08:51 -0000 On 21 February 2016 at 12:06, Eric Rescorla wrote: > I think we're going to have to invent a 0-RTT exporter (yes, I understand > that this > requires care). We might disagree about that "have to". I'd be happier if the 0-RTT data couldn't rely on the existence of an exporter. If that means that token-binding needs to work out a bespoke solution, I think that I'd prefer that. From nobody Sun Feb 21 12:52:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36971ACDA5; Sun, 21 Feb 2016 12:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.636 X-Spam-Level: X-Spam-Status: No, score=-0.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_84=0.6, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=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 j7MuW4SyHZHN; Sun, 21 Feb 2016 12:52:51 -0800 (PST) Received: from implementers.org (implementers.org [173.246.102.69]) by ietfa.amsl.com (Postfix) with ESMTP id DA48D1ACDA8; Sun, 21 Feb 2016 12:52:50 -0800 (PST) Received: from [IPv6:2602:ae:177f:9f00:f486:e1a7:6cf7:c359] (unknown [IPv6:2602:ae:177f:9f00:f486:e1a7:6cf7:c359]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 3E779200E3; Sun, 21 Feb 2016 21:52:49 +0100 (CET) To: Dave Garrett , tls@ietf.org References: <56A8904D.10307@ericsson.com> <201602080117.57742.davemgarrett@gmail.com> From: Marc Petit-Huguenin X-Enigmail-Draft-Status: N1110 Message-ID: <56CA239F.6010107@acm.org> Date: Sun, 21 Feb 2016 13:52:47 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.6.0 MIME-Version: 1.0 In-Reply-To: <201602080117.57742.davemgarrett@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: avt@ietf.org Subject: Re: [TLS] WG last call of draft-ietf-avtcore-rfc5764-mux-fixes-05 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 20:52:52 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 02/07/2016 11:17 PM, Dave Garrett wrote: > Permanently gobbling up the majority of the codespace feels like > excessive force here. This is not what the RFC-to-be is proposing. We are just marking the values that can create an issue when used with RFC 5764 as reserved, with a note in the IANA registry that ask to read the RFC-to-be to understand the problem. If a new proposed ContentType codepoint will never ever be used in the context of RTCWeb, then it can be allocated in the reserved range. > For TLS 1.3, the first byte will always be one > of alert(21), handshake(22), or application_data(23), even for custom > types. The stated type for TLSCiphertext has been frozen to > application_data(23) with the actual type for the payload now in the > encrypted fragment. (this is of course assuming we don't eventually > drop the frozen type & version here, which now sounds unlikely if > we're having to deal with design flaws like this) Even handshake > records after the hellos will have an opaque_type of > application_data(23), with the encrypted fragment.type containing the > actual handshake(22) designation. All TLS 1.3+ packets will be > detected with the RFC 5764 Section 5.1.2 algorithm even if new types > are allocated in the proposed reserved ranges. > > Locking down the <1.2 registry seems fine, however 1.3+ should be > able to do whatever it needs as its encrypted type is not going to > get accidentally read & misinterpreted by anything. > > https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-5.2.2 > https://tools.ietf.org/html/rfc5764#section-5.1.2 > https://tools.ietf.org/html/draft-ietf-avtcore-rfc5764-mux-fixes-05#section-4 > > > > Dave > > > On Monday, February 08, 2016 12:21:02 am Joseph Salowey wrote: >> This document is relevant to the TLS working because it reserves a >> large portion of the TLS content type space. The values 0-19 and >> 64-255 cannot be used without checking for conflicts with >> SRTP-DTLS's wacky demultiplexing scheme. In TLS 1.3 we will move >> more encrypted content types which should limit the impact this >> unfortunate design on TLS evolution, but the working group should >> be aware of this. >> >> >> On Wed, Jan 27, 2016 at 1:39 AM, Magnus Westerlund >> wrote: >> >>> AVTCORE and TLS, >>> >>> TLS WG, you are included in this WG last call, as this document >>> affects the TLS ContentType IANA registry. >>> >>> This email starts a two week WG last call, that ends on the 10th >>> of February. The intended status of this document is standards >>> track (Proposed Standard). >>> >>> The document can be retrieved here: >>> https://datatracker.ietf.org/doc/draft-ietf-avtcore-rfc5764-mux-fixes/ - -- >>> Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWyiOZAAoJECnERZXWan7EpAwQALT42q+uWbjk9qfPZmJI4dzU EKhNuQw+yJZ6Pk0TO5EbLtbLb0U9huWIXfL/qnMhoZKmtyBI05yL08KIIucJQJ74 Y/vTcVuYhminD4Ug8p4ytu9v5RotexQFbomFKqZP3TC0hCISrrWbbg+LU0EEPpZM jT+D8pYdzAXGEYQvZ8k9xq/rjZfksYLjQOUPLHgoCC1L3wzr3xvswKQ7c0NEoSC8 rDbVxTp4f+q15W3/HG29+wFN6npgapFK49bXPzAR2LYTHO8yw6mHpHMEd3zq9Kd/ HsdOWH2ETqFiLOaszFO+rzQPx+/OsEwZWDTf2tcKLamogCoKfRJKICmFWAvHSf9G 56aiBiwL6kdKZHIcOJ4zQZqG7UdZ1pVy78czPfkjSwB8TD1RMFXNwS6WTgF9RmYy Ixe1lrvzOdfrL02NvGz2DdEAM7ETS9ujIxbrOUTEg6d7IDJ7FQdT97zHxvCUfjLY kDd4RtVqIr825+78uJxeXCJ5fZfXOG0VbwpwlC2smyxHUUVwTWQMCJ32EvZynuFo f7yNMkdSolr3C2Bkt5ELwnKxUtiTqFMZj52rtBzhqAN6iDt289JSvO1e87EORBin N1ingAw1bEJz1raNF0uA8u7N12QUtAsPrc9hYpmYjxl6I3+d/lFevvmWne/YbWbU UduqXpPezcNInD7bMDOD =J64B -----END PGP SIGNATURE----- From nobody Sun Feb 21 14:30:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49CC51B2F6C for ; Sun, 21 Feb 2016 14:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 bdd1Hqq9_MRT for ; Sun, 21 Feb 2016 14:30:02 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 CFC4E1B2F6D for ; Sun, 21 Feb 2016 14:30:01 -0800 (PST) Received: by mail-yk0-x22a.google.com with SMTP id r207so55419384ykd.2 for ; Sun, 21 Feb 2016 14:30:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=PUnhU/1KwCJ5xXypS55vVVDx1WXT/wBn6OVUQoQQNyo=; b=KSFepKVEec6CuFMm3hk/JzVEw3p3ETTUexXJc39WAWXGhXff3f5n6rlCVKtq2y8oM8 RxkybtdyUIpL9FH/IX88iI0HUl9r9g83I7UwEEFIHEAsdsUAfIaT1A2w3n6y17fyDrMb pLLX5hTWnX8L5Shd+3cwcMQFQBJpzxd+HK6b8= 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 :content-type; bh=PUnhU/1KwCJ5xXypS55vVVDx1WXT/wBn6OVUQoQQNyo=; b=OnqIt5FHlvEN0RtlrBXOS9bYrdv4mzFtXmTfoU10MoH2REdDTGAVlHeQCZ3Nj8Pkfn m0bepwplgxjtFfrKrW1y6MjkORjJ6DWtCA6Thmi7OjcsWxBKJEcwvE9l/aj6ehD7CxHz YXV/wBbsOX5Q2z+fISTrRmVIGp4TbkqjYF2f4sBWb90ObtJ4+iHjoJ2KQKXv6SV1oBXs HPkM62LeGmtBanW6+pYKf3klx3BzhpnqR1N1JRf4RS3C/tTR7SiSQmzE6Pm2BZL/72En JbDPHQfiarwNpNITyWc3y2U9lS1ewlADBm27S8ZD49YnVVffsdvJBrcAY/3o4Xj9NyCs f4uw== X-Gm-Message-State: AG10YORUMH1LbUy2b0/ENPbo6WEDMv4eUFAtc05ZcUn+vMN2mi+zI79BPAM/6dl4IV+2Ci0XYHmGrJerkZCUlGSh X-Received: by 10.37.29.194 with SMTP id d185mr12787568ybd.109.1456093801088; Sun, 21 Feb 2016 14:30:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.86.67 with HTTP; Sun, 21 Feb 2016 14:29:41 -0800 (PST) From: Nick Sullivan Date: Sun, 21 Feb 2016 14:29:41 -0800 Message-ID: To: hackathon@ietf.org, tls@ietf.org Content-Type: multipart/alternative; boundary=001a11428d0ec6650e052c4f41e6 Archived-At: Subject: [TLS] New IETF 95 Hackathon technology: TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 22:30:03 -0000 --001a11428d0ec6650e052c4f41e6 Content-Type: text/plain; charset=UTF-8 At the TRON workshop at NDSS there was interest in a hackathon project to work on TLS 1.3 implementations and to test interoperability. I have added this as a topic for the IETF 95 Hackathon. If you are interested in participating, please sign up here: https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=95hackathon Nick Sullivan --001a11428d0ec6650e052c4f41e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
At the TRON workshop at NDSS there was interest in a = hackathon project to work on TLS 1.3 implementations and to test interopera= bility. I have added this as a topic for the IETF 95 Hackathon. If you are = interested in participating, please sign up here:

http= s://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=3D95hackathon

Nick Sullivan
--001a11428d0ec6650e052c4f41e6-- From nobody Sun Feb 21 15:59:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 278B71ACE5C for ; Sun, 21 Feb 2016 15:59:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rtr_F7NzeKSY for ; Sun, 21 Feb 2016 15:59:09 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::753]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1B681ACE38 for ; Sun, 21 Feb 2016 15:59:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uP+Z+1phvKXQmR77tMUe1khl4ykbybuhxPmVLN/sd9g=; b=H26bb/Co+Sd6vl/2EIbxsNSivghtCxgZSCC6jiMetP07OMUKPKVbnEWnVWjmDiu7aviN9WAo2SNNq+F+Np9Oock6K2i/fcrOjh8IKrRAbQHGY5OEMTdLNVE+C031eHfPS9D+2eKM28P6uZM+1PrbzkgkIdIhEjEF4oZBaC3XaO4= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.409.15; Sun, 21 Feb 2016 23:58:52 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0409.024; Sun, 21 Feb 2016 23:58:52 +0000 From: Andrei Popov To: Eric Rescorla , Martin Thomson Thread-Topic: [TLS] Remove 0-RTT client auth Thread-Index: AQHRbN5zI6wtdPUSskemUdPtdNKkhZ825MAAgABIwjA= Date: Sun, 21 Feb 2016 23:58:51 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::1d2] x-ms-office365-filtering-correlation-id: a0f288f0-4fed-40ea-bfa9-08d33b1af2eb x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:dPA7klbhryLgmW8+hWQ7T4UHMqEcCdJ8XkDddajuq/wE18KRmmz8i0IE3ZZTP//xl9rAG2gXdEOEr9wS/KvRRNcCmGqBxsX7V7dw9W7iTFev3V+7HYiU18eVRMDfOXr9LHF4epfKIFerY/gAySH1PA==; 24:H9fqB4OmcTGpLGN2CqBvtqyBmUNlCy+4Br7t2HQgG5XlKlcGS+n30fkBq7pE2v+t1A3D8gZwrZfvp5Q3kGp0Jnu/NZjAke9DOARDaiMbkA8= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 085956473E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(24454002)(5001770100001)(33656002)(19625215002)(76176999)(5001960100002)(54356999)(50986999)(16236675004)(2900100001)(2950100001)(77096005)(106116001)(15975445007)(99286002)(76576001)(86362001)(8990500004)(19300405004)(19617315012)(10400500002)(10290500002)(87936001)(5004730100002)(5005710100001)(2906002)(3660700001)(3280700002)(10090500001)(5003600100002)(92566002)(5008740100001)(11100500001)(586003)(74316001)(790700001)(6116002)(102836003)(1096002)(1220700001)(122556002)(5002640100001)(40100003)(189998001)(19580405001)(19580395003)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BLUPR03MB13969A66CED53C71975A9D468CA20BLUPR03MB1396namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2016 23:58:51.6971 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Feb 2016 23:59:14 -0000 --_000_BLUPR03MB13969A66CED53C71975A9D468CA20BLUPR03MB1396namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBzdHJvbmdseSBpbiBmYXZvciBvZiByZW1vdmluZyBjbGllbnQgYXV0aCBmcm9tIDAtUlRU Lg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFN1bmRheSwgRmVicnVh cnkgMjEsIDIwMTYgMTE6MzcgQU0NClRvOiBNYXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25A Z21haWwuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFJlbW92ZSAw LVJUVCBjbGllbnQgYXV0aA0KDQorMQ0KDQpPbiBTdW4sIEZlYiAyMSwgMjAxNiBhdCAxMTozMSBB TSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpJJ20gc2l0dGluZyBoZXJlIGluIFRST04gbGlz dGVuaW5nIHRvIEthcnRoaWsgZGVzY3JpYmUgYWxsIHRoZSB2YXJpb3VzDQp3YXlzIGluIHdoaWNo IGNsaWVudCBhdXRoZW50aWNhdGlvbiBpbiAwLVJUVCBpcyBiYWQuICBJJ20gcGFydGljdWxhcmx5 DQpzeW1wYXRoZXRpYyB0byB0aGUgcGVycGV0dWFsIGltcGVyc29uYXRpb24gYXR0YWNrIHRoYXQg YXJpc2VzIHdoZW4gdGhlDQpjbGllbnQncyBlcGhlbWVyYWwga2V5IGlzIGNvbXByb21pc2VkLg0K DQpXZSBvcmlnaW5hbGx5IHRob3VnaHQgdGhhdCB3ZSBtaWdodCB3YW50IHRvIGRvIHRoaXMgZm9y DQpXZWJSVEMvcmVhbC10aW1lLiAgQXMgaXQgc28gaGFwcGVucywgd2UgaGF2ZSBhbiBhbHRlcm5h dGl2ZSBkZXNpZ24NCnRoYXQgZG9lc24ndCBuZWVkIHRoaXMsIHNvLi4uDQoNCkkgcHJvcG9zZSB0 aGF0IHdlIHJlbW92ZSBjbGllbnQgYXV0aGVudGljYXRpb24gZnJvbSAwLVJUVC4NCg0KVGhpcyBz aG91bGQgc2ltcGxpZnkgdGhlIHByb3RvY29sIGNvbnNpZGVyYWJseS4NCg0KaHR0cHM6Ly9naXRo dWIuY29tL3Rsc3dnL3RsczEzLXNwZWMvaXNzdWVzLzQyMA0KDQpbMV0gQ29tcHJvbWlzaW5nIHRo ZSBzZXJ2ZXIncyBsb25nIHRlcm0ga2V5IGhhcyB0aGUgc2FtZSBpbXBhY3QsIGJ1dA0KdGhhdCdz IGludGVyZXN0aW5nIGZvciBvdGhlciwgd29yc2UgcmVhc29ucy4NCl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0 Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdGxzPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bS8/dXJsPWh0dHBzJTNhJTJmJTJmd3d3LmlldGYub3JnJTJmbWFpbG1hbiUyZmxpc3RpbmZvJTJm dGxzJmRhdGE9MDElN2MwMSU3Y0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN2NiOGFmZTM1 YTZjOGE0ZGQ3ZTQxMzA4ZDMzYWY2N2RlNyU3YzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdjMSZzZGF0YT1iTFBvbmRnOTM0UTl1UDI3OSUyYjRScTVMbm0zZVJpcUhSMSUyZmhFN0s1 ejBZZyUzZD4NCg0K --_000_BLUPR03MB13969A66CED53C71975A9D468CA20BLUPR03MB1396namp_ 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 Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbSBzdHJvbmdseSBpbiBmYXZvciBv ZiByZW1vdmluZyBjbGllbnQgYXV0aCBmcm9tIDAtUlRULg0KPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj5DaGVlcnMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5BbmRyZWk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5G cm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86dGxzLWJvdW5jZXNA aWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50 OjwvYj4gU3VuZGF5LCBGZWJydWFyeSAyMSwgMjAxNiAxMTozNyBBTTxicj4NCjxiPlRvOjwvYj4g TWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gUmVtb3Zl IDAtUlRUIGNsaWVudCBhdXRoPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ JiM0MzsxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBT dW4sIEZlYiAyMSwgMjAxNiBhdCAxMTozMSBBTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9 Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90 dG9tOjEyLjBwdCI+SSdtIHNpdHRpbmcgaGVyZSBpbiBUUk9OIGxpc3RlbmluZyB0byBLYXJ0aGlr IGRlc2NyaWJlIGFsbCB0aGUgdmFyaW91czxicj4NCndheXMgaW4gd2hpY2ggY2xpZW50IGF1dGhl bnRpY2F0aW9uIGluIDAtUlRUIGlzIGJhZC4mbmJzcDsgSSdtIHBhcnRpY3VsYXJseTxicj4NCnN5 bXBhdGhldGljIHRvIHRoZSBwZXJwZXR1YWwgaW1wZXJzb25hdGlvbiBhdHRhY2sgdGhhdCBhcmlz ZXMgd2hlbiB0aGU8YnI+DQpjbGllbnQncyBlcGhlbWVyYWwga2V5IGlzIGNvbXByb21pc2VkLjxi cj4NCjxicj4NCldlIG9yaWdpbmFsbHkgdGhvdWdodCB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gZG8g dGhpcyBmb3I8YnI+DQpXZWJSVEMvcmVhbC10aW1lLiZuYnNwOyBBcyBpdCBzbyBoYXBwZW5zLCB3 ZSBoYXZlIGFuIGFsdGVybmF0aXZlIGRlc2lnbjxicj4NCnRoYXQgZG9lc24ndCBuZWVkIHRoaXMs IHNvLi4uPGJyPg0KPGJyPg0KSSBwcm9wb3NlIHRoYXQgd2UgcmVtb3ZlIGNsaWVudCBhdXRoZW50 aWNhdGlvbiBmcm9tIDAtUlRULjxicj4NCjxicj4NClRoaXMgc2hvdWxkIHNpbXBsaWZ5IHRoZSBw cm90b2NvbCBjb25zaWRlcmFibHkuPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9naXRodWIu Y29tL3Rsc3dnL3RsczEzLXNwZWMvaXNzdWVzLzQyMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8v Z2l0aHViLmNvbS90bHN3Zy90bHMxMy1zcGVjL2lzc3Vlcy80MjA8L2E+PGJyPg0KPGJyPg0KWzFd IENvbXByb21pc2luZyB0aGUgc2VydmVyJ3MgbG9uZyB0ZXJtIGtleSBoYXMgdGhlIHNhbWUgaW1w YWN0LCBidXQ8YnI+DQp0aGF0J3MgaW50ZXJlc3RpbmcgZm9yIG90aGVyLCB3b3JzZSByZWFzb25z LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzYSUyZiUyZnd3dy5pZXRmLm9yZyUyZm1haWxtYW4lMmZsaXN0 aW5mbyUyZnRscyZhbXA7ZGF0YT0wMSU3YzAxJTdjQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNv bSU3Y2I4YWZlMzVhNmM4YTRkZDdlNDEzMDhkMzNhZjY3ZGU3JTdjNzJmOTg4YmY4NmYxNDFhZjkx YWIyZDdjZDAxMWRiNDclN2MxJmFtcDtzZGF0YT1iTFBvbmRnOTM0UTl1UDI3OSUyYjRScTVMbm0z ZVJpcUhSMSUyZmhFN0s1ejBZZyUzZCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BLUPR03MB13969A66CED53C71975A9D468CA20BLUPR03MB1396namp_-- From nobody Sun Feb 21 16:02:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E2F1A6F7A for ; Sun, 21 Feb 2016 16:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id om_tEwq3PmWG for ; Sun, 21 Feb 2016 16:02:25 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6A22C1A1EF7 for ; Sun, 21 Feb 2016 16:02:25 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 3C7A1F9C013 for ; Sun, 21 Feb 2016 19:02:25 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id wCeZaeSOaaqX for ; Sun, 21 Feb 2016 19:01:01 -0500 (EST) Received: from [172.25.1.3] (rrcs-67-52-140-5.west.biz.rr.com [67.52.140.5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 71488F9C00F for ; Sun, 21 Feb 2016 19:02:12 -0500 (EST) From: Russ Housley Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-82-1050761322 Date: Sun, 21 Feb 2016 19:02:10 -0500 In-Reply-To: To: IETF TLS References: Message-Id: <2CF222FD-7288-4952-B53D-F3ADE131596C@vigilsec.com> X-Mailer: Apple Mail (2.1085) Archived-At: Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 00:02:26 -0000 --Apple-Mail-82-1050761322 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1=20 =20 On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson = wrote: I'm sitting here in TRON listening to Karthik describe all the various ways in which client authentication in 0-RTT is bad. I'm particularly sympathetic to the perpetual impersonation attack that arises when the client's ephemeral key is compromised. We originally thought that we might want to do this for WebRTC/real-time. As it so happens, we have an alternative design that doesn't need this, so... I propose that we remove client authentication from 0-RTT. This should simplify the protocol considerably. https://github.com/tlswg/tls13-spec/issues/420 [1] Compromising the server's long term key has the same impact, but that's interesting for other, worse reasons.= --Apple-Mail-82-1050761322 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 
On Sun, Feb 21, 2016 at = 11:31 AM, Martin Thomson <

I'm sitting here in TRON listening to = Karthik describe all the various
ways in which client authentication = in 0-RTT is bad.  I'm particularly
sympathetic to the perpetual = impersonation attack that arises when the
client's ephemeral key is = compromised.

We originally thought that we might want to do this = for
WebRTC/real-time.  As it so happens, we have an alternative = design
that doesn't need this, so...

I propose that we remove = client authentication from 0-RTT.

This should simplify the = protocol considerably.

 Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 05:46:18 -0000 On Sun, Feb 21, 2016 at 11:31:04AM -0800, Martin Thomson wrote: > I'm sitting here in TRON listening to Karthik describe all the various > ways in which client authentication in 0-RTT is bad. I'm particularly > sympathetic to the perpetual impersonation attack that arises when the > client's ephemeral key is compromised. It also seems like a footgun to me (yes, I realize one isn't supposed to transport "non-safe"[1] data on it, but...). > We originally thought that we might want to do this for > WebRTC/real-time. As it so happens, we have an alternative design > that doesn't need this, so... Got mailarchive or draft link? Some sort of "sign ClientHello" scheme? Or just taking the 1RTT for the authentcation? > I propose that we remove client authentication from 0-RTT. > > This should simplify the protocol considerably. Yes, there are all sorts of obscure corner-cases with 0-RTT auth that don't happen with 0-RTT data, and seemingly some existing extensions if implemented bring even more (and the current spec doesn't even begin to explain those extension issues). [1] "idempotent" isn't enough: e.g. HTTP considers unconditional DELETE to be idempotent, but effects of making such thing replayable with authentication might not be desirable... -Ilari From nobody Sun Feb 21 23:18:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790911B3645 for ; Sun, 21 Feb 2016 23:18:50 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lns8dFPg7-gM for ; Sun, 21 Feb 2016 23:18:49 -0800 (PST) Received: from mail-ig0-x22c.google.com (mail-ig0-x22c.google.com [IPv6:2607:f8b0:4001: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 22CE81B33C7 for ; Sun, 21 Feb 2016 23:18:49 -0800 (PST) Received: by mail-ig0-x22c.google.com with SMTP id y8so80312594igp.0 for ; Sun, 21 Feb 2016 23:18: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:date:message-id:subject:from:to :cc:content-type; bh=0+Hk09V3855586ndIvbSswpU5ulMNTfHehUjK2sr83s=; b=0Fuzf5bfLq6aJYe8ClujPXvvMPTYm123i65B7wb9z7qIQZl1O0ioe8tCQJmTzKffYT TLY0seGhudz240kwEmBfx0wwJLD4kAUHGPb5FCjroXgRWqPrEAumdlFDwze1QelDoa2p K5IgvtOm4f9OKExxSpxV9angvYddxAKEfqkD/HCHZtKCqT4gN6C6hpiu0ToW0g5vY6iP RVECTRJZSYZoXn4qoWPBDHOb6iSTcZgyrn/14DYmScMZvAYpPGNgRos1J56vXoqnqNxe bXxcCJB1n57Rc+hRqbmNRrOX8WgeKLrGb1Jgb7TOKc7Qny0dxoVZOjgDVkgpycaq5HnK 53Xg== 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:date :message-id:subject:from:to:cc:content-type; bh=0+Hk09V3855586ndIvbSswpU5ulMNTfHehUjK2sr83s=; b=luMumuWlpkjwEIiuAKlR0XWCatNnD282GlNQgJtD5a5i0OqUn8dB304heEJbRMRvLm z0K28CgxexTqeq5KGslyI/WToj0Ddu+qwGvlyNvTZOZzF31SZ9xvU5apuBNfIsitwVeS Z4B7Zq7y7oFLG1ra0NRaovzgYf4gM6HH0ZJ1n3utB31Ah7QGDqIQy8v4D1fJEiO+tuG1 wiUmj4LnfmGqopapqivVg0hBvRqBiCqg9y7UfczH/d4SG87fXe5CUdwEhAnO19KwOiOO oBnQa3fpKE/qtaUKjvHTSCi8/106UIZ1cFQykEToRlerZlOqOPukIXiYHBohWOvBf6n3 Hd3g== X-Gm-Message-State: AG10YOR78Wxd7kRf9IYqSE6J/mneksqQ/SfFL1buLLfbPnSZjz+D5YCbl6D1a6TuprEWEOR3aieKX/Q8cxXNEw== MIME-Version: 1.0 X-Received: by 10.50.131.227 with SMTP id op3mr3239972igb.94.1456125528515; Sun, 21 Feb 2016 23:18:48 -0800 (PST) Received: by 10.36.53.79 with HTTP; Sun, 21 Feb 2016 23:18:48 -0800 (PST) In-Reply-To: <20160222054609.GA20873@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160222054609.GA20873@LK-Perkele-V2.elisa-laajakaista.fi> Date: Sun, 21 Feb 2016 23:18:48 -0800 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove 0-RTT client auth X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 07:18:50 -0000 On 21 February 2016 at 21:46, Ilari Liusvaara wrote: >> We originally thought that we might want to do this for >> WebRTC/real-time. As it so happens, we have an alternative design >> that doesn't need this, so... > > Got mailarchive or draft link? No, this was a realization that we could just stuff the ClientHello into the signaling (the SDP offer to be precise) and continue the handshake later. There were all sorts of ideas floating around about using offline configs, but those are all just more complex. From nobody Mon Feb 22 02:56:57 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 4119D1A00D0; Sun, 21 Feb 2016 16:37:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160222003702.32233.97538.idtracker@ietfa.amsl.com> Date: Sun, 21 Feb 2016 16:37:02 -0800 Archived-At: X-Mailman-Approved-At: Mon, 22 Feb 2016 02:56:56 -0800 Cc: tls@ietf.org, tls-chairs@ietf.org Subject: [TLS] tls - Update to a Meeting Session Request for IETF 95 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Feb 2016 00:37:02 -0000 An update to a meeting session request has just been submitted by Stephen Farrell, a SEC Area Director. --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Stephen Farrell Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: tokbind tcpinc stir saag rtcweb opsawg httpauth httpbis dane cfrg cose jose acme trans uta capport curdle Second Priority: sacm oauth sidr i2nsf Special Requests: Please avoid LURK BOF. --------------------------------------------------------- From nobody Tue Feb 23 02:45:12 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8EE1B4152 for ; Tue, 23 Feb 2016 02:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qMpoYTSwRugd for ; Tue, 23 Feb 2016 02:45:08 -0800 (PST) Received: from mail-pa0-x22c.google.com (mail-pa0-x22c.google.com [IPv6:2607:f8b0:400e:c03::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 8A9701B4020 for ; Tue, 23 Feb 2016 02:45:05 -0800 (PST) Received: by mail-pa0-x22c.google.com with SMTP id fy10so108356917pac.1 for ; Tue, 23 Feb 2016 02:45:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to; bh=4asjqKncze7V/Tse40DE8EXKAnFRmT79UAvzn2/Suak=; b=MkXrlzkWnmZNLH2d9nfUNgDVhrZSHr/YtsJlJAyKvj3XGTabNoDO7Dst9jaynZrlZf 7UfQ9lD7pSq5X7HRJvwpvpWTUFci5zmcoBnWTvTrpR7ZPlcNJcL2RdK7KaDo44WRYDn2 CdbIOMIcoIW1SmWqnYn5CMNoodq7Bsy2RejNaVWjrYD1HcSHWxQKOzx163yUen1P2ck8 lmCkrCCjJjIY7Q6ohYEOOETyNt0iRZEmpxTk6LIoA9IsCQPAzvYdQun+rbAj0fehHjrk IE6FylrN3G3qiCS0ptkUjQlNFVXzoldH9b5F3Au54AZFvGPg312iZqmCVsUzC0ZmaTUF N5CQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to; bh=4asjqKncze7V/Tse40DE8EXKAnFRmT79UAvzn2/Suak=; b=YoqQMDwn2Fe31djrV9BQLFAYEZpzBkxAHIcP5BxVFlifPnhJrN87UC6O+EW9EjvSeV N2itHo+hqS85DZ6A0KSRD5STdKZE4p8SQq/YtSN7pvWZ5LkM3Wj02gf+hVxdExUUBizm u81BIWoHXD2OEam0pcCWGj6BUQ6P/Wc07hgIET56K012dGAq4+9ylp435lQda3li7kGW 2X8Ys9bif5R2daCZi8VtFXzMspGNM2ny7g2fZ660w4NRPvCzzqeQ9yN7oibLwZHm2e4A 1UQlvmg4ysqTjY6nhj+9/KyoSmrBvAUBGdAuiPfLLvZS3ZmYyrE/cJ3L5mV8HOsDHshz edZA== X-Gm-Message-State: AG10YOQtYAXESzj1q9fTsMeYThgMBdCmILvHGBWZhLVm/smf1N0DJoE902V6EBoVOJfEcg== X-Received: by 10.67.23.161 with SMTP id ib1mr43453133pad.156.1456224305168; Tue, 23 Feb 2016 02:45:05 -0800 (PST) Received: from [172.25.0.204] (rrcs-67-52-140-5.west.biz.rr.com. [67.52.140.5]) by smtp.gmail.com with ESMTPSA id c68sm26475526pfj.41.2016.02.23.02.45.02 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Feb 2016 02:45:02 -0800 (PST) From: Bryan Ford Content-Type: multipart/signed; boundary="Apple-Mail=_CF36275F-F4EA-48FD-975E-77410095E1FF"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <2771EB48-C7CD-4454-91EF-480F4FA1EBE7@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Date: Tue, 23 Feb 2016 02:45:01 -0800 References: <566BF6F4.7050100@gmail.com> To: "tls@ietf.org" In-Reply-To: <566BF6F4.7050100@gmail.com> X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [TLS] Prototype of TLS 1.3 records, padding, and optional headerless records X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 10:45:12 -0000 --Apple-Mail=_CF36275F-F4EA-48FD-975E-77410095E1FF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii In followup to my talk in the TRON workshop, I have opened the following = Issue proposing to make unencrypted headers optional, as per my earlier = E-mails on Dec 1 and 12: https://github.com/tlswg/tls13-spec/issues/422 Add encrypted NextRecordLength field to make next record's = unencrypted header optional The precise (1- or 2-byte) encoding I leave for further discussion. Thanks Bryan > On Dec 12, 2015, at 2:29 AM, Bryan A Ford = wrote: >=20 > Since a lot of the skepticism toward my encrypted-headers proposal > constituted worries whether the benefits are worth the implementation > cost/complexity, I decided to implement it and find out what that cost > and complexity actually is. See this github repo: >=20 > https://github.com/bford/nss >=20 > Here you'll find a snapshot of Mozilla NSS/NSPR, with three branches: > (a) current baseline version supporting only TLS 1.2 records; (b) a > version that adds support for the currently-specified TLS 1.3 record > format with the encrypted content-type trailer and padding within the > AEAD; and (c) a further extension to support optional "headerless" > records. This doesn't implement all the other new stuff in TLS 1.3 = such > as negotiation, 0-RTT, etc. - only the record-layer changes. >=20 > --- > Observations from implementing TLS 1.3 records: >=20 > The baseline...master diff (https://github.com/bford/nss/pull/1/files) > represents the changes that appear needed to get from TLS 1.2 records = to > TLS 1.3 record format, with padding of records to a constant size for > traffic analysis protection. I set the fixed padded record length > (TLS13_PAD_FRAGMENT_LENGTH) to 256 bytes "just because", but change it > to whatever you like; I don't have any fish to fry regarding the > specific "best" value. 512 and 1024 also seem like reasonable = choices, > with obvious tradeoffs between wasted bytes padding small messages > versus the bandwidth and processing overheads of fewer bytes per = record. >=20 > Measuring implementation complexity simplistically by line count, this > diff constitutes +92-14=3D78 lines (92 added, 14 removed) - nothing = too > serious. Subjectively, the main implementation came from adding the > 1-byte internal content-type trailer in the first place, which means > having to copy the input cleartext into the write buffer in order to > fiddle with it before passing it to the AEAD encryptor. Thus, because > of this 1-byte content-type trailer (even with no padding), we can no > longer just encrypt directly from the caller-provided input into the > ciphertext buffer but have to copy the cleartext first, unless the = AEAD > API supports scatter/gather (which NSS's doesn't and I expect most > probably won't). >=20 > This doesn't seem like a big problem to me and I definitely consider = the > benefits of the encrypted content type and record padding to be worth > this minor cost. And in practice I doubt it'll cause any actual > noticeable performance degradation because a > copy-A-to-B-then-encrypt-in-place-at-B is going to have a pretty = similar > cache footprint as an encrypt-from-A-to-B. >=20 > TLS 1.3 also already changes the way the pseudo-header is calculated = for > MAC purposes; I didn't yet fully implement those changes, but did > already need to move the pseudo-header calculation on the send side > until a bit later when the length of the ciphertext is known. >=20 > --- > Headerless records extension: >=20 > The other pull request (https://github.com/bford/nss/pull/2/files) > represents the further delta needed to implement a further simplified > version of my last "encrypted headers" proposal, which in this > incarnation becomes "headerless records". Since TLS 1.3 is already > adding a 1-byte mandatory encrypted trailer within each record (the > encrypted content-type), I simply extended this to a 3-byte trailer, = in > which the first two bytes indicate: >=20 > - If zero, the next record (following this one) has the usual 5-byte = TLS > header and its length is defined by that header as usual. > - If nonzero, the next record has *no* TLS header at all, and its = length > is defined by this value. >=20 > By combining the "next-record-length" into the encrypted trailer that > TLS 1.3 is adding anyway, the changes required are pretty minimal. By > my count, this is a delta of +40-8=3D32 lines, which at least to me = seems > pretty insignificant in terms of implementation complexity. And > implementations could be even simpler by not implementing the = send-side > logic at all and simply setting all next-record-length fields in the > trailers to zero, attaching headers to all records as before. The = only > minor point of "implementation pain" is the need to add the = appropriate > inter-record state variables (writeNextLength and readNextLength), but > the handling of these are not fundamentally any different from the = state > needed to keep track of sequence numbers across records for example. >=20 > Making headerless records optional, selected by the trailer in the = prior > record as defined above, offers several nice benefits: >=20 > - It address the concerns that have been raised (though = unsubstantiated > so far with any concrete evidence) about breaking middleboxes that = want > to parse traditional TLS record streams. TLS implementations that are > paranoid to this degree about breaking middleboxes can simply always = set > the next-header-length field in the trailer to 0 and send cleartext > record headers for every TLS record just as before. >=20 > - We don't need to do anything special to handle the "first record" > case: i.e., we neither need to specify a standard "first record = length" > nor add a first-record-length field to one of the negotiation packets. > Instead, the first AEAD-encrypted record is simply transmitted with a > 5-byte header as usual, but the sender can omit the headers from > subsequent records if it chooses to. >=20 > - A TLS 1.3 implementation that doesn't want to bother "predicting" or > "committing to" a next-record-length beyond a SSL_Write() boundary can > simply set the next-record-length field to zero in the last record of > the current write, so the first record in the next SSL_Write() will > including a header determining its size as before. This isn't ideal = in > terms of traffic analysis protection, but it's an implementation = option. >=20 > - FWIW, when the sender transmits headerless records, the encoding = saves > 2 bytes per record with respect to TLS 1.2 (saving the 5-byte = cleartext > header but adding the 3-byte encrypted trailer). >=20 > --- > Implications on padded record transmission: >=20 > Finally, while implementing this extension I realized a further = general > benefit of headerless transmission: it can make the use of padding for > traffic analysis protection more bandwidth-efficient. >=20 > With cleartext headers, to achieve the traffic analysis benefits of > padding we must ensure that every transmitted record has *exactly* the > same ciphertext length, since any variation will produce a readily > fingerprintable pattern in cleartext. This creates tradeoffs, as = noted > above. Padding to a smaller fixed size (e.g., 256 bytes) adds less > bandwidth overhead to small messages such as typical HTTP requests but > incurs the cost of a MAC tag, nonce, TLS headers/trailers etc once = every > 256 bytes - for AES-GCM this is about an 11% bandwidth overhead with > 256-byte records. Padding to a larger fixed size (e.g., 1024) reduces > the bandwidth overhead for bulk data transmission such as large HTTP > responses (e.g., to about 3% overhead with 1024-byte records), at a = cost > of adding a lot of bandwidth overhead to tiny HTTP requests or > status-indication responses, which are also common. >=20 > With headerless records, in contrast, we can pick a relatively small > ciphertext length padding granularity (e.g., 256 bytes), but then the > sender can transmit records whose sizes are any *multiple* of this > granularity, because N consecutive 256-byte ciphertexts are now > cryptographically indistinguishable from a single N*256-byte = ciphertext. > Thus, we get the bandwidth-efficiency benefits of small records by > avoiding the need to add too much padding to small messages, plus the > bandwidth-efficiency benefits of larger records for bulk transmission. > For example, we can send a large message mostly consisting of > ~16384-byte records, each containing only one MAC tag and internal TLS > 1.3 trailer (though an eavesdropper won't know that), reducing the > bandwidth overhead in the AES-GCM case from 11% to 0.2%. >=20 > There are two minor caveats to this: >=20 > - In the specific case of AES-GCM, it looks like TLS 1.2 uses AES-GCM > with explicitly transmitted nonces, which are clearly distinguishable > from random values and hence will break the above benefits. The > solution is simple, however: simply make TLS 1.3 use AES-GCM (and = other > AEAD schemes) without explicit nonces. These nonces can be calculated > implicitly by sender and receiver just as easily without explicit > transmission, and all the necessary integrity-checking happens via the > "additional_data" pseudo-header anyway. (In fact perhaps TLS 1.3 > already eliminates the explicit nonce - I don't see any mention of it = in > the new record spec anyway, the only question is whether it's still in > the AES-GCM-specific specs, which I haven't looked at closely and = don't > know if they'll be updated wrt TLS 1.3 or not.) >=20 > - Even if N 256-byte ciphertexts in a TLS 1.3 stream are > cryptographically indistinguishable from one N*256-byte ciphertext, if > the TLS sender implementation transmits these in a single OS write(), > the OS's TCP stack may (or may not, depending on circumstances) still > reveal this difference by segmenting transmitted TCP segments > differently. There are several obvious solutions to this, however: >=20 > (1) The TLS implementation could prepare the N*256-byte = ciphertext but > then transmit it using N separate 256-byte write() calls to the > underlying TCP stack. This might (again depending on the TCP stack) > increase the TCP-level overhead by sending many smaller-than-necessary > TCP segments, but is a fully OS-independent solution, and we still = save > the TLS-level bandwidth overhead (one MAC tag etc rather than N). >=20 > (2) Better, at least on Linux systems, the TLS implementation = could > simply enable the TCP_CORK socket option, causing the kernel to delay > the transmission of incomplete (less-than-MTU-sized) TCP segments > slightly in hopes of "filling" them. This way, the TLS sender will > always produce continuous streams of MTU-sized TCP segments for all > "bursts" of transmission of any number of TLS records. The downside = is > that the kernel-imposed delay can add a bit of latency (I understand > around 200ms) to the transmission of the very last, incomplete segment > in a burst, thus perhaps adding up to 200ms to the total > request/response latency of a round-trip interactive exchange. >=20 > (3) Still better, again on Linux systems, the TLS implementation = could > send records using send() instead of write(), and set the MSG_MORE = flag > on all records except for the last record just before the connection > goes idle (no more data to transmit). Figuring out when a connection > is "going idle" may require some heuristics or hints from the > application, but can ensure that bursts are transmitted as a fully > uniform series of MTU-size segments without incurring any added delay = at > the end. >=20 > --- > OK, congratulations and thanks to anyone who persisted through all = that. > I hope this will help understand the implementation complexity and > tradeoffs both of the currently-specified TLS 1.3 record layer and the > proposed headerless records features. Comments? >=20 > Thanks > Bryan >=20 --Apple-Mail=_CF36275F-F4EA-48FD-975E-77410095E1FF Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ+DCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUEwggQpoAMCAQICEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcNAQELBQAwgZsxCzAJBgNV BAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAY BgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xNTA2MjQwMDAwMDBaFw0xNjA2 MjMyMzU5NTlaMCYxJDAiBgkqhkiG9w0BCQEWFWJyeW5vc2F1cnVzQGdtYWlsLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAMA89U5ktW7a1k5qjaiycbEbBjLucLdRfzKh5us59o1a Qi0iRQfo1BEq6rG4MTvXburjxUdzuTCaDgOJ+g6PFKNfJP5H2lH962EXCNeJYKOwhpZtwVzpfsPV 8iKw7XjPwPiW4E7Ut7M1UHoN57yUy60/047gyYpZirf4lpv1G//cFcLKIMNB/GGK5YXNlBNalvMY Z/CK1yo8cf3s83gI4KGGE65RL1i3WpAFjwaffp5V6kp3PdiIXuKL8kO2HWID/McrynKKb46ARFzC joiV2qHn27LQiMwBwoDUxzfgCAxAl0uWaFgBqLmcws4lCIXN8jIHp6CNLKKyHHXWukv/EqUCAwEA AaOCAfMwggHvMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBSlca2J DhGBY+vVSOfJ1I+3I9NqLzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wIAYDVR0RBBkwF4EVYnJ5bm9zYXVydXNAZ21haWwuY29tMA0GCSqGSIb3 DQEBCwUAA4IBAQAMNIE1FhYCtEA9JMwLoNKtQ4hZDcnUKYRcRihDhAHIKSTJtFQKBchp1MBTCP4P 1lfgdDHG+06Rv65VAKfBsjqMZmPQylvsxZg5kPJ5BPVgShQxGl5RSlMN3qLDcSbQt/6uPv9U+Vgq 8StMI6fIRSbbPwyKyZyM8gUnxR34dxzJ+mSGi0kdtUE36FIabTeXtjFVXN/2jDOrsvm8IHlp8nJM 23nHuqUsJyyIYFbaRKhApoMAzC5gynlg6APV2hz/JYlKSJABwpxZjYAtpyz5rQVIi2pPWs2Te2cd faykisGAOu/7nJtlcEGMCSd61tM43matZPa3MuBiko8kuzj0RMigMYIDwzCCA78CAQEwgbAwgZsx CzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZv cmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBD bGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQFqWbTcRwZIVaBthymnmm 6jAJBgUrDgMCGgUAoIIB5zAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNjAyMjMxMDQ1MDFaMCMGCSqGSIb3DQEJBDEWBBQuIYJfMeCnib9PVByMZc7fpxOszjCBwQYJ KwYBBAGCNxAEMYGzMIGwMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEBalm03EcGSFWgbYcpp5puowgcMGCyqGSIb3DQEJEAILMYGzoIGwMIGbMQswCQYDVQQGEwJH QjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQK ExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEBalm03EcGSFWgbYcpp5puowDQYJKoZIhvcN AQEBBQAEggEAW7bykP81o0FxJlkI0Dzuv4ru8uZXS60OLRIbFDaxupmzgl1chvVzyZoSUpn3SY8r hehOTish2gzv5MGs57j5ObXjzlyZS0rDJnGsG7ZDovYR5LjJ0TcQSY3d4zJXXU4HBF7HOFt1RjT6 uBljMQyFtS7fQjTGt/lR/1BcypWiCqnib4ZM6CuTF3cPnalnrqRsvBDja3l1mbXw5kAX3yphIhq4 +yYgMhCTiYLo4yaMqlWYXr+mq66H31Hy6wsnt3FkjD2LW/CUswHBrkGSdvzAuApgKhGEJh3uwujC GT4m3q57Ee/h4JaZWGOWraaXiS3ZJOhjq+iU2Zw6SW5WpB8J1gAAAAAAAA== --Apple-Mail=_CF36275F-F4EA-48FD-975E-77410095E1FF-- From nobody Tue Feb 23 07:34:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5091B3457 for ; Tue, 23 Feb 2016 07:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.807 X-Spam-Level: X-Spam-Status: No, score=-0.807 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BogOU3dwBe1o for ; Tue, 23 Feb 2016 07:34: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 2803C1B3453 for ; Tue, 23 Feb 2016 07:34:42 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4ABF942370A for ; Tue, 23 Feb 2016 15:34:41 +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 35161423703 for ; Tue, 23 Feb 2016 15:34:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456241681; bh=CC5XkizaFl1Sd/owwpoKqcg2sKeSVVI8TaoYykR9G/g=; l=2555; h=From:To:Date:From; b=CCimpWXdhAqxTSid0Zt+7qDzqbI2DyWMH8LdzZ9VF3SKMPH7Y5m6PSx1xENoA3pkR rryGdSryDi/64ClFSjZWOwcPYqnrV8DJ7UtSXGa2H/LyXJ/Rb4qGjhu9Pfn0eu06+v mkY29+z4lfGoGtcdkfBGNj70aHwrFxWSwiqBG7Wk= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1CD201FC87 for ; Tue, 23 Feb 2016 15:34:41 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 23 Feb 2016 09:34:40 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1076.000; Tue, 23 Feb 2016 09:34:40 -0600 From: "Salz, Rich" To: "tls@ietf.org" Thread-Topic: SRP ? Thread-Index: AdFuT674UuyzJsa5Tha9ZPuI0hYuYg== Date: Tue, 23 Feb 2016 15:34:39 +0000 Message-ID: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.94] Content-Type: multipart/alternative; boundary="_000_30c15e55fd524e8bbba814f4898c3f95ustx2exdag1mb1msgcorpak_" MIME-Version: 1.0 Archived-At: Subject: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 15:34:44 -0000 --_000_30c15e55fd524e8bbba814f4898c3f95ustx2exdag1mb1msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Is anyone using SRP with TLS? The OpenSSL implementation in particular? -- Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz --_000_30c15e55fd524e8bbba814f4898c3f95ustx2exdag1mb1msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Is anyone using SRP with TLS?  The OpenSSL impl= ementation in particular?

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz<= /p>

 

--_000_30c15e55fd524e8bbba814f4898c3f95ustx2exdag1mb1msgcorpak_-- From nobody Tue Feb 23 07:43:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 263E81B2BEB for ; Tue, 23 Feb 2016 07:43:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.506 X-Spam-Level: X-Spam-Status: No, score=-14.506 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=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MafsgjfBzI5d for ; Tue, 23 Feb 2016 07:43:11 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21C5F1B2B37 for ; Tue, 23 Feb 2016 07:43:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3382; q=dns/txt; s=iport; t=1456242191; x=1457451791; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=o9seLGEmQcGSjPyn/jmwXiAMz1OdKp8JJhhmyngnc44=; b=QEEdJae+v2vDOfrV0ticBrpDZ7PTuRGboOBItxONhEyE0Z4YTPWprA6x LmZ5hwck5GOKqWZgnZAXTycyJ7c/LVF3pNlwkr3cF041cgDq2vXn3AK3d 4NKCBfHYep0caNZ06g47sRelZ94Bm0P3Mdjf5qFQnLmTTSwk9CUAd+Me/ w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeAgAVfcxW/4ENJK1egm5MUm26aQENg?= =?us-ascii?q?WYXAQmFbAKBRDgUAQEBAQEBAWQnhEIBAQQBAQEqQQoRCwQUCRYPCQMCAQIBFTA?= =?us-ascii?q?TBgIBAYgXDrxbAQEBAQEBAQMBAQEBAQEBARQEikyFAYNuBY4eiGmNXokhhVCOS?= =?us-ascii?q?R4BAUKEAh4uiDkBAQE?= X-IronPort-AV: E=Sophos;i="5.22,489,1449532800"; d="scan'208,217";a="241551148" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2016 15:43:10 +0000 Received: from [10.21.172.61] ([10.21.172.61]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u1NFh9wx031406 for ; Tue, 23 Feb 2016 15:43:09 GMT To: tls@ietf.org References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> From: John Foley Message-ID: <56CC7E0D.9000106@cisco.com> Date: Tue, 23 Feb 2016 10:43:09 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------040701060005090307040204" Archived-At: Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 15:43:17 -0000 This is a multi-part message in MIME format. --------------040701060005090307040204 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Yes, Cisco uses this. On 02/23/2016 10:34 AM, Salz, Rich wrote: > > Is anyone using SRP with TLS? The OpenSSL implementation in particular? > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz@jabber.at Twitter: RichSalz > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------040701060005090307040204 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Yes, Cisco uses this.


On 02/23/2016 10:34 AM, Salz, Rich wrote:

Is anyone using SRP with TLS?  The OpenSSL implementation in particular?

 

-- 

Senior Architect, Akamai Technologies

IM: richsalz@jabber.at Twitter: RichSalz

 



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

--------------040701060005090307040204-- From nobody Tue Feb 23 09:42:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 711FA1ACE9A for ; Tue, 23 Feb 2016 09:42:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 YkZ6iIfQjytl for ; Tue, 23 Feb 2016 09:42:37 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AE81ACD3A for ; Tue, 23 Feb 2016 09:42:37 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id h129so152679122ywb.1 for ; Tue, 23 Feb 2016 09:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:content-type; bh=iNMSTq98xpcCPLEWXOdEgJherGYF1m23mo0qF8npRM0=; b=qOetAIvid+feq/adKI/CiJkvOWYDWKzO94u55aWeTSYpHt/XiKE+Ih/FdKCYVf8A6N 2qxbrlgjbmQA4/WUzmtX1MM8F3JQFKwPaU0g3QocxwUNwSHYe5xKNytHM53blV65I27V jyNcafj/jHxO1PCitZZFtL4DJdJm7klHCI+AY= 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 :content-type; bh=iNMSTq98xpcCPLEWXOdEgJherGYF1m23mo0qF8npRM0=; b=SknZ8YHGkPc3k1bj1+rIukNm/dli7K8mY0f73sbe5E6IuzBPiSUUlb3OUNu/5LnZqy Bd9GaAiws8MFpEkCM3AdmldWixtzyEMY5Sjn5VbZYnSOySxWmUKV5fGlUIgv4qnQyfI1 jHFkFoh9W+EyBEQTFjuRM2awXGcDCOTaaTs0PC9ESHaTwy6K6FHMFFCK6fnfvc+evRoF wtPLWA1TLD99/SHLanxLgEmJ1dWl7/GK8Q4wMMX/CI9Amaixdfr8ZcVXxCm2og7Rk88A Gd1N9vLbVqk6rMt9zdous14ZaaUiXUM6937RGFFOEB9sENg9fZLjCVW6ITh6ptcBYXSu XbDQ== X-Gm-Message-State: AG10YOQNzLbY8fcfxCFGQ7vUzQDeq1xkeuyKK8jfhvXFs+1gDdCXIYD1QstDlbcsKKl3u+V6nuM6YlbBlkWMNFKl X-Received: by 10.13.243.67 with SMTP id c64mr17889695ywf.306.1456249356828; Tue, 23 Feb 2016 09:42:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.86.67 with HTTP; Tue, 23 Feb 2016 09:42:17 -0800 (PST) From: Nick Sullivan Date: Tue, 23 Feb 2016 09:42:17 -0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=94eb2c0355749e75da052c737940 Archived-At: Subject: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 17:42:39 -0000 --94eb2c0355749e75da052c737940 Content-Type: text/plain; charset=UTF-8 Draft 11 currently supports both ServerConfiguration and PSK + Session Ticket for session resumption (0RTT or otherwise). Both mechanisms have the same properties in terms of forward secrecy: a compromise of the server's private data (whether PSK, session ticket key, or DH exponent) lets an attacker retroactively decrypt data from all sessions established with the PSK or Session Ticket. However, both mechanisms contain different language around how the lifetimes of the resumption data is managed. After some discussion with Facebook and others, I'd like to suggest a change in the wording of the draft to make the Session Ticket lifetime more closely resemble the lifetime of the ServerConfiguration. Here is the current language for session ticket lifetimes: ticket_lifetime_hint Indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order from the time of ticket issuance. A value of zero is reserved to indicate that the lifetime of the ticket is unspecified. The ticket lifetime hint is informative only. A client SHOULD delete the ticket and associated state when the time expires. It MAY delete the ticket earlier based on local policy. A server MAY treat a ticket as valid for a shorter or longer period of time than what is stated in the ticket_lifetime_hint. And for SeverConfigurations: struct { opaque configuration_id<1..2^16-1>; uint32 expiration_date; KeyShareEntry static_key_share; EarlyDataType early_data_type; ConfigurationExtension extensions<0..2^16-1>; } ServerConfiguration; expiration_date The last time when this configuration is expected to be valid (in seconds since the Unix epoch). Servers MUST NOT use any value more than 604800 seconds (7 days) in the future. Clients MUST NOT cache configurations for longer than 7 days, regardless of the expiration_date. [[OPEN ISSUE: Is this the right value? The idea is just to minimize exposure.]] My proposed change is to change the session ticket lifetime hint to a strict lifetime along the lines of the ServerConfiguration: ticket_lifetime Indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order from the time of ticket issuance. Servers MUST NOT use any value more than 604800 seconds (7 days). The value of zero indicates that the ticket should be discarded immediately. Clients MUST NOT cache session tickets for longer than 7 days, regardless of the ticket_lifetime. It MAY delete the ticket earlier based on local policy. A server MAY treat a ticket as valid for a shorter period of time than what is stated in the ticket_lifetime. The full change is on Github as a pull request: https://github.com/tlswg/tls13-spec/pull/424 Note that this new wording is more strict than that of RFC 5077, which does not specify a maximum lifetime for session tickets or dictate that the hint be followed in any way by either client or server. The introduction of the resumption master secret strengthened the forward secrecy story in TLS by requiring resumed connections to use new session keys. The proposed logic strengthens the forward secrecy story of TLS even further by creating a hard limit on the lifetime of unused resumption master secrets. Nick --94eb2c0355749e75da052c737940 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Draft 11 currently supports both ServerConfigura= tion and PSK + Session Ticket for session resumption (0RTT or otherwise). B= oth mechanisms have the same properties in terms of forward secrecy: a comp= romise of the server's private data (whether PSK, session ticket key, o= r DH exponent) lets an attacker retroactively decrypt data from all session= s established with the PSK or Session Ticket. However, both mechanisms cont= ain different language around how the lifetimes of the resumption data is m= anaged.

After some discussion with Facebook and others, I'd like= to suggest a change in the wording of the draft to make the Session Ticket= lifetime more closely resemble the lifetime of the ServerConfiguration.
Here is the current language for session ticket lifetimes:

ticket_lifetime_hint
Indicates the lifetime = in seconds as a 32-bit unsigned integer in network byte order from the time= of ticket issuance. A value of zero is reserved to indicate that the lifet= ime of the ticket is unspecified.

The ticket lifetime hint is inform= ative only. A client SHOULD delete the ticket and associated state when the= time expires. It MAY delete the ticket earlier based on local policy. A se= rver MAY treat a ticket as valid for a shorter or longer period of time tha= n what is stated in the ticket_lifetime_hint.

And for SeverCon= figurations:
=C2=A0 struct {
= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque configuration_id<1..2^16-1>;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uint32 expiration_date;
=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 KeyShareEntry static_key_share;
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 EarlyDataType early_data_type;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Con= figurationExtension extensions<0..2^16-1>;
=C2=A0 } ServerConfigur= ation;

expiration_date

= The last time when this configuration is expected to be valid (in seconds s= ince the Unix epoch). Servers MUST NOT use any value more than 604800 secon= ds (7 days) in the future. Clients MUST NOT cache configurations for longer= than 7 days, regardless of the expiration_date. [[OPEN ISSUE: Is this the = right value? The idea is just to minimize exposure.]]

My= proposed change is to change the session ticket lifetime hint to a strict = lifetime along the lines of the ServerConfiguration:

ticket_lif= etime
Indicates the lifetime in seconds as a 32-bit=20 unsigned integer in network byte order from the time of ticket issuance. Servers MUST NOT use any value more than 604800 seconds (7 days). The value= of zero indicates that the ticket should be discarded immediately. Clients= MUST NOT cache session tickets for longer than 7 days, regardless of the t= icket_lifetime. It MAY delete the ticket earlier based on local policy. A= =20 server MAY treat a ticket as valid for a shorter period of=20 time than what is stated in the ticket_lifetime.

The full= change is on Github as a pull request:
https://github.com/tlswg/tls13-spec/pul= l/424

Note that this new wording is more strict than that of RFC= 5077, which does not specify a maximum lifetime for session tickets or dic= tate that the hint be followed in any way by either client or server.
The introduction of the resumption master secret strengthened the forward= secrecy story in TLS by requiring resumed connections to use new session k= eys. The proposed logic strengthens the forward secrecy story of TLS even f= urther by creating a hard limit on the lifetime of unused resumption master= secrets.

Nick
--94eb2c0355749e75da052c737940-- From nobody Tue Feb 23 10:43:37 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EEF1A1B5D for ; Tue, 23 Feb 2016 10:43:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.717 X-Spam-Level: X-Spam-Status: No, score=-0.717 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=-0.006, SPF_PASS=-0.001] autolearn=ham Received: 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_vDwKd1XaE for ; Tue, 23 Feb 2016 10:43: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 359C41A1B4B for ; Tue, 23 Feb 2016 10:43:33 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8BF65423784; Tue, 23 Feb 2016 18:43:32 +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 67988423766; Tue, 23 Feb 2016 18:43:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456253012; bh=zI2SGPxjcC35w3wbbERoogI56LZRoVOz8I1Loo77WXk=; l=3624; h=To:References:From:Date:In-Reply-To:From; b=JjGXbKMvUnDqnaBne6xNWdbCmFb0EmF8F2RrZr63SLcjkry6NMQ2CKrYQsyW6rHz9 HLf0sXsDUZ2DnivMr0URoh48I+UtTWsHjhmUgK1c9pvYBf5KyOFdAaFEiuUceLP1bM g4IWsfFYa4XihgPAfylWbDolHENZaJylEN1cSXoE= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 374771FC8C; Tue, 23 Feb 2016 18:43:32 +0000 (GMT) To: Nick Sullivan , tls@ietf.org References: From: Benjamin Kaduk Message-ID: <56CCA853.4070601@akamai.com> Date: Tue, 23 Feb 2016 12:43:31 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------050003090905040909030106" Archived-At: Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 18:43:35 -0000 This is a multi-part message in MIME format. --------------050003090905040909030106 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 02/23/2016 11:42 AM, Nick Sullivan wrote: > My proposed change is to change the session ticket lifetime hint to a > strict lifetime along the lines of the ServerConfiguration: > But leave it as a relative time, contrasting the absolute expiration time of the server configuration -- why not go for full-out parallelism? -Ben > ticket_lifetime > Indicates the lifetime in seconds as a 32-bit unsigned integer in > network byte order from the time of ticket issuance. Servers MUST NOT > use any value more than 604800 seconds (7 days). The value of zero > indicates that the ticket should be discarded immediately. Clients > MUST NOT cache session tickets for longer than 7 days, regardless of > the ticket_lifetime. It MAY delete the ticket earlier based on local > policy. A server MAY treat a ticket as valid for a shorter period of > time than what is stated in the ticket_lifetime. > > The full change is on Github as a pull request: > https://github.com/tlswg/tls13-spec/pull/424 > --------------050003090905040909030106 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit On 02/23/2016 11:42 AM, Nick Sullivan wrote:
My proposed change is to change the session ticket lifetime hint to a strict lifetime along the lines of the ServerConfiguration:


But leave it as a relative time, contrasting the absolute expiration time of the server configuration -- why not go for full-out parallelism?

-Ben

ticket_lifetime
Indicates the lifetime in seconds as a 32-bit unsigned integer in network byte order from the time of ticket issuance. Servers MUST NOT use any value more than 604800 seconds (7 days). The value of zero indicates that the ticket should be discarded immediately. Clients MUST NOT cache session tickets for longer than 7 days, regardless of the ticket_lifetime. It MAY delete the ticket earlier based on local policy. A server MAY treat a ticket as valid for a shorter period of time than what is stated in the ticket_lifetime.

The full change is on Github as a pull request:

--------------050003090905040909030106-- From nobody Tue Feb 23 10:47:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481D41A21BC for ; Tue, 23 Feb 2016 10:47:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tphG2rY8lJZV for ; Tue, 23 Feb 2016 10:47:51 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F871A1BE9 for ; Tue, 23 Feb 2016 10:47:51 -0800 (PST) Received: from pps.filterd (m0001255.ppops.net [127.0.0.1]) by mx0b-00082601.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1NIkvVJ001791; Tue, 23 Feb 2016 10:47:42 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=pULj0/fuBsuhYUaBHqLYhIprRMY60rOQdX1WF5YsJyY=; b=JVnalJbJ5hVqlo6W5ws/ADUJEwOhr8RZgg4GT28n8G4LMMegmjRM8+qirOlIb7iUmKyz 0PLMMDzxBDO/eHI6UPn6DNJf1Wi3JTJEcyCwXT4YZE+vbm8/cPFA63UihGIetF4wz3qb jfALgTgjEolqJM0FIN+Bzd+EitAb6aXnY6I= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0b-00082601.pphosted.com with ESMTP id 2189n8usea-2 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 23 Feb 2016 10:47:42 -0800 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.151]) by PRN-CHUB07.TheFacebook.com ([fe80::d38:43fc:554e:146a%12]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 10:46:34 -0800 From: Subodh Iyengar To: Benjamin Kaduk , Nick Sullivan , "tls@ietf.org" Thread-Topic: [TLS] Removing the "hint" from the Session Ticket Lifetime hint Thread-Index: AQHRbmGau7ZdmtJqV0qE3JnbE5+PR586fYiA//96DoA= Date: Tue, 23 Feb 2016 18:46:34 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99564E774A@PRN-MBX01-4.TheFacebook.com> References: , <56CCA853.4070601@akamai.com> In-Reply-To: <56CCA853.4070601@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E99564E774APRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-23_10:, , signatures=0 Archived-At: Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 18:47:53 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E99564E774APRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One other proposal which is related is to make server config have relative = time as well instead of absolute time. If we don't make this relative this = expiration time might not be practically enforceable due to clock skew. This enforcement is relevant in situations where compromise of the ephemera= l server config key is not the same as compromising the long term private k= ey, for example in a SSL key offloading infrastructure. I do not think relative time introduces any new threats because the server = still needs to prove possession of the private key to make new clients acce= pt a server config. Thus a compromise of a server config key should only af= fect the initial data of clients who have cached a config modulo relative e= xpiration time. Subodh Iyengar ________________________________ From: TLS [tls-bounces@ietf.org] on behalf of Benjamin Kaduk [bkaduk@akamai= .com] Sent: Tuesday, February 23, 2016 10:43 AM To: Nick Sullivan; tls@ietf.org Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hin= t On 02/23/2016 11:42 AM, Nick Sullivan wrote: My proposed change is to change the session ticket lifetime hint to a stric= t lifetime along the lines of the ServerConfiguration: But leave it as a relative time, contrasting the absolute expiration time o= f the server configuration -- why not go for full-out parallelism? -Ben ticket_lifetime Indicates the lifetime in seconds as a 32-bit unsigned integer in network b= yte order from the time of ticket issuance. Servers MUST NOT use any value = more than 604800 seconds (7 days). The value of zero indicates that the tic= ket should be discarded immediately. Clients MUST NOT cache session tickets= for longer than 7 days, regardless of the ticket_lifetime. It MAY delete t= he ticket earlier based on local policy. A server MAY treat a ticket as val= id for a shorter period of time than what is stated in the ticket_lifetime. The full change is on Github as a pull request: https://github.com/tlswg/tls13-spec/pull/424 --_000_974CF78E8475CD4CA398B1FCA21C8E99564E774APRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
One other proposal which is related is to make server config have re= lative time as well instead of absolute time. If we don't make this relative this expiration time might not be practically enforceable due to clock skew.
This enforcement is relevant in situations where compromise of the eph= emeral server config key is not the same as compromising the long term priv= ate key, for example in a SSL key offloading infrastructure. 

I do not think relative time introduces any new threats because the se= rver still needs to prove possession of the private key to make new clients= accept a server config. Thus a compromise of a server config key should on= ly affect the initial data of clients who have cached a config modulo relative expiration time.

Subodh Iyengar
From: TLS [tls-bounces@ietf.org] on behal= f of Benjamin Kaduk [bkaduk@akamai.com]
Sent: Tuesday, February 23, 2016 10:43 AM
To: Nick Sullivan; tls@ietf.org
Subject: Re: [TLS] Removing the "hint" from the Session Ti= cket Lifetime hint

On 02/23/2016 11:42 AM, Nick Sullivan wrote:
My proposed change is to change the session ticket lifetim= e hint to a strict lifetime along the lines of the ServerConfiguration:


But leave it as a relative time, contrasting the absolute expiration time o= f the server configuration -- why not go for full-out parallelism?

-Ben

ticket_lifetime
Indicates the lifetime in seconds as a 32-bit unsigned integer in network b= yte order from the time of ticket issuance. Servers MUST NOT use any value = more than 604800 seconds (7 days). The value of zero indicates that the tic= ket should be discarded immediately. Clients MUST NOT cache session tickets for longer than 7 days, regardless = of the ticket_lifetime. It MAY delete the ticket earlier based on local pol= icy. A server MAY treat a ticket as valid for a shorter period of time than= what is stated in the ticket_lifetime.

The full change is on Github as a pull request:

--_000_974CF78E8475CD4CA398B1FCA21C8E99564E774APRNMBX014TheFac_-- From nobody Tue Feb 23 10:54:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 963B11A6FBA for ; Tue, 23 Feb 2016 10:54:50 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kYVkG30Vg1w3 for ; Tue, 23 Feb 2016 10:54:48 -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 B183A1A702E for ; Tue, 23 Feb 2016 10:54:48 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id 9so225212228iom.1 for ; Tue, 23 Feb 2016 10:54:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=WX0KTq7IEQLmoHmcWN3JtaI4MG/fDoeeZ3sJseTJfUc=; b=D6FB6kZLH0MLyje4rFcawFpcyrflR9H0BQg3u63HPxfrtBaXTnBRLapZfwgybQipZa BgzgURYYu4W8DNXOX3eOLCbzCdYS+PV+7OjRwXMEy5tOk1+GpaG2ekbiMaTwYwupKQU5 EJqVpEXLMLed9ApLkZXlmRL8oILaiRndpn8hlR3kdxZF7cYgqYLYRBt2e/Dn2m1sXqq2 /rZOpRpSlBoKepke4BoE3VZuZ1dYmLxfUPw2loNE4HSaskN63fh4y86meZQwfCPscr8F 3nMmCSilds2V9zIXG4mkAQ88C8Y/uWgrqmBp1fNMkwfX/8THgDuSjL62voIoAko9jutj wsaA== 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:date :message-id:subject:from:to:cc:content-type; bh=WX0KTq7IEQLmoHmcWN3JtaI4MG/fDoeeZ3sJseTJfUc=; b=FOIL1HmLSbyDDNEuaJAPds0/l1A5i3+EKg/hkHrL8NQ+1PrkxtDOznI0ttnRFoxF+Q 9UiK88HyOeLo6px1p10i2mCNOWP6SMq+A2czMyOeUITLRWNX1/wPWFmx8qsBv0ehYQ9v kA4jcb7ZCzKo3s3Z45/JfE+4/DpJo8wLBjhCUr3p13c3l25QhncRUSmiH3ArAgT0plDC CFmW6P3Vl3JlxMbytXG9si0bs3dL7xfkoYC/p9qvFHiz5jBgtJNj+SIr3nWRPiwShbkm kONkM7LhEPmsyaIXRzj/nlXc0zj982aSp2EkhF/LlalkEMHOHyn9kZ5bH/kMAfhHyV+V EK1Q== X-Gm-Message-State: AG10YOSPVcbDl0FNy5ByQF/ZV7lNxGMJ7lca+LdHW4X7aoBtfd2Bzce2GmjREFS5l100ARQ/raFRqwziWhmhTQ== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr23781297iop.100.1456253688130; Tue, 23 Feb 2016 10:54:48 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 10:54:48 -0800 (PST) In-Reply-To: <56CCA853.4070601@akamai.com> References: <56CCA853.4070601@akamai.com> Date: Tue, 23 Feb 2016 10:54:48 -0800 Message-ID: From: Martin Thomson To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 18:54:50 -0000 On 23 February 2016 at 10:43, Benjamin Kaduk wrote: > But leave it as a relative time, contrasting the absolute expiration time of > the server configuration -- why not go for full-out parallelism? As I have said before, the value of absolute time here is that it allows for the use of server configuration outside of the context of the TLS 1.3 handshake. Given that we are now seriously discussing removing ServerConfiguration from TLS 1.3, this is probably moot. From nobody Tue Feb 23 10:58:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 709D11A7113 for ; Tue, 23 Feb 2016 10:58:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQEvoV1tzC2E for ; Tue, 23 Feb 2016 10:58:26 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0781.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::781]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B94231A6F30 for ; Tue, 23 Feb 2016 10:58:25 -0800 (PST) Received: from BN1AFFO11FD031.protection.gbl (10.58.52.30) by BN1AFFO11HUB036.protection.gbl (10.58.52.147) with Microsoft SMTP Server (TLS) id 15.1.415.6; Tue, 23 Feb 2016 18:58:03 +0000 Authentication-Results: spf=pass (sender IP is 198.105.204.2) smtp.mailfrom=five9.com; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=bestguesspass action=none header.from=five9.com; Received-SPF: Pass (protection.outlook.com: domain of five9.com designates 198.105.204.2 as permitted sender) receiver=protection.outlook.com; client-ip=198.105.204.2; helo=mx01.five9.com; Received: from mx01.five9.com (198.105.204.2) by BN1AFFO11FD031.mail.protection.outlook.com (10.58.52.185) with Microsoft SMTP Server (TLS) id 15.1.422.5 via Frontend Transport; Tue, 23 Feb 2016 18:58:03 +0000 Received: from MB01.five9.com (10.7.8.141) by mx01.five9.com (10.7.15.111) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 23 Feb 2016 10:57:03 -0800 Received: from MB02.five9.com ([fe80::ede6:8312:5207:4046]) by mb01.five9.com ([fe80::ddc6:159a:f53:8ee7%15]) with mapi id 14.03.0248.002; Tue, 23 Feb 2016 10:58:02 -0800 From: Ronald del Rosario To: Jeffrey Walton Thread-Topic: Request for information: Lightweight Mutual Authentication for Constrained Devices? Thread-Index: AQHRbmwekX97Tg03T0GxRI6hDwMtNQ== Date: Tue, 23 Feb 2016 18:58:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/0.0.0.160212 x-originating-ip: [10.7.8.130] Content-Type: multipart/alternative; boundary="_000_A64B319C48F1480AAD7F97851878EA9Afive9com_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD031; 1:UCVyZpwytwHJbBK4JoWeZsqALjQK5vc0Zc7wACvP+yWet+Rs2HZehkK0il6ioZyySgTnJtPsrEphvZaZAqYl/V6VNQxtaLwo25xD4wRpu8K4CHU8va9ISZwMS/NZjSuJgSaPsAQhQUMYBk91mE9s5HkV67BGKxvpSECA9LldlNhoKJ28Vc+ini23oZkSEuedXFgfvDNNeT7W3EPcIacGcDIuo2m2x5L++G22aUvDs6+rrYZyWogXzaXGOm5USj+w/O/V/JOduLjyN7pkMyeOme5oAIUvKpaA8pImlMpoIO89RJYpeM0cs4R4fj1S/pvUFASWgoe0Af12EpqCmjjJiDoQRYukQXLv2l7yYbWZ3AAUyT3uy3+ZvyIkFeuEsYNYgOaNTQeDUgb7FOnG5c1U60+O7Ykq8oHzcYIDAoXKyWA= X-Forefront-Antispam-Report: CIP:198.105.204.2; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(2980300002)(438002)(199003)(189002)(87936001)(3846002)(102836003)(53416004)(50986999)(54356999)(11100500001)(6806005)(189998001)(107886002)(5001970100001)(106116001)(512874002)(36756003)(83716003)(5008740100001)(30436002)(5003600100002)(300700001)(1096002)(1220700001)(2906002)(586003)(5004730100002)(6116002)(83506001)(82746002)(92566002)(229853001)(86362001)(2900100001)(16236675004)(4001350100001)(33656002)(19580405001)(106466001)(19580395003)(450100001)(5250100002)(5890100001)(4546004)(7099028)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1AFFO11HUB036; H:mx01.five9.com; FPR:; SPF:Pass; MLV:sfv; A:1; MX:1; LANG:en; X-MS-Office365-Filtering-Correlation-Id: d5cde0dd-b116-472d-d0c1-08d33c83424e X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 2:tpQFax0boYD6I3R8iz42JONFOImkRtAlhpRetf8DeWGbfl9vUK4QP0GdfUo+qZOxGaaJ089x/WnToUzmT2E0i03CA+cGW2yo3xITE+R04tQn0PDqjCrkcL8GaCHdgf7eokjmWhi3+Vyje79nMl78N3sWv5/Vph1rTcsT4FvzfY9CNCiPfQ4lJ9il3fU1gLFg; 3:ZBj+Jx/0YLVpo0/w1h2p5mX8t+Jo6bzccMUO02EHlN6Obd5kBIy36X+6R7sPM31/9O4aQFJ+A1loG3R8f+QfKpEQn6HYHRDPXnzhqHkQjsagykOuAkqI9l/rs+s/UiA4J6j1vXEADVCsbdYtP/ezU1dQRnn2/uNsQ3VDRY6Uz3BPLH1GED0ouSCChT/XQioabN0xqXCBpv6l/L6WpvvuTbkKbQ5rCk9+m4RRTr0LAR1EF2KnY16ItgFJwhlA6IKzViF8Zls6G4rrPd+YothyTA==; 25:T2uOhrUoMRlrqAuWqUb4U/hk22gEWDoXh7tDS5x37S9LekVXquRegBmpSxke19ENZ75wQd7R2fRx3SfqcGYj/tcpCJE4zyjLtxETmAlSjiyvjXFI+XPdA0HhdTqNDbghdUSnx7ndpQKnFt83sQB8+S1kkDpEBxxv+KJpJ97HNg7ifTg+mpblptWN6XRgcHbMnO+CFUis6zLNLHnmZLODHKUIu0l9OAe6t6I0edWj1arvj8zORdyeBMB+hxtqDSktLPM8e1MUxWLgRuHcUob/Uy1gheW5tFJ8qbkzqWUxMxGeKK1+W6lJ6PgbS0ZP0Mgy2qEYc4pghJayHui/yO7A5aHsJMEwPxNV7IxFGWaXaohoPos5YI48jzmH8CPb4YcGpbVEwiCJsg87/V9YdnkYdA== X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(8251501002); SRVR:BN1AFFO11HUB036; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 20:32HDtP+abHSVAWQUj0VgQSBzTkqkD3GlEed4ebccgFZ7zWobm1kIMBHcSudSqIlumfjANzJFGu339MehnMASOT+BE13qLUCWmCMKkQI8ZlFN7qJ57edG1efqR858PhOxB9PDpbw5DwfzGwQH+V21YRdNR2axl8yzaTaTZtogvYrrAE22XOzo6eRiAxvOt4M0Fr9XI2l/yZIc44SZmJKe0erhPqYcM/gSZLoyEPRoc6K85XQck8GFH1UkLGtHs+fPdt1Kh9mb3eGQItMlhR4u2jQ60HuqsxJzUpjiFJOVqp2ut6GO+8/RlfcVYD7zzVIiMFZqg+BxEvbfELDT33MGscFrk34I0d3Hx4A5oLPXCJvakbkR493hlaOIfargzUnLSgcmSqd56w6vfJBJkaChscK1bw4beD8hUYPgBxo+jtKkLssRagPt0wKlrJOEKCOdZjKt4zCOrfDXZnvNqOSJgFZcmkAH8k3k/SVlfinscDw6VXJ9ASZ4vzT3gAf7TeBK X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13015025)(13023025)(8121501046)(13024025)(13018025)(5005006)(13017025)(10201501046)(3002001); SRVR:BN1AFFO11HUB036; BCL:0; PCL:0; RULEID:; SRVR:BN1AFFO11HUB036; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 4:L0K4YsPU9vOkaCKXWURk8UcLEc1vS+OSuqHAKURo4BFRxxOcbatug8yXb5kpy15t43JsIV8D11jaSEuQUz1E/T7ayNyqd22M9hkpXiOW7QOtLGicTIgyToNWpKU5H4vNW9BHi2+jSrvIpETrH+ktUtmtyVNXKDmr3nO7rOp+l0sIYFvw3vW70BYlNXsZPJQPw3RE/Ey3B65cM90iZajQpQfgNkzmOUeIZh/nO4E6QnvQU1MVtK+6Qu+cMeN2wTn/gGW2/wjebrp4hIizgET7DiGlL6FCqF+VwKPqav4S9zaW04PVgyv+qJqi5JEfIv5hMdyMLf+KHYbYWY/7YxK0igFG93HL9jGAeyqH6sPACsvD2Xdy443bgTVKfWxV3dx0PFeislo//xz0DSw2iG/pBUmwV9WPBZBSkJev66bLzOn0hcXCQfZzHhNSWO+She4juNrQNZUsIFg7eWHYt3mKtg== X-Forefront-PRVS: 08617F610C X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BN1AFFO11HUB036; 23:NvsdIpXfaIaInySuPXbFMvNB3gMgzSabFfS5Lyn?= =?us-ascii?Q?hv/I0Y5lJRcXiShUzJfkCDzJ+o7YFgpZvq5MFr+yXtPqGg7DbLAWj/uXgcx7?= =?us-ascii?Q?5aSR3rD0pqIPtoBFVHnMYZtDC6un8+XvU8by70t0RGwBwr7GtfplPj/oVa88?= =?us-ascii?Q?1ohzivO8w27e5xGr8J+Ub/IYM4d2HIxsFjWjiSgunhU+HnZB0jrVaVAbJvV7?= =?us-ascii?Q?f+Vur3JWzTSQwgoCstf942MF8hMVK1vsZd7spifvTbl9umo5k9dpUTs5+mwm?= =?us-ascii?Q?/CfR7xm8CDx7OhjN4dB0bvPBmXWESPiGDVt4Zl+8wC8aLWT20gO1TxBgz60o?= =?us-ascii?Q?OMlrI38WtmV5xFqBB5MGc435dX9H9gmcpmHDmh5CnIC/v0IaBymv3qLhgq/0?= =?us-ascii?Q?SQ8lvLtXLc/D5k+JZsLwVRzp15i8jSCchsszPqeUTQoSOi2evwJYCm3aeeNZ?= =?us-ascii?Q?lQ2F/qbCcRkHPNT6BSWKxOCW7o4gtrw9V4M48L0HRhx9sRWvdZ3/618LGL8p?= =?us-ascii?Q?g2jXiGSuaDU+WBElPnYIZXQ/F6oj7fgtbcvu9Pmr+S3Zz+uPJt3FNquh0qm6?= =?us-ascii?Q?rQl6peC2p1kXbjGSmqOBkrthuwDLwo65gFdJxpIYJ7rjNu/mW/j/nqtjSFsf?= =?us-ascii?Q?3S0ofJ9TXjc/ll7NDYpkthX6icyC8EEAtHjDx7mhcaxE1cDy877tEQaYB082?= =?us-ascii?Q?bk5GWGkg3qmj6YTuzki4iiHeLkaVTdOUOrOwOuRKnGKSuIE9hmELpmJXBbPn?= =?us-ascii?Q?ua1lZZfrh/3EQ15MoWXMCSQil4SMbWMsM98p81kNW63lW0wZJa9bwdYkXLuz?= =?us-ascii?Q?zE9zyZvmRFkSFgewTS2CTbQ6CLkAZeCO5CpUBmmjIXcsMkNI4zvzCjh4OJUV?= =?us-ascii?Q?R4Aw/m9IfhtHMYf3ZcoO1fY+N88/e9LeICnLoWnrvf0TRiFnDOUO+aVYeaB4?= =?us-ascii?Q?GeF1Q/yQpn+BW/a7Z8zT94XhI1l6wTrQJKGFU/uU+A9dW0z/XmpJxJXmc9pl?= =?us-ascii?Q?8fC0JwcHp37hgRSoHeBHBbSss0mhWKlc1N+oQZdEoWibCiwJ571tGt2L8z8z?= =?us-ascii?Q?x8nhX5MO7ao4D4jhUTVIw7XefIqZqp+8fOf4+TdG5vySjFhfK54tq8G6DKjl?= =?us-ascii?Q?jkrR4HgsyzHTZNX07xNENT1mPy1lo2eN34MoaMVnfSTZFhxfiU3rnO62K1/t?= =?us-ascii?Q?TSjAxURAjljg6ghbakEDePXnoUL9X2K7CTjyKa2vD8WNQ2DxxaFzyAqrz1hE?= =?us-ascii?Q?RqCOhOXBpgU4GA7zAH5y3iEK6YN1fYPg/S0HMDxQ7?= X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11HUB036; 5:gH5Wb/c3zZELWgt8WDUwqAdyIzqzU/7uWLBoEBdc7RMCFIPgZ3sMclQn4QWJD7mxBThvN2oTV3rmL8sk/JL7zMMVvm9tXwr0ZJ5MX4FrTEKUXLKXeXF8B2kGmNBTCWUesGo6hMKv8vNjtm0+3xV4NA==; 24:9mGGngPO4iVtm0j/Oai/DYE+4SzEuysLUrxB2D/jqOQFQoKNH1AO3Xrq6MLSdvX2pAg+51dWEuCZSGD9FvrGif7JwMzV7o2iSFpoknwfyaE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: five9.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2016 18:58:03.6003 (UTC) X-MS-Exchange-CrossTenant-Id: 91df0123-f1fa-4e71-852c-e6bdacd1a9a1 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=91df0123-f1fa-4e71-852c-e6bdacd1a9a1; Ip=[198.105.204.2]; Helo=[mx01.five9.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN1AFFO11HUB036 Archived-At: Subject: [TLS] Request for information: Lightweight Mutual Authentication for Constrained Devices? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 18:58:28 -0000 --_000_A64B319C48F1480AAD7F97851878EA9Afive9com_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 R3JlZXRpbmdzIFRMUyBHcm91cCwNCg0KTG9va2luZyBmb3Igc3RhbmRhcmRzL2RyYWZ0cy9kb2N1 bWVudGF0aW9uIG9yIHNpbWlsYXIgcmVzZWFyY2ggZGlzY3Vzc2luZyBhIG11dHVhbCBhdXRoZW50 aWNhdGlvbiBmcmFtZXdvcmsgZm9yIGNvbnRhaW5lZCBkZXZpY2VzIChEZXZpY2VzIHdpdGggbGlt aXRlZCBwcm9jZXNzaW5nIHBvd2VyLCBiYXR0ZXJ5LCBydW5zIG9uIHdpcmVsZXNzIE5ldHdvcmsp DQoNClRoYW5rcyBpbiBhZHZhbmNlLA0KUm9uDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KQ09ORklERU5USUFMSVRZIE5PVElDRTogVGhpcyBlLW1haWwgYW5kIGFueSBm aWxlcyBhdHRhY2hlZCBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gb2YgRml2 ZTkgYW5kL29yIGl0cyBhZmZpbGlhdGVkIGVudGl0aWVzLiBBY2Nlc3MgYnkgdGhlIGludGVuZGVk IHJlY2lwaWVudCBvbmx5IGlzIGF1dGhvcml6ZWQuIEFueSBsaWFiaWxpdHkgYXJpc2luZyBmcm9t IGFueSBwYXJ0eSBhY3RpbmcsIG9yIHJlZnJhaW5pbmcgZnJvbSBhY3RpbmcsIG9uIGFueSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBlLW1haWwgaXMgaGVyZWJ5IGV4Y2x1ZGVkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHksIGRlc3Ryb3kgdGhlIG9yaWdpbmFsIHRyYW5zbWlzc2lvbiBhbmQgaXRz IGF0dGFjaG1lbnRzIGFuZCBkbyBub3QgZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhl ciBwZXJzb24sIHVzZSBpdCBmb3IgYW55IHB1cnBvc2UsIG9yIHN0b3JlIG9yIGNvcHkgdGhlIGlu Zm9ybWF0aW9uIGluIGFueSBtZWRpdW0uIENvcHlyaWdodCBpbiB0aGlzIGUtbWFpbCBhbmQgYW55 IGF0dGFjaG1lbnRzIGJlbG9uZ3MgdG8gRml2ZTkgYW5kL29yIGl0cyBhZmZpbGlhdGVkIGVudGl0 aWVzLg0K --_000_A64B319C48F1480AAD7F97851878EA9Afive9com_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx M3B4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5HcmVldGluZ3Mg VExTIEdyb3VwLDwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+TG9va2luZyBmb3Igc3Rh bmRhcmRzL2RyYWZ0cy9kb2N1bWVudGF0aW9uIG9yIHNpbWlsYXIgcmVzZWFyY2ggZGlzY3Vzc2lu ZyBhIG11dHVhbCBhdXRoZW50aWNhdGlvbiBmcmFtZXdvcmsgZm9yIGNvbnRhaW5lZCBkZXZpY2Vz IChEZXZpY2VzIHdpdGggbGltaXRlZCBwcm9jZXNzaW5nIHBvd2VyLCBiYXR0ZXJ5LCBydW5zIG9u IHdpcmVsZXNzIE5ldHdvcmspPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3Mg aW4gYWR2YW5jZSw8L2Rpdj4NCjxkaXY+Um9uPC9kaXY+DQo8YnI+DQo8YnI+DQo8aHI+DQo8Zm9u dCBmYWNlPSJBcmlhbCIgY29sb3I9IkdyYXkiIHNpemU9IjEiPjxicj4NCkNPTkZJREVOVElBTElU WSBOT1RJQ0U6IFRoaXMgZS1tYWlsIGFuZCBhbnkgZmlsZXMgYXR0YWNoZWQgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIGluZm9ybWF0aW9uIG9mIEZpdmU5IGFuZC9vciBpdHMgYWZmaWxpYXRlZCBl bnRpdGllcy4gQWNjZXNzIGJ5IHRoZSBpbnRlbmRlZCByZWNpcGllbnQgb25seSBpcyBhdXRob3Jp emVkLiBBbnkgbGlhYmlsaXR5IGFyaXNpbmcgZnJvbSBhbnkgcGFydHkgYWN0aW5nLCBvciByZWZy YWluaW5nIGZyb20gYWN0aW5nLA0KIG9uIGFueSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBlLW1haWwgaXMgaGVyZWJ5IGV4Y2x1ZGVkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQg cmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGRlc3Ryb3kg dGhlIG9yaWdpbmFsIHRyYW5zbWlzc2lvbiBhbmQgaXRzIGF0dGFjaG1lbnRzIGFuZCBkbyBub3Qg ZGlzY2xvc2UgdGhlIGNvbnRlbnRzIHRvIGFueSBvdGhlciBwZXJzb24sIHVzZSBpdA0KIGZvciBh bnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1 bS4gQ29weXJpZ2h0IGluIHRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgYmVsb25ncyB0 byBGaXZlOSBhbmQvb3IgaXRzIGFmZmlsaWF0ZWQgZW50aXRpZXMuPGJyPg0KPC9mb250Pg0KPGRp dj48L2Rpdj4NCjxkaXY+PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_A64B319C48F1480AAD7F97851878EA9Afive9com_-- From nobody Tue Feb 23 11:03:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2E51A8896 for ; Tue, 23 Feb 2016 11:03:55 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAHBviqYQF33 for ; Tue, 23 Feb 2016 11:03:54 -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 54E3E1A8897 for ; Tue, 23 Feb 2016 11:03:54 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id 9so225509861iom.1 for ; Tue, 23 Feb 2016 11:03:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ExTHFz7NtbKRhjmUW5v2z32+qy/ZJAPi98hKg2WTiwY=; b=oaER2pg0wF2evMowX6YC6psYWL285GEgB2204raA0UFQBk+87TE2HIOJndRjhEvpE2 pPYPof6W9tF1tirAbRmaGTDrOXI2py09uU/iE1+fH/zn7T2EQQlZuGD9aAzJ26rFJAie nGFq4CILMW6VXmE+bjgI0m9k5EXeWfkM/3ekIKECsvaZjgPDnVU5zUzvcd8utMExxXX1 3n6W2JSYxEu+opUkWfTCIFTtTao+rko/R2MBbHL8oD92zkvCical5gKKsZOJOtW72uWP S2+pnyJm+WPiAsXX1zNrvJOtXBvlG3+1zsnCkzbNyhr18NIkB1gC4hvwdQ8CVRk443pY QzwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=ExTHFz7NtbKRhjmUW5v2z32+qy/ZJAPi98hKg2WTiwY=; b=dVq7p6kiiBMIrbSr3hiFpRQIjLPg0nYRZSZYdn5WA6ijxxrU0v9TD40YaVQH4hgNLz niBuSzIhzoxOusKePw6SHERyMecsCL6ntm7f2OZrB52VjKhe6x7FMczxzZwLfejH+R89 dwGOoYNzs7NqqRBfErGDs4PO9BoWQVJ7A+4slrKG0uX+RQD3SR+A+7c085wQprmEGej9 57sdVTJm4FxLF5L6JbpdUucWY2kNdKBJE6JPHsFNfTMNuAlSV0xbOHrqhoSm4sF7RnjE N0vNdmi0UGWk4WXF0dfIdrJCEk0TEzB5xSUy025D41H/7SfMdJ3ODLmEdeldRRRyozKs I1/w== X-Gm-Message-State: AG10YOSpslH2T8woiYIFDk0UKdNwaMNRskTyU4zeTmh/ot/uNCEJafdukqwA4OuG+T49bReBGYagSyJ2yyMc2A== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr37551112iod.190.1456254233777; Tue, 23 Feb 2016 11:03:53 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 11:03:53 -0800 (PST) Date: Tue, 23 Feb 2016 11:03:53 -0800 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 19:03:56 -0000 Now that the other issue is in the bag, let's talk about making some real savings. I propose that we remove DH-based 0-RTT from TLS 1.3. As ekr's previous mail noted, the security properties of PSK-based 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is much more complex. For those who love DH-based 0-RTT, and I know that some people are fans, here's something that might make you less sad about removing it from the core spec. You can use DH out of band to negotiate a PSK. You might even do this as an extension to TLS, but that's of less value. If you - for example - had the offline configuration from https://unicorn-wg.github.io/tls-offline-config/ then you could simply state that using the included configuration identifier caused the session to have a "PSK". That "PSK" could be a value derived from a shared secret (g^xs) plus maybe HKDF that took the configuration as a label input. Then you get something that follows Hugo's existing analysis. What you don't get is in-TLS server configuration, but we've established that we don't really need that. From nobody Tue Feb 23 11:24:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E09271ACD39 for ; Tue, 23 Feb 2016 11:24:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.385 X-Spam-Level: X-Spam-Status: No, score=-1.385 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 y6W1jd4rsO-P for ; Tue, 23 Feb 2016 11:24:02 -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 E47D61ACD25 for ; Tue, 23 Feb 2016 11:24:01 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id h129so155200439ywb.1 for ; Tue, 23 Feb 2016 11:24:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RCCMcsHtGq2IHHhZw9A+wBL3OQVnBNECC2D0f1XrHUY=; b=hwXusX3rU8GCshvSzB6n970Y/0zHQam6uj0dZ+haN+fdDHff5IwhYV1Xt+a5dYqz0P hEOZvIqFZfrRB9Gh2lySzOsTA3I6SXdVxR+C7Bwe7ITU2AOSmQDUqcKaPYHzhSnz/f61 tr7usNdbGkgJN/8FuMgb1x52YY4XIpGlc+5qMKSQ+CkvcipHTWRv/2UIzAlFKMhSKtXl c4+NwV22cs41zmPnOJFQXFFLn/w/5hfbfYomk7CQ4V6ZEniqAHzCLvzgw9FXVhx3+Uw5 P+QQTeqRaPFmF2l7wolFsbgSe5v2sd3xnqdynqns6SqpZ5TWYAhadP8e2IYbl/NtiNcZ NICA== 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:date :message-id:subject:from:to:cc:content-type; bh=RCCMcsHtGq2IHHhZw9A+wBL3OQVnBNECC2D0f1XrHUY=; b=jVxWDC3mUAo9HByxo4cmr1crnynhv3CD03jIzgid5k/f9VVVtN7uoZXlg+msdpV/iv Qa0DrKvZTWgHn/2ps4IY5aZdCnM2I9QylQarXnUxwv9Mo4OIbL0iY+KfXxJiwDAh4VHH hPin0gUv2geesfPq+8unv39J5zC+dlAw7oguzebo0bDhFQFVgqbUh/4KnwbXNMlgC767 DIhkdVZlY1RvNJ5LKs2Ov7sQNxT3/QLppYRwnLLzRYLxAX9/qmNHaU24lOd9ocm9KSNO hG+iFZ1RUP6xsIbQC9D3lHXvtEYc2EWuCjyMMl8c2F1pmv4ekLF3Ytcp0kd/CXDf0udi TupQ== X-Gm-Message-State: AG10YOQfu1snfudosuBOQVsmVLe2VgdeRK1tip4Q5hGUV4eT7KMa2QgJqWKRPgExBqBCrHxmi8p8Km70834ltWo9 MIME-Version: 1.0 X-Received: by 10.13.231.132 with SMTP id q126mr17418198ywe.203.1456255441141; Tue, 23 Feb 2016 11:24:01 -0800 (PST) Received: by 10.37.119.141 with HTTP; Tue, 23 Feb 2016 11:24:00 -0800 (PST) In-Reply-To: References: Date: Tue, 23 Feb 2016 11:24:00 -0800 Message-ID: From: Wan-Teh Chang To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 19:24:03 -0000 DH-based 0-RTT requires server configuration, which is all public information and can be safely stored on disk. This makes it easy to do 0-RTT after an application restart. PSK-based 0-RTT requires PSK, which is secret key material. Storing PSKs on disk requires special care. Without storing PSKs on disk, we can't do 0-RTT after an application restart. It seems sufficient to just ban client authentication in replayable DH-based 0-RTT. Why remove DH-based 0-RTT altogether? Wan-Teh Chang From nobody Tue Feb 23 11:27:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A2E1A90D3 for ; Tue, 23 Feb 2016 11:27:12 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ms3OUM_jBaC4 for ; Tue, 23 Feb 2016 11:27:10 -0800 (PST) Received: from mail-ig0-x22a.google.com (mail-ig0-x22a.google.com [IPv6:2607:f8b0:4001: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 C0AD71ACD3F for ; Tue, 23 Feb 2016 11:27:10 -0800 (PST) Received: by mail-ig0-x22a.google.com with SMTP id z8so15585218ige.0 for ; Tue, 23 Feb 2016 11:27:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=q/vH3M93fs/f5iPXzra5FGaBs3pZk0QY51Kmos2l/3c=; b=kLokuxhD5h9/SU3iu7GEoaq6Aa1J1KtynN0fDdqnSw0MTZMI4X9z9ZMjglUWY9zkM+ bJ+ITr8frBfncA6oHZKEMPOttZ3PJ76KI+0WSgLawZk4iV4vdhTUhKuploZ7epucCrYx n/ycgCDLTCV5ZkQ9BJoRtpidgwfijkeAVwJMrVAs47vvJ7Eqlg3EUJXgXdDr3FrakyuU z5/F9SGqpsu7TXF645O2FIHRhuWq+aEwv4M1q9TXQfYeDzkVlK6AX6o7czDulIjjQJEi kutDvxPw0ekR7raV0FM6xbdJ8RDvxYuG3naKT3sZa/AJvkG4SS6WU5W8lNjpqHnn1mut E/2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=q/vH3M93fs/f5iPXzra5FGaBs3pZk0QY51Kmos2l/3c=; b=DR+JZFUWv9THAsFXdZ8FgWjZWMIqzjJgIgfArkbX5eyBQjQqPxq/PJwaSTNFMZGMwk pb46jwtqExuBdyc90NeuK62XIdIPB1lnd5Th3vp83SZriHr3qmuKvlw7l06aLofFpbkn 0C0eqjCCVGVYMmUApZz5CV5YdJqjp9YZDF6yq20W8Uu1zYKRmwocP8U/9kwSRj89qt4w 6ap3q5dJ+nHQex0T2xc3UmF1r8Km8CWgMYrFVpjWifUGjdAut6es/xSWnrl7BLjIxP8f cwK3UCkdnLSdW1hVfisev09QQ0p3F5jeVTirp8gz6WNqGO0D8G7Vwk2d81ao+NWh86SC Ok1A== X-Gm-Message-State: AG10YOSZqXSeOoFDJSfzw/9bH4DqT+ll6LMBlJaULejS1wqXF3VCf7Oi9Ivwo9h9KcSFXGYa48GNgvSOoqA2qA== MIME-Version: 1.0 X-Received: by 10.50.20.129 with SMTP id n1mr19612007ige.77.1456255630066; Tue, 23 Feb 2016 11:27:10 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 11:27:10 -0800 (PST) Date: Tue, 23 Feb 2016 11:27:10 -0800 Message-ID: From: Martin Thomson To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 19:27:12 -0000 Karthik raised some concerns here, and I think that we have some thinking to do. But I don't think that it is intractable, nor even hard, to reason about this problem. The only thing that the client's second flight provides is authentication. The Finished isn't needed if there is no client auth [P]. Hugo's presentation at TRON did not include a client Finished in the earlier, simpler examples. Thus, based on Watson's observation that the client authentication is removable, we might conclude that the handshake is complete from the perspective of a server that does not require client authentication. There are still reasons we might like to keep the client authentication in the handshake, but those are decisions we can make on engineering grounds. If post-handshake client authentication is OK, then 0.5 RTT is equally OK [X]. I would assert that any decision about changing keys after the client Finished applies to post-handshake client auth (or vice versa). If that logic is sound, then I see no reason we can't have some very simple advice: 1. if the server does not request client authentication, it can send application data immediately following its Finished 2. if the server requests client authentication, it MUST NOT send application data until it receives and validates the client's first flight. UNLESS the server is certain that the data it sends does not depend on the client's identity (that is, it would send this application data to anyone). >From an API perspective, I believe that we should recommend that there be a separate function for sending in condition 2, just as we are going to recommend that there is a separate function for sending 0-RTT data (as well as there being one to receive on the server end). Based on this, we should recommend different points in time for the server API to report that the handshake is "complete" at a server. In condition 1, the handshake is complete after the server Finished is sent; in condition 2, the handshake is complete after the client Finished is received. [P] Note that a client Finished does confirm a PSK. Though you might reasonably argue that successfully generating valid application data works equally well in that regard. [X] Post-handshake client authentication has only been analyzed very lightly, so we have to caveat that statement too. From nobody Tue Feb 23 11:38:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F2D21A90DF for ; Tue, 23 Feb 2016 11:38:32 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA88boDO8GCX for ; Tue, 23 Feb 2016 11:38:31 -0800 (PST) Received: from mail-ig0-x232.google.com (mail-ig0-x232.google.com [IPv6:2607:f8b0:4001: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 EBEF41A90DB for ; Tue, 23 Feb 2016 11:38:30 -0800 (PST) Received: by mail-ig0-x232.google.com with SMTP id y8so119101681igp.0 for ; Tue, 23 Feb 2016 11:38:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=7iibMqjb5lVMOo+/rvroE2P0srrRhE246Buv5yaOfeo=; b=TCLl0ancHV52cBygIJn1H8SII1ttEjae7fYhNEClnL8lD+djR0MmIPyaLDnhspP+IB odia1dDX7w9R7Ld1/8UaQG75Pk+/pYYDfvginD58J7T8RyTnfOyJd/aZZtD1Dd7jmtSN be/WILUDZdOlYTqVy9nSiO8wHCvUk9BcyZv+rqvw4WbMpv8kuWmgzD8RDEJkyFIK7QzR cwsMFuOlYHmQ9hdU2rr7Cnz0tpEuQthkp39jkdeI/JssdligWaNKE9sW5QWCKHwdH87m RkEaUV6zqWneITlN1O8O1yQfLb1WbYDYbESJxSimt0HU8cWcDlm3KSH6/jqbopv+xRc2 g6LA== 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:date :message-id:subject:from:to:cc; bh=7iibMqjb5lVMOo+/rvroE2P0srrRhE246Buv5yaOfeo=; b=de8jh0tehGj5iTXw45yUBuoVYy9YH0NgfTHNDIEYcu9TPsXHHLxlc52rmOE+cxD3aF pQHb1L4jrcCK7ItfHYemNGmzsSiVq5nFya3QShOxXnJ+O1uljh0UwG3hkyV94dcs5xdn kfO6QsSzsmUPtywLN4XcKCyKHTrPOvV8qqaH3EtaICRP0ag0zvvomUeaQW/vIki8mI7D dtMMDajRcWPeuOE7y1kSJ6kS9hv7aPNuYnkwocgD/atEMDBnlfHVxNCNXlkCs5udU+s3 qnUiZWxfttB6z5Ki0CsM7t66Kp77rLmdFHOnRV8Ej2i6cKe04hbdB+ne+ng/kJ7NvyDN jTUg== X-Gm-Message-State: AG10YOS/s0GL9VmiQ0dJUpmdFVifwk7l0deV+dFVOXQ19ddXJSjrGIe6zw6yhKLTJBNexWy6B1iZAAqMVkqG3g== MIME-Version: 1.0 X-Received: by 10.50.28.105 with SMTP id a9mr19889545igh.94.1456256310326; Tue, 23 Feb 2016 11:38:30 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 11:38:30 -0800 (PST) In-Reply-To: References: Date: Tue, 23 Feb 2016 11:38:30 -0800 Message-ID: From: Martin Thomson To: Wan-Teh Chang Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 19:38:32 -0000 On 23 February 2016 at 11:24, Wan-Teh Chang wrote: > It seems sufficient to just ban client authentication in replayable > DH-based 0-RTT. Why remove DH-based 0-RTT altogether? On the grounds that it is more complex to analyze, build, and test. And given that deferring the feature does no significant harm to those who want it. I acknowledge that persistence of secrets on clients is a material difference between that an PSK-based 0-RTT. I just don't think that it's a good enough reason to pay for what is a relatively expensive feature. From nobody Tue Feb 23 12:02:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75E61ACDBC for ; Tue, 23 Feb 2016 12:02:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SbsI_O5LSko3 for ; Tue, 23 Feb 2016 12:02:50 -0800 (PST) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98C321A90A3 for ; Tue, 23 Feb 2016 12:02:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=W4iIWIoxANnu/uboDl6YL44OF3S3TQWDNEpOJaYLW+A=; b=nXCBoa8Cqo7Ae7F+zU3EsgG5fKyYMgdDxzIWOn6tOTBoLycy/HvWjRGvAtbebxn4ED2E1i+a4+xyNFzAjcnGiycTek/ckg3QM+cTnuxtD6ut99ifuneuQqVoIZvodol8imTdUnwaR2zCRFBUzRAArvZp7IZu55xmLm9Ut/Z1pVM= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) with Microsoft SMTP Server (TLS) id 15.1.409.15; Tue, 23 Feb 2016 20:02:10 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0409.024; Tue, 23 Feb 2016 20:02:10 +0000 From: Andrei Popov To: Martin Thomson , Wan-Teh Chang Thread-Topic: [TLS] Remove DH-based 0-RTT Thread-Index: AQHRbmz48/+gRnfGcEOC087b5Dkw9Z86AqQAgAAEDQCAAAWGUA== Date: Tue, 23 Feb 2016 20:02:10 +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=microsoft.com; x-originating-ip: [2001:4898:80e8:b::1d2] x-ms-office365-filtering-correlation-id: 967e8a8a-19ed-4315-b85b-08d33c8c3726 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1396; 5:UhtjsyNS0+PNbN94JHiRU4oj40562pvCoqwgGr7KI6CySu0TOaB3fVvImFdQDHzugZgz20tZVpTF5WLJvG9fMmg/oOYExmBp1B1kuyvFwt/i8zvhoN3PsjdkswYr/P9Q3SdCXVfIhZ/OPQ2Y4lpXOQ==; 24:A3ucmNbqQoDGKze2xooksWzUYj9ocZqajvxE/k/MRAqn8U2HwfBACMCvpdB/JcjRO7MuxrARiFkrrVcYUUqWLCMai759y2rpLDnSUMWtSfU= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1396; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(61426038)(61427038); SRVR:BLUPR03MB1396; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1396; x-forefront-prvs: 08617F610C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(13464003)(377454003)(87936001)(1096002)(50986999)(11100500001)(102836003)(54356999)(189998001)(76176999)(5001960100002)(106116001)(5003600100002)(86362001)(4326007)(1220700001)(586003)(5002640100001)(5008740100001)(5004730100002)(2906002)(3660700001)(15975445007)(74316001)(6116002)(3280700002)(99286002)(92566002)(86612001)(2950100001)(10400500002)(2900100001)(40100003)(5001770100001)(5005710100001)(10290500002)(8990500004)(122556002)(33656002)(19580395003)(19580405001)(77096005)(10090500001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1396; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2016 20:02:10.5869 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1396 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 20:02:52 -0000 For general-purpose TLS stacks that have to support PSK anyway (and therefo= re already deal with PSK persistence issues), removing DH-based 0-RTT is a = significant simplification. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson Sent: Tuesday, February 23, 2016 11:39 AM To: Wan-Teh Chang Cc: tls@ietf.org Subject: Re: [TLS] Remove DH-based 0-RTT On 23 February 2016 at 11:24, Wan-Teh Chang wrote: > It seems sufficient to just ban client authentication in replayable=20 > DH-based 0-RTT. Why remove DH-based 0-RTT altogether? On the grounds that it is more complex to analyze, build, and test. And given that deferring the feature does no significant harm to those who = want it. I acknowledge that persistence of secrets on clients is a material differen= ce between that an PSK-based 0-RTT. I just don't think that it's a good en= ough reason to pay for what is a relatively expensive feature. _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c= om%7cf17dcaeb65eb4ecc907e08d33c88ed75%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3DiUfZJINzquzcxHr7W6Xf1bo8P34UfkneZOVwj8TjWP0%3d From nobody Tue Feb 23 12:13:07 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 273621B2C1D for ; Tue, 23 Feb 2016 12:13:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huPAmE2CTOHq for ; Tue, 23 Feb 2016 12:13:01 -0800 (PST) Received: from odin.smetech.net (x-bolt-wan.smeinc.net [209.135.219.146]) by ietfa.amsl.com (Postfix) with ESMTP id 83C3F1B2C0B for ; Tue, 23 Feb 2016 12:13:01 -0800 (PST) Received: from localhost (unknown [209.135.209.5]) by odin.smetech.net (Postfix) with ESMTP id 016BCF9C014; Tue, 23 Feb 2016 15:13:00 -0500 (EST) X-Virus-Scanned: amavisd-new at smetech.net Received: from odin.smetech.net ([209.135.209.4]) by localhost (ronin.smeinc.net [209.135.209.5]) (amavisd-new, port 10024) with ESMTP id 7LQr9C0JuJak; Tue, 23 Feb 2016 15:11:37 -0500 (EST) Received: from new-host-3.home (pool-108-51-128-219.washdc.fios.verizon.net [108.51.128.219]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by odin.smetech.net (Postfix) with ESMTP id 10891F9C00F; Tue, 23 Feb 2016 15:12:49 -0500 (EST) Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: multipart/alternative; boundary=Apple-Mail-118--937684868 From: Russ Housley In-Reply-To: Date: Tue, 23 Feb 2016 15:12:48 -0500 Message-Id: <12E9A44C-57CB-4EDD-A3A9-A623C11DD0C7@vigilsec.com> References: To: Nick Sullivan X-Mailer: Apple Mail (2.1085) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 20:13:05 -0000 --Apple-Mail-118--937684868 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It makes sense to me that the lifetimes be the same. Russ On Feb 23, 2016, at 12:42 PM, Nick Sullivan wrote: > Draft 11 currently supports both ServerConfiguration and PSK + Session = Ticket for session resumption (0RTT or otherwise). Both mechanisms have = the same properties in terms of forward secrecy: a compromise of the = server's private data (whether PSK, session ticket key, or DH exponent) = lets an attacker retroactively decrypt data from all sessions = established with the PSK or Session Ticket. However, both mechanisms = contain different language around how the lifetimes of the resumption = data is managed. >=20 > After some discussion with Facebook and others, I'd like to suggest a = change in the wording of the draft to make the Session Ticket lifetime = more closely resemble the lifetime of the ServerConfiguration. >=20 > Here is the current language for session ticket lifetimes: >=20 > ticket_lifetime_hint > Indicates the lifetime in seconds as a 32-bit unsigned integer in = network byte order from the time of ticket issuance. A value of zero is = reserved to indicate that the lifetime of the ticket is unspecified. >=20 > The ticket lifetime hint is informative only. A client SHOULD delete = the ticket and associated state when the time expires. It MAY delete the = ticket earlier based on local policy. A server MAY treat a ticket as = valid for a shorter or longer period of time than what is stated in the = ticket_lifetime_hint. >=20 > And for SeverConfigurations: > struct { > opaque configuration_id<1..2^16-1>; > uint32 expiration_date; > KeyShareEntry static_key_share; > EarlyDataType early_data_type; > ConfigurationExtension extensions<0..2^16-1>; > } ServerConfiguration; >=20 > expiration_date >=20 > The last time when this configuration is expected to be valid (in = seconds since the Unix epoch). Servers MUST NOT use any value more than = 604800 seconds (7 days) in the future. Clients MUST NOT cache = configurations for longer than 7 days, regardless of the = expiration_date. [[OPEN ISSUE: Is this the right value? The idea is just = to minimize exposure.]] >=20 > My proposed change is to change the session ticket lifetime hint to a = strict lifetime along the lines of the ServerConfiguration: >=20 > ticket_lifetime > Indicates the lifetime in seconds as a 32-bit unsigned integer in = network byte order from the time of ticket issuance. Servers MUST NOT = use any value more than 604800 seconds (7 days). The value of zero = indicates that the ticket should be discarded immediately. Clients MUST = NOT cache session tickets for longer than 7 days, regardless of the = ticket_lifetime. It MAY delete the ticket earlier based on local policy. = A server MAY treat a ticket as valid for a shorter period of time than = what is stated in the ticket_lifetime. >=20 > The full change is on Github as a pull request: > https://github.com/tlswg/tls13-spec/pull/424 >=20 > Note that this new wording is more strict than that of RFC 5077, which = does not specify a maximum lifetime for session tickets or dictate that = the hint be followed in any way by either client or server. >=20 > The introduction of the resumption master secret strengthened the = forward secrecy story in TLS by requiring resumed connections to use new = session keys. The proposed logic strengthens the forward secrecy story = of TLS even further by creating a hard limit on the lifetime of unused = resumption master secrets. >=20 > Nick > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-118--937684868 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It = makes sense to me that the lifetimes be the = same.

Russ


On = Feb 23, 2016, at 12:42 PM, Nick Sullivan wrote:

Draft 11 currently supports both = ServerConfiguration and PSK + Session Ticket for session resumption = (0RTT or otherwise). Both mechanisms have the same properties in terms = of forward secrecy: a compromise of the server's private data (whether = PSK, session ticket key, or DH exponent) lets an attacker retroactively = decrypt data from all sessions established with the PSK or Session = Ticket. However, both mechanisms contain different language around how = the lifetimes of the resumption data is managed.

After some = discussion with Facebook and others, I'd like to suggest a change in the = wording of the draft to make the Session Ticket lifetime more closely = resemble the lifetime of the ServerConfiguration.

Here is the = current language for session ticket lifetimes:

ticket_lifetime_hint
Indicates the = lifetime in seconds as a 32-bit unsigned integer in network byte order = from the time of ticket issuance. A value of zero is reserved to = indicate that the lifetime of the ticket is unspecified.

The = ticket lifetime hint is informative only. A client SHOULD delete the = ticket and associated state when the time expires. It MAY delete the = ticket earlier based on local policy. A server MAY treat a ticket as = valid for a shorter or longer period of time than what is stated in the = ticket_lifetime_hint.

And for = SeverConfigurations:
  = struct {
      opaque = configuration_id<1..2^16-1>;
      = uint32 expiration_date;
      KeyShareEntry = static_key_share;
      EarlyDataType = early_data_type;
      = ConfigurationExtension extensions<0..2^16-1>;
  } = ServerConfiguration;

expiration_date

The last time when = this configuration is expected to be valid (in seconds since the Unix = epoch). Servers MUST NOT use any value more than 604800 seconds (7 days) = in the future. Clients MUST NOT cache configurations for longer than 7 = days, regardless of the expiration_date. [[OPEN ISSUE: Is this the right = value? The idea is just to minimize exposure.]]

My = proposed change is to change the session ticket lifetime hint to a = strict lifetime along the lines of the = ServerConfiguration:

ticket_lifetime
Indicates the = lifetime in seconds as a 32-bit=20 unsigned integer in network byte order from the time of ticket issuance. Servers MUST NOT use any value more than 604800 seconds (7 days). The = value of zero indicates that the ticket should be discarded immediately. = Clients MUST NOT cache session tickets for longer than 7 days, = regardless of the ticket_lifetime. It MAY delete the ticket earlier = based on local policy. A=20 server MAY treat a ticket as valid for a shorter period of=20 time than what is stated in the ticket_lifetime.

The = full change is on Github as a pull request:
https://github.com/t= lswg/tls13-spec/pull/424

Note that this new wording is more = strict than that of RFC 5077, which does not specify a maximum lifetime = for session tickets or dictate that the hint be followed in any way by = either client or server.

The introduction of the resumption = master secret strengthened the forward secrecy story in TLS by requiring = resumed connections to use new session keys. The proposed logic = strengthens the forward secrecy story of TLS even further by creating a = hard limit on the lifetime of unused resumption master = secrets.

Nick
_______________________________________________
TLS mailing = list
TLS@ietf.org
https://www.ietf.org/ma= ilman/listinfo/tls

= --Apple-Mail-118--937684868-- From nobody Tue Feb 23 12:14:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CE8A1A010C for ; Tue, 23 Feb 2016 12:14:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyjlSElJdxW1 for ; Tue, 23 Feb 2016 12:14:48 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 1975C1B2D38 for ; Tue, 23 Feb 2016 12:14:48 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 50741200019; Tue, 23 Feb 2016 20:14:47 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 3ACDF200001; Tue, 23 Feb 2016 20:14:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456258487; bh=XfbA1cyxaBKMTNKDWBIgCwqcp79h8UAh0AEXix8fjas=; l=210; h=From:To:Date:References:In-Reply-To:From; b=X/e2yXQ6zAZMq16Sry+HGUivi4h4NEMaKVxU6Z80NW7Mi9LjGut1+DtBLmrAaUidB EYPzDwEDvujg8ZRVIZpN9LgvLfLOY5dh93N3EcHSG8+nejz2Gw+0WiE6LMYOnRFqvJ R+VgpjqXT/jbQATBwE+mXJnUqGHkkjam1g1sq7uE= Received: from email.msg.corp.akamai.com (ustx2ex-cas2.msg.corp.akamai.com [172.27.25.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 390F51E07C; Tue, 23 Feb 2016 20:14:47 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 23 Feb 2016 12:14:46 -0800 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1076.000; Tue, 23 Feb 2016 14:14:46 -0600 From: "Salz, Rich" To: Russ Housley , "tls@ietf.org" Thread-Topic: [TLS] Removing the "hint" from the Session Ticket Lifetime hint Thread-Index: AQHRbmGb3qhL4MwHBkCIipZK7uo5JJ86dPMA//+bxTA= Date: Tue, 23 Feb 2016 20:14:46 +0000 Message-ID: References: <12E9A44C-57CB-4EDD-A3A9-A623C11DD0C7@vigilsec.com> In-Reply-To: <12E9A44C-57CB-4EDD-A3A9-A623C11DD0C7@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.41.89] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 20:14:50 -0000 Absolute lifetimes seem more robust; e.g., if you find one lying around, yo= u don't have enough context to know if it's still good or not. We went from relative to absolute times in ACME for this reason. From nobody Tue Feb 23 12:43:19 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1D91B2EA9 for ; Tue, 23 Feb 2016 12:43:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSvUNrKM7X0f for ; Tue, 23 Feb 2016 12:43:16 -0800 (PST) Received: from lb2-smtp-cloud2.xs4all.net (lb2-smtp-cloud2.xs4all.net [194.109.24.25]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6C51B2C0D for ; Tue, 23 Feb 2016 12:43:15 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id MwjB1s00b10HQrX01wjDub; Tue, 23 Feb 2016 21:43:13 +0100 Message-ID: <56CCC45F.9060105@openfortress.nl> Date: Tue, 23 Feb 2016 21:43:11 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: "Salz, Rich" References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 20:43:18 -0000 Hi, > Is anyone using SRP with TLS? The OpenSSL implementation in particular? > We're considering it too, although not necessarily through OpenSSL. Also I'd really prefer an ECDH-based formalism; I'm note sure if work on that is being done, or where. -Rick From nobody Tue Feb 23 12:49:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 368CF1B3098 for ; Tue, 23 Feb 2016 12:49:07 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OypnHWgX57HB for ; Tue, 23 Feb 2016 12:49:05 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::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 DB96A1B302D for ; Tue, 23 Feb 2016 12:49:04 -0800 (PST) Received: by mail-pa0-x234.google.com with SMTP id ho8so119370049pac.2 for ; Tue, 23 Feb 2016 12:49:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Fm/HqqEOs8YeWx1mO06pmQ2ASvg7vD8ZxTptdhykZ/E=; b=VhM+M6G0RIVzOJsUy9d96NjfbWw1S0qPX/NSkLTe2q9iCo2joQmwl7yDXkJ2rkiRqn dzXxGPIPlhsqEnNg1LkNCRxp9NdBKwEuHQ0/RL2T5F4ofHoWMRnQukmhElXyEMbsWLEI S7ni07AvkzDozHAfyoPpjLYGmYorltZ90PKtRM5LrPOlq6bDaiAZ5AgcYKvICSnIKXsg /K12zzR52KMfp0SatDOOGOqLGEtCI+biyGKblaXpFp1y7kFs843xOgrWGiHQfrQ110rg 4gBnBF5P1wkMpt+8sV7dVYLsEK07LmCR5Eqy3DvCJEIph1PCuejWRbAJ7CrO+2NKfB+o DSrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=Fm/HqqEOs8YeWx1mO06pmQ2ASvg7vD8ZxTptdhykZ/E=; b=NNy3IBCpEpCWAvety1b0+X2lYy1rQ1tCSQsJsIlABl0i2UW/B9fO/cvRucFzvk6jYB 4XvVKNjRbO4XwhRiifCg17n5Bte9fBExJ0LIxAtgIXRMErllwDEAoAzXEj2hYyTL29zt jh6N0s0wQioxPhd0dxCiUjS0hvdL81mkEBuXAOo1eeBGtm4/I2SmQ4w52FQCHd++zOZL ujkdDmwIpsQ2QlfLFS8Ok5eJ+bPFKIB3GJokH861ZQRgMyntOkJ8LY9/lcUvNhHndTwV kNm6Ot8q6aPS5aqJs1nUf8nH/41YOhjEJb0AuZsx8pQhSg9/DzBhqkEAj2FoklWAaUi6 syXQ== X-Gm-Message-State: AG10YOTzERIpHrCsTgCSBYoFCWV2TeHnEzKI0Nmhsp2/S9U0QpsrU56lfanf/7ystNgzrw== X-Received: by 10.66.191.104 with SMTP id gx8mr49009234pac.21.1456260544510; Tue, 23 Feb 2016 12:49:04 -0800 (PST) Received: from [30.30.30.117] (rrcs-24-43-243-163.west.biz.rr.com. [24.43.243.163]) by smtp.gmail.com with ESMTPSA id l62sm46166719pfj.7.2016.02.23.12.49.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 12:49:03 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Tue, 23 Feb 2016 12:49:02 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 20:49:07 -0000 There are some fears about 0.5-RTT data that do not necessarily apply to = post-client authentication, at which point at least both parties have = sent their Finished messages. When the server is sending 0.5-RTT data, this is effectively = false-start; the client hasn=E2=80=99t confirmed its choice of = ciphersuites yet, and downgrade attacks may become possible. To be principled, we should look at the current browser best practices = for false start and make sure that 0.5-RTT data abides by them. For example, one may argue that 0.5-RTT is actually a bit worse than = false-start in TLS 1.2 where at least the peer=E2=80=99s presence and = DH key has been authenticated before false start data is sent.=20 There is no such guarantee in 0.5-RTT. The question is whether this is just a server-side concern, or does the = client need to be aware of 0.5-RTT.=20 I don=E2=80=99t know the answer to that, but if we wanted to setup a = 0.5-RTT rule, I would say that it should *only* be sent during PSK-resumption handshakes, because the PSK authenticates = the peer, and because the server is likely responding to some 0-RTT data sent by the client/ Again maybe this breaks some server push scenarios that I am not aware = of. Best, Karthik PS: The OPTLS proof does not require ClientFinished, but they do not = consider downgrades or client auth.=20 On the whole, cryptographers including the authors of OPTLS would = be happier with 0.5-RTT keys=20 not being the same as 1-RTT keys. Again, so far, this is a matter = of taste and proof modularity. > On 23 Feb 2016, at 11:27, Martin Thomson = wrote: >=20 > Karthik raised some concerns here, and I think that we have some > thinking to do. But I don't think that it is intractable, nor even > hard, to reason about this problem. >=20 > The only thing that the client's second flight provides is > authentication. The Finished isn't needed if there is no client auth > [P]. Hugo's presentation at TRON did not include a client Finished in > the earlier, simpler examples. >=20 > Thus, based on Watson's observation that the client authentication is > removable, we might conclude that the handshake is complete from the > perspective of a server that does not require client authentication. > There are still reasons we might like to keep the client > authentication in the handshake, but those are decisions we can make > on engineering grounds. >=20 > If post-handshake client authentication is OK, then 0.5 RTT is equally > OK [X]. I would assert that any decision about changing keys after > the client Finished applies to post-handshake client auth (or vice > versa). >=20 > If that logic is sound, then I see no reason we can't have some very > simple advice: >=20 > 1. if the server does not request client authentication, it can send > application data immediately following its Finished >=20 > 2. if the server requests client authentication, it MUST NOT send > application data until it receives and validates the client's first > flight. UNLESS the server is certain that the data it sends does not > depend on the client's identity (that is, it would send this > application data to anyone). >=20 >> =46rom an API perspective, I believe that we should recommend that = there > be a separate function for sending in condition 2, just as we are > going to recommend that there is a separate function for sending 0-RTT > data (as well as there being one to receive on the server end). >=20 > Based on this, we should recommend different points in time for the > server API to report that the handshake is "complete" at a server. In > condition 1, the handshake is complete after the server Finished is > sent; in condition 2, the handshake is complete after the client > Finished is received. >=20 >=20 > [P] Note that a client Finished does confirm a PSK. Though you might > reasonably argue that successfully generating valid application data > works equally well in that regard. > [X] Post-handshake client authentication has only been analyzed very > lightly, so we have to caveat that statement too. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Feb 23 13:25:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B96E01B334D for ; Tue, 23 Feb 2016 13:25:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 T5kjPwv1Lg1k for ; Tue, 23 Feb 2016 13:25:05 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF7B1B3349 for ; Tue, 23 Feb 2016 13:25:04 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id l143so124271263lfe.2 for ; Tue, 23 Feb 2016 13:25:04 -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:content-type; bh=COjdTfzaET0sBC2v5bOKzwog45KYLUswpm36IaeSAyw=; b=ae8eotztN3tvdjP0KoGY86YnrL2ec10hG9/tMoF4FcFoJO2UEkD66USRDJ/tuwGeTv jvqUVP8V99iSOPE85ZXGmkDs3Y0GlBjCImu78DV7KGyu9kt9N+W5e90NLrHLB8EpX0ZK J58ziEfHKy0kB+DcH7+m2DubAvTH6hZSoXh4n3YJHwRLISnOwjGpgb0kwVBUvP5/NNDR rf01sIZ7tn0Tp43SJgWtKtphoBsPsHWSJrUIErVrVoSf64D3+d4M2CJP2c95O6KmYexL M0yu0IGgN5IhMx0kZVftiagfe1IJD8KGT3D/fOr2RfLrkWibEkqQ1a7K8/RLSbi6+1K2 tfyQ== 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:content-type; bh=COjdTfzaET0sBC2v5bOKzwog45KYLUswpm36IaeSAyw=; b=D4AWUpgoVs5isUw6hLlBWLkPzi9iyzJOkoiamLWZ7wqwLjUlniZF4CAx50bCpoMIaY YtbYTASRklkYtled+34GN8LjnsEhYD1WKlI1TWVvz2eVhNd3zlSPO8EsKtX9QAzR8Qo1 Vta+pf1GPnXveAp+KzsQ/dE+9yn48eyrhN7WiRYlMEwfFZkj5504oxZZ/Ai8pjeEpV87 Fj3rpwg1GKh+mu99UQUiuH+S2jlNIiaMJ6WWg7zfrILP2uPtUlGgozRz1Yi7dTZOpInd kbWhLbCpGRwX6VelYJAititRV9Hkna8O3VDxEsFOY6/HJlS7CTxXQRNHW6RUEMX0mpCd r/6Q== X-Gm-Message-State: AG10YOR3J9R1kn4+uSo5AnTTOvkk1GZi90q1k8Kx36pN3bOf1B65Zc7IeqIFdSRaHxMFy2TECK6VZKkKywQfqw== X-Received: by 10.25.21.90 with SMTP id l87mr12984477lfi.64.1456262702766; Tue, 23 Feb 2016 13:25:02 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Tue, 23 Feb 2016 13:24:33 -0800 (PST) In-Reply-To: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> From: Hugo Krawczyk Date: Tue, 23 Feb 2016 16:24:33 -0500 X-Google-Sender-Auth: pTR4lhOQztK7Bkyf4mKiOKK8J68 Message-ID: To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a113d9b54191f82052c76959b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 21:25:07 -0000 --001a113d9b54191f82052c76959b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 23, 2016 at 3:49 PM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > There are some fears about 0.5-RTT data that do not necessarily apply to > post-client authentication, at which point at least both parties have sen= t > their Finished messages. > > When the server is sending 0.5-RTT data, this is effectively false-start; > the client hasn=E2=80=99t confirmed its choice of ciphersuites yet, and d= owngrade > attacks may become possible. > To be principled, we should look at the current browser best practices fo= r > false start and make sure that 0.5-RTT data abides by them. > For example, one may argue that 0.5-RTT is actually a bit worse than > false-start in TLS 1.2 where at least the peer=E2=80=99s presence and DH= key has > been authenticated before false start data is sent. > There is no such guarantee in 0.5-RTT. > > The question is whether this is just a server-side concern, or does the > client need to be aware of 0.5-RTT. > I don=E2=80=99t know the answer to that, but if we wanted to setup a 0.5-= RTT rule, > I would say that it should *only* > be sent during PSK-resumption handshakes, because the PSK authenticates > the peer, and because > the server is likely responding to some 0-RTT data sent by the client/ > > Again maybe this breaks some server push scenarios that I am not aware of= . > > Best, > Karthik > > PS: The OPTLS proof does not require ClientFinished, but they do not > consider downgrades or client auth. > =E2=80=8BThat's right, we do not consider downgrades or client authenticati= on but Martin's suggestion explicitly only applies to the case=E2=80=8B where the = server does not require client authentication so the analysis holds in that case. As for downgrades, this will be discovered by the server when receiving the client's Finished message. So the only problem I see is that the server might have been "tricked" to send the 0.5-RTT data with less protection than intended by the (honest) client. But for that there is no need for downgrade. The attacker could have generated the exchange with the weaker ciphersuite by himself (acting as a client). If the server accepts that ciphersuite it means he is willing to send that particular data with that level of security to *anyone*. That is the meaning of not requiring client authentication. =E2=80=8BOne useful feature of client's finished is to catch 0-RTT replays.= But even then I am not sure what damage can be done to the 0.5 data. Either the attacker knows the client's keying material (say PSK) and can generate the client finished by himself or he doesn't know that keying material but then it cannot decrypt 0.5 data. Am I missing something on these particular points? On the whole, cryptographers including the authors of OPTLS would be > happier with 0.5-RTT keys > not being the same as 1-RTT keys. Again, so far, this is a matter > of taste and proof modularity. > =E2=80=8BAgreed. Hugo =E2=80=8B > > On 23 Feb 2016, at 11:27, Martin Thomson > wrote: > > > > Karthik raised some concerns here, and I think that we have some > > thinking to do. But I don't think that it is intractable, nor even > > hard, to reason about this problem. > > > > The only thing that the client's second flight provides is > > authentication. The Finished isn't needed if there is no client auth > > [P]. Hugo's presentation at TRON did not include a client Finished in > > the earlier, simpler examples. > > > > Thus, based on Watson's observation that the client authentication is > > removable, we might conclude that the handshake is complete from the > > perspective of a server that does not require client authentication. > > There are still reasons we might like to keep the client > > authentication in the handshake, but those are decisions we can make > > on engineering grounds. > > > > If post-handshake client authentication is OK, then 0.5 RTT is equally > > OK [X]. I would assert that any decision about changing keys after > > the client Finished applies to post-handshake client auth (or vice > > versa). > > > > If that logic is sound, then I see no reason we can't have some very > > simple advice: > > > > 1. if the server does not request client authentication, it can send > > application data immediately following its Finished > > > > 2. if the server requests client authentication, it MUST NOT send > > application data until it receives and validates the client's first > > flight. UNLESS the server is certain that the data it sends does not > > depend on the client's identity (that is, it would send this > > application data to anyone). > > > >> From an API perspective, I believe that we should recommend that there > > be a separate function for sending in condition 2, just as we are > > going to recommend that there is a separate function for sending 0-RTT > > data (as well as there being one to receive on the server end). > > > > Based on this, we should recommend different points in time for the > > server API to report that the handshake is "complete" at a server. In > > condition 1, the handshake is complete after the server Finished is > > sent; in condition 2, the handshake is complete after the client > > Finished is received. > > > > > > [P] Note that a client Finished does confirm a PSK. Though you might > > reasonably argue that successfully generating valid application data > > works equally well in that regard. > > [X] Post-handshake client authentication has only been analyzed very > > lightly, so we have to caveat that statement too. > > > > _______________________________________________ > > 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 > --001a113d9b54191f82052c76959b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 23, 2016 at 3:49 PM, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wrote:
There are some fears about 0.5-RTT data that do not neces= sarily apply to post-client authentication, at which point at least both pa= rties have sent their Finished messages.

When the server is sending 0.5-RTT data, this is effectively false-start;= =C2=A0 the client hasn=E2=80=99t confirmed its choice of ciphersuites yet, = and downgrade attacks may become possible.
To be principled, we should look at the current browser best practices for = false start and=C2=A0 make sure that 0.5-RTT data abides by them.
For example, one may argue that 0.5-RTT is actually a bit worse than false-= start in TLS 1.2=C2=A0 where at least the peer=E2=80=99s presence and DH ke= y has been authenticated before false start data is sent.
There is no such guarantee in 0.5-RTT.

The question is whether this is just a server-side concern, or does the cli= ent need to be aware of 0.5-RTT.
I don=E2=80=99t know the answer to that, but if we wanted to setup a 0.5-RT= T rule, I would say that it should *only*
be sent during PSK-resumption handshakes, because the PSK authenticates the= peer, and because
the server is likely responding to some 0-RTT data sent by the client/

Again maybe this breaks some server push scenarios that I am not aware of.<= br>
Best,
Karthik

PS: The OPTLS proof does not require ClientFinished, but they do not consid= er downgrades or client auth.

=E2=80=8BThat's right, we do not consider downgrades or client authen= tication but Martin's suggestion explicitly only applies to the case=E2= =80=8B where the server does not require client authentication so the analy= sis holds in that case. As for downgrades, this will be discovered by the s= erver when receiving the client's Finished message. So the only problem= I see is that the server might have been "tricked" to send the 0= .5-RTT data with less protection than intended by the (honest) client. But = for that there is no need for downgrade. The attacker could have generated = the exchange with the weaker ciphersuite by himself (acting as a client). I= f the server accepts that ciphersuite it means he is willing to send that p= articular data with that level of security to *anyone*. That is the meaning= of not requiring client authentication.=C2=A0

=E2=80=8BOne useful feature of client's finished is to catch 0-RTT r= eplays. But even then I am not sure what damage can be done to the 0.5 data= . Either the attacker knows the client's keying material (say PSK) and = can generate the client finished by himself or he doesn't know that key= ing material but then it cannot decrypt 0.5 data.

Am I missing something on these particular points?



=C2=A0 =C2=A0 =C2=A0 =C2=A0On the whole, cryptographers including the autho= rs of OPTLS would be happier with 0.5-RTT keys
=C2=A0 =C2=A0 =C2=A0 =C2=A0not being the same as 1-RTT keys. Again, so far,= this is a matter of taste and proof modularity.
=C2= =A0

=E2=80=8BAgreed.
Hugo
=C2=A0
=E2=80=8B

> On 23 Feb 2016, at 11:27, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> Karthik raised some concerns here, and I think that we have some
> thinking to do.=C2=A0 But I don't think that it is intractable, no= r even
> hard, to reason about this problem.
>
> The only thing that the client's second flight provides is
> authentication.=C2=A0 The Finished isn't needed if there is no cli= ent auth
> [P].=C2=A0 Hugo's presentation at TRON did not include a client Fi= nished in
> the earlier, simpler examples.
>
> Thus, based on Watson's observation that the client authentication= is
> removable, we might conclude that the handshake is complete from the > perspective of a server that does not require client authentication. > There are still reasons we might like to keep the client
> authentication in the handshake, but those are decisions we can make > on engineering grounds.
>
> If post-handshake client authentication is OK, then 0.5 RTT is equally=
> OK [X].=C2=A0 I would assert that any decision about changing keys aft= er
> the client Finished applies to post-handshake client auth (or vice
> versa).
>
> If that logic is sound, then I see no reason we can't have some ve= ry
> simple advice:
>
>=C2=A0 1. if the server does not request client authentication, it can = send
> application data immediately following its Finished
>
>=C2=A0 2. if the server requests client authentication, it MUST NOT sen= d
> application data until it receives and validates the client's firs= t
> flight.=C2=A0 UNLESS the server is certain that the data it sends does= not
> depend on the client's identity (that is, it would send this
> application data to anyone).
>
>> From an API perspective, I believe that we should recommend that t= here
> be a separate function for sending in condition 2, just as we are
> going to recommend that there is a separate function for sending 0-RTT=
> data (as well as there being one to receive on the server end).
>
> Based on this, we should recommend different points in time for the > server API to report that the handshake is "complete" at a s= erver.=C2=A0 In
> condition 1, the handshake is complete after the server Finished is > sent; in condition 2, the handshake is complete after the client
> Finished is received.
>
>
> [P] Note that a client Finished does confirm a PSK.=C2=A0 Though you m= ight
> reasonably argue that successfully generating valid application data > works equally well in that regard.
> [X] Post-handshake client authentication has only been analyzed very > lightly, so we have to caveat that statement too.
>
> _______________________________________________
> 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

--001a113d9b54191f82052c76959b-- From nobody Tue Feb 23 13:39:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6C541ACEA5 for ; Tue, 23 Feb 2016 13:38:59 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YYMKva17Oag for ; Tue, 23 Feb 2016 13:38:58 -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 5F01B1A924A for ; Tue, 23 Feb 2016 13:38:58 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id 9so2952654iom.1 for ; Tue, 23 Feb 2016 13:38: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:date:message-id:subject:from:to :cc:content-type; bh=dwNuSFKN+QvG7nzfLbFEYQbHB//wYB22iyiQdhy8otU=; b=Tiijve+gUD13HywGpaUB3aC/xVIYzf5tioUWRcaxdOW4ztzeFaGU8yhOVprysyFDMI h9aJVPCb50h7EF8YWsy7+7Pb9YogMFgRDWRq04KN6IgEYDhnY3Jdm9I0kP+LlnT1r/WF 4rI8CwMiAHAHrKLBzx9Mu7dp/lCmXqCVnPKy/ctQVmyvJEdCT+8H+cRt4JZclFs3FqW1 8oU87TJDOH9rtXflntxQ825Ftz5wQR6lm7zBiS2eeEGvfa9McTcKU0iSgSkIeUkFbWvj dWbbed8x3T74LhV2lhiENSxpOHfQYZ43dKTy5YbR0saB/Vf/9+TlCQMgMi5N/NJ6jQPm Zq4Q== 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:date :message-id:subject:from:to:cc:content-type; bh=dwNuSFKN+QvG7nzfLbFEYQbHB//wYB22iyiQdhy8otU=; b=dlEVaQbnIVFvIqJf9u5xDCFn02ztswin41vYR0k92pVC2SnTjp0d7fDgIfD+U6kYfd 62g/KH/mGbUkDcT5WqnckgPYoPoGINmDQpLXqGe1DqKIN++ANS32DKjO7zXeR7eqf4dx He9oS1E3SMZ7OkvIDteJMPJECiUNrKBZE+gYZ0YPfU/ZkUaleJHEx8cHvNXD7tNPYDmj iH78/cs8Xi/nhcu38PkcNP727hBzI2fWeGd/wm5mzm+mNwlYVfjeQYv9BfLMSaW9esPi DiONvED6Ot3un6ffNTYEVj9OWTwQSPV90HN7GB14iGmciw7Gq2dlM8j93wazOiVRKXo/ T5AQ== X-Gm-Message-State: AG10YOQfkIexvD9Q+SaxXZ8hj1ehUZBcnbepyLdNDvlgxgBAV0P9NZpehDwNK57/zZtmhDswr+B8HFmp+y/iDA== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr33068135ioi.108.1456263537749; Tue, 23 Feb 2016 13:38:57 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 13:38:57 -0800 (PST) In-Reply-To: References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> Date: Tue, 23 Feb 2016 13:38:57 -0800 Message-ID: From: Martin Thomson To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 21:38:59 -0000 On 23 February 2016 at 13:24, Hugo Krawczyk wrote: > As for downgrades, this will be discovered by the server when receiving the > client's Finished message. Won't a downgrade be detected by the client when it fails to decrypt the server's data? If the server was given a false impression about the client's capabilities, then that can only happen if it receives a different ClientHello to the one the client sent. From nobody Tue Feb 23 13:58:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864141B313F for ; Tue, 23 Feb 2016 13:58:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 BBFrvwQtd_rN for ; Tue, 23 Feb 2016 13:58:33 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com [IPv6:2607:f8b0:400e:c03::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 E58341B2FF5 for ; Tue, 23 Feb 2016 13:58:32 -0800 (PST) Received: by mail-pa0-x22f.google.com with SMTP id fy10so116873942pac.1 for ; Tue, 23 Feb 2016 13:58:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=xaKsVLhg8qNOUVg6+mE50jp8xnLIXi+3mTqsJpTd9mM=; b=T1nxb1hdpxVVrwgH5mBgUuy9/Zv6xPv5qYiCsr8cYscVnLMojqU8ml2o2LE8JATNET Q0oli41AUf3v+AUWMZJ12W8SP+VD/BX9a7Ff2mlbDTP0yYj26vMQFirzOIC6LjMigyig IZO8AzmSR1sOCwU5a9mxSwLUNPYBYLeI757BmQR/kpD/e9SFD5PTHokIVOpDnVm0rrxl 8qwusN1i88C0/evmpmKH63VwvBvS400jIPtnd+dVOocqFl1GYc4j7m2L4SDL/5BZIMDk E+wQRjjgDtwNPQ9KpUC4AyPe3mInXL3QpEsA3AmTzUu0O0wgMXVixvpBXdsCwEbCZyDz Tdhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=xaKsVLhg8qNOUVg6+mE50jp8xnLIXi+3mTqsJpTd9mM=; b=dCaZ5o6BzLZ+soYtjKVG67nORND9AW6q6rNtItcBUBHAQao37mTwovAXvrPk2+Agm7 nNnjisdbHXnzodTm+s3EihQOzyje9Qb46QQyjyTktvuCIStYP2pipU+BopdUILn1s6ST 0Sm/r0xnKolVHBSsWLgnOoDtwkSdT/SFcNERZmeLgMGJqyw4CNilxXEy15MAs5RIH72A xt9m5VGtwgniCLQnZncXQ4Odzw7Hs2saxj9vSsooXjoaDpuL3rLptiOPelzNYsVwZRYw O0r8fngT2Wv3BmyezBn4EUsxHgoBTKHfxX/3Y4LI7xCnEttgiZ95AXfFqImhFPkCZXB1 0Vzw== X-Gm-Message-State: AG10YORKU0jfinZ9ZCvAoki9VyoZjX3ZwpNYYHDna/gDGH/mttdlwEG6QUwLppdxHC9esg== X-Received: by 10.66.124.201 with SMTP id mk9mr36471099pab.152.1456264712540; Tue, 23 Feb 2016 13:58:32 -0800 (PST) Received: from [172.25.3.130] (rrcs-67-52-140-5.west.biz.rr.com. [67.52.140.5]) by smtp.gmail.com with ESMTPSA id 87sm46252233pfq.93.2016.02.23.13.58.31 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 13:58:31 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_45209FF7-7151-40EF-8842-A83D6BDA30B6" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Tue, 23 Feb 2016 13:58:30 -0800 Message-Id: <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> To: Hugo Krawczyk X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 21:58:35 -0000 --Apple-Mail=_45209FF7-7151-40EF-8842-A83D6BDA30B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > =E2=80=8BThat's right, we do not consider downgrades or client = authentication but Martin's suggestion explicitly only applies to the = case=E2=80=8B where the server does not require client authentication so = the analysis holds in that case. As for downgrades, this will be = discovered by the server when receiving the client's Finished message. = So the only problem I see is that the server might have been "tricked" = to send the 0.5-RTT data with less protection than intended by the = (honest) client. But for that there is no need for downgrade. The = attacker could have generated the exchange with the weaker ciphersuite = by himself (acting as a client). If the server accepts that ciphersuite = it means he is willing to send that particular data with that level of = security to *anyone*. That is the meaning of not requiring client = authentication.=20 Yes Hugo, you=E2=80=99re right that when there is no client auth, the = situation is less problematic.=20 However, let=E2=80=99s note there may still be implicit kind of = authentication, for example, what if the client hello requests PSK-based = 1-RTT with a old-broken cipher that the real client would never use. The server should not, in this case, send user-specific data under the = old-broken cipher until it receives the client finished. Of course, this could be worked around by having a nice whitelist of = ciphers, or possibly other designs. I am mainly pointing out that we need to be careful that the guarantees = for 0.5-RTT seem to be strictly weaker than that for 1-RTT. > =E2=80=8BOne useful feature of client's finished is to catch 0-RTT = replays. But even then I am not sure what damage can be done to the 0.5 = data. Either the attacker knows the client's keying material (say PSK) = and can generate the client finished by himself or he doesn't know that = keying material but then it cannot decrypt 0.5 data. Right, this is the other concern. Suppose a passive adversary records a = clients 0-RTT data (under a PSK that is bound to an authenticated = client). He can then go home and replay this 0-RTT request as many times as he = wants and record the server=E2=80=99s 0.5-RTT responses.=20 They will be encrypted, sure, but maybe even the length of those = responses may give the attacker useful dynamic information (e.g. he can = tell whether the user=E2=80=99s bank balance went up or down by a = digit).=20 Yes, this attack is always possible for a persistent passive adversary, = and we can mitigate it with length-hiding techniques, but it gives us an = example of how 0.5-RTT may provide new avenues for attacking encrypted = connections. Best, Karthik >=20 > Am I missing something on these particular points? >=20 >=20 >=20 > On the whole, cryptographers including the authors of OPTLS = would be happier with 0.5-RTT keys > not being the same as 1-RTT keys. Again, so far, this is a = matter of taste and proof modularity. > =20 >=20 > =E2=80=8BAgreed. >=20 > Hugo > =20 > =E2=80=8B >=20 >=20 > > On 23 Feb 2016, at 11:27, Martin Thomson > wrote: > > > > Karthik raised some concerns here, and I think that we have some > > thinking to do. But I don't think that it is intractable, nor even > > hard, to reason about this problem. > > > > The only thing that the client's second flight provides is > > authentication. The Finished isn't needed if there is no client = auth > > [P]. Hugo's presentation at TRON did not include a client Finished = in > > the earlier, simpler examples. > > > > Thus, based on Watson's observation that the client authentication = is > > removable, we might conclude that the handshake is complete from the > > perspective of a server that does not require client authentication. > > There are still reasons we might like to keep the client > > authentication in the handshake, but those are decisions we can make > > on engineering grounds. > > > > If post-handshake client authentication is OK, then 0.5 RTT is = equally > > OK [X]. I would assert that any decision about changing keys after > > the client Finished applies to post-handshake client auth (or vice > > versa). > > > > If that logic is sound, then I see no reason we can't have some very > > simple advice: > > > > 1. if the server does not request client authentication, it can = send > > application data immediately following its Finished > > > > 2. if the server requests client authentication, it MUST NOT send > > application data until it receives and validates the client's first > > flight. UNLESS the server is certain that the data it sends does = not > > depend on the client's identity (that is, it would send this > > application data to anyone). > > > >> =46rom an API perspective, I believe that we should recommend that = there > > be a separate function for sending in condition 2, just as we are > > going to recommend that there is a separate function for sending = 0-RTT > > data (as well as there being one to receive on the server end). > > > > Based on this, we should recommend different points in time for the > > server API to report that the handshake is "complete" at a server. = In > > condition 1, the handshake is complete after the server Finished is > > sent; in condition 2, the handshake is complete after the client > > Finished is received. > > > > > > [P] Note that a client Finished does confirm a PSK. Though you = might > > reasonably argue that successfully generating valid application data > > works equally well in that regard. > > [X] Post-handshake client authentication has only been analyzed very > > lightly, so we have to caveat that statement too. > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls = >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_45209FF7-7151-40EF-8842-A83D6BDA30B6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
=E2=80=8BTha= t's right, we do not consider downgrades or client authentication but = Martin's suggestion explicitly only applies to the case=E2=80=8B where = the server does not require client authentication so the analysis holds = in that case. As for downgrades, this will be discovered by the server = when receiving the client's Finished message. So the only problem I see = is that the server might have been "tricked" to send the 0.5-RTT data = with less protection than intended by the (honest) client. But for that = there is no need for downgrade. The attacker could have generated the = exchange with the weaker ciphersuite by himself (acting as a client). If = the server accepts that ciphersuite it means he is willing to send that = particular data with that level of security to *anyone*. That is the = meaning of not requiring client = authentication. 

Yes Hugo, you=E2=80=99re right that when there is = no client auth, the situation is less problematic. 

However, let=E2=80=99s note there may still be = implicit kind of authentication, for example, what if the client hello = requests PSK-based 1-RTT with a old-broken cipher that the real client = would never use.
The server should not, in this case, send = user-specific data under the old-broken cipher until it receives the = client finished.
Of course, this could be worked around by = having a nice whitelist of ciphers, or possibly other = designs.
I am mainly pointing out that we need to be careful = that the guarantees for 0.5-RTT seem to be strictly weaker than that for = 1-RTT.


=E2=80=8BOne= useful feature of client's finished is to catch 0-RTT replays. But even = then I am not sure what damage can be done to the 0.5 data. Either the = attacker knows the client's keying material (say PSK) and can generate = the client finished by himself or he doesn't know that keying material = but then it cannot decrypt 0.5 = data.

Right, = this is the other concern. Suppose a passive adversary records a clients = 0-RTT data (under a PSK that is bound to an authenticated = client).
He can then go home and replay this 0-RTT request as = many times as he wants and record the server=E2=80=99s 0.5-RTT = responses. 
They will be encrypted, sure, but maybe even = the length of those responses may give the attacker useful dynamic = information (e.g. he can tell whether the user=E2=80=99s bank balance = went up or down by a digit). 

Yes, this attack is always possible for a = persistent passive adversary, and we can mitigate it with length-hiding = techniques, but it gives us an example of how 0.5-RTT may provide new = avenues for attacking encrypted connections.

Best,
Karthik



Am I = missing something on these particular points?



      =  On the whole, cryptographers including the authors of OPTLS would = be happier with 0.5-RTT keys
      =  not being the same as 1-RTT keys. Again, so far, this is a matter = of taste and proof modularity.
 

=E2=80=8BAgreed.

Hugo
 
=E2=80=8B


> On 23 Feb 2016, at 11:27, Martin = Thomson <martin.thomson@gmail.com> wrote:
>
> Karthik raised some concerns here, and I think that we = have some
> thinking to do.  But I don't think = that it is intractable, nor even
> hard, to reason = about this problem.
>
> The only thing = that the client's second flight provides is
> = authentication.  The Finished isn't needed if there is no client = auth
> [P].  Hugo's presentation at TRON did not = include a client Finished in
> the earlier, simpler = examples.
>
> Thus, based on Watson's = observation that the client authentication is
> = removable, we might conclude that the handshake is complete from the
> perspective of a server that does not require client = authentication.
> There are still reasons we might like = to keep the client
> authentication in the handshake, = but those are decisions we can make
> on engineering = grounds.
>
> If post-handshake client = authentication is OK, then 0.5 RTT is equally
> OK = [X].  I would assert that any decision about changing keys after
> the client Finished applies to post-handshake client = auth (or vice
> versa).
>
> If that logic is sound, then I see no reason we can't = have some very
> simple advice:
>
>  1. if the server does not request client = authentication, it can send
> application data = immediately following its Finished
>
>  2. if the server requests client authentication, = it MUST NOT send
> application data until it receives = and validates the client's first
> flight.  UNLESS = the server is certain that the data it sends does not
> = depend on the client's identity (that is, it would send this
> application data to anyone).
>
>> =46rom an API perspective, I believe that we should = recommend that there
> be a separate function for = sending in condition 2, just as we are
> going to = recommend that there is a separate function for sending 0-RTT
> data (as well as there being one to receive on the = server end).
>
> Based on this, we = should recommend different points in time for the
> = server API to report that the handshake is "complete" at a server.  = In
> condition 1, the handshake is complete after the = server Finished is
> sent; in condition 2, the = handshake is complete after the client
> Finished is = received.
>
>
> [P] = Note that a client Finished does confirm a PSK.  Though you = might
> reasonably argue that successfully generating = valid application data
> works equally well in that = regard.
> [X] Post-handshake client authentication has = only been analyzed very
> lightly, so we have to caveat = that statement too.
>
> = _______________________________________________
> 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

= --Apple-Mail=_45209FF7-7151-40EF-8842-A83D6BDA30B6-- From nobody Tue Feb 23 14:01:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB91A8927 for ; Tue, 23 Feb 2016 14:01:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjhENNk4-MsS for ; Tue, 23 Feb 2016 14:01:30 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 E94431A6F3A for ; Tue, 23 Feb 2016 14:01:29 -0800 (PST) Received: by mail-pa0-x22a.google.com with SMTP id yy13so116995365pab.3 for ; Tue, 23 Feb 2016 14:01:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rj4kWeH5QKeBKaBeCxtsyk6Yg4t7JZFEPyCBB5S3sVg=; b=lsGMtPuJASDarqU1lFLam5LrRZDIDCyOLbFuzIUdhuz0EFQGhWYrM8dMxQtdDKmor6 d5pI6Oy0nXUKNvZlyW3HVFnEYVWllNnd5yIQLGQzvdVYX59mKVKH5tD9fo+LkgSeeJzS aBjo/E53fof2CyPLeTIckYZnHRoEefoABr316tauedDSamLmuMscXuEVeMEt9jRlwbN+ 4DPLJd1b+qKNgvj2NdDVZV/BScgSdRKHtVtfrLvW4IILlbPXXOW5yFlVIWpB6CVrIMLL e6yZUzDpjNGcOz1OyYWtZ7IWHGWGOiiHIgLtEEgt4iuApos9Dw4sLu1+1ePg8hnOYBLG cKlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=rj4kWeH5QKeBKaBeCxtsyk6Yg4t7JZFEPyCBB5S3sVg=; b=AKBlU/EbHC7mmuhwPrEodW8QDdtYMWC5y2iutbxfshCWXHol4P6A58aS98ylhQmaug OeGwxH1P7WDTOdztDXZRFuZ97xMQpCt4ZVIgDttG9UcUaF2RuDAa7kxMUr5q3H9ERPju 5Lbg502+Omb4GsqAU7bRXv3GLpr/5wJ2QOif9RGGtmFa2gg8r38eCgmibPQEKQ7g0X+V 78ArDPzgp49NXF+5NLLNLIcDlcumxIto1BpTRlcFsQLoAf/4Gu3nLYvW82kFNjuxhaCQ Eok1pDLE0r916lSa+Gm79QBjgoihXYEdfjSsUzoQxpWIyXRodDTcxpRxNih9u1W7l1vA QAIQ== X-Gm-Message-State: AG10YOSAaJHp/f42FoTe8vOqb8DrRtTYn50P4/dpmCBnTkLK9YJuTaKO2WgCpSIxCEOKxw== X-Received: by 10.67.6.10 with SMTP id cq10mr49675613pad.120.1456264889666; Tue, 23 Feb 2016 14:01:29 -0800 (PST) Received: from [172.25.3.130] (rrcs-67-52-140-5.west.biz.rr.com. [67.52.140.5]) by smtp.gmail.com with ESMTPSA id fk10sm3628394pab.33.2016.02.23.14.01.28 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 14:01:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Tue, 23 Feb 2016 14:01:28 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> To: Martin Thomson X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:01:31 -0000 > Won't a downgrade be detected by the client when it fails to decrypt > the server's data?=20 The main downgrade concern, I think, is for the 0.5-RTT data=E2=80=99s = confidentiality; i.e. it may have been sent encrypted under a broken = cipher. You=E2=80=99re right that the client will not accept this data because = the handshake hashes (mixed into the key) would not match. From nobody Tue Feb 23 14:08:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDDF81A885D for ; Tue, 23 Feb 2016 14:08:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yR4IK_Yq1HFO for ; Tue, 23 Feb 2016 14:08:22 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 4DAEA1B3472 for ; Tue, 23 Feb 2016 14:08:22 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id g203so3945270iof.2 for ; Tue, 23 Feb 2016 14:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=66ydGXZPxd/ImX+ka+tvveFdD5O20CdW7fYFLN+WKBg=; b=Fr/F4o/pWL4Ki4afvuUe/konxTxtQy98FaaEY7SlP5I375VviDoIWIlmF/LANm76tt 7AV98JFfPojIQwpxc0r5T3MzLwZnzNK5B74uWDJ3AHAPg2OJilA59OUzVLirxANlAvVb /0D+LNCz2QEiTARxIKt6LQR8JkfLj8o+nsvLfrLB26Doc5eAGkGIU08cHafAZrIcUhp8 r9eSoiaCiW5LhyvuyvqyRfV+PEaMLZKT1xow1e/ra9Cdz3sDiWDpbqfn7ReWT6zkG2Qm DtYSRewrjXlYxAnpmYHiSuS0nPy/pN2iI++9UXQNcJdJbdF2X/WwddlOZZ0+EQfnvzg7 7yLA== 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:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=66ydGXZPxd/ImX+ka+tvveFdD5O20CdW7fYFLN+WKBg=; b=hFoGDoAEEoNC9uYhEq7sSZ/Q5d3Xv3fCYUYBmN86ln018UHlfiPk/0cYhXHNeUTTW/ kv/s5HKuXjEsZRQv5larN7e9VO7jQKCIXQENOg+998zW54ISA2HIxr1TdcRv9t9o6tlm DK5Es6clesGA5RsEFEYp63J2NbxlSmi3djggRl5xXQYr1vH53rMl8MfGS9T3Q2rBJ1aK 3qZCIml5OcOKkwWmeJPiHsdLCZ6FwsECE+y25X60DLPTfMcm4QtKO0668XDKY9dWJ/fV A2sONqfMU9XHJzR284uz1X62c2xAwXl5Xttg5as48Yo3SdgnBUAtXB+I405eNhrvX1QC mTOw== X-Gm-Message-State: AG10YORbIiXoyWOTm1b209iXFiVU7YUxjniSw+yYphzKhHAa77gCjTm0t8Aa7liWx5c6M68IP1e+KNwOzLZ66w== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr38256017iod.190.1456265301715; Tue, 23 Feb 2016 14:08:21 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 14:08:21 -0800 (PST) In-Reply-To: <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> Date: Tue, 23 Feb 2016 14:08:21 -0800 Message-ID: From: Martin Thomson To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:08:23 -0000 On 23 February 2016 at 14:01, Karthikeyan Bhargavan wrote: > The main downgrade concern, I think, is for the 0.5-RTT data=E2=80=99s co= nfidentiality; i.e. it may have been sent encrypted under a broken cipher. Hmm, that's a good point. So Antoine's analogy is closer to correct than I had thought, and the need for Finished remains. There's an argument that says that 0.5RTT data isn't confidential because the server would send it to anyone, but I don't agree with that viewpoint. And we're potentially also handling 0-RTT data before sending 0.5 data. Like I said on the weekend, we don't have to solve every problem. None of the cipher suites in TLS 1.3 would fail to qualify as broken currently, but if they did, then logic similar to what we recommend for false start seems reasonable to me. Other than that, we can simply document the shortcoming. I don't think that any of this justifies a stronger response than that, and that includes extra key updates. From nobody Tue Feb 23 14:26:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B76F11A8749 for ; Tue, 23 Feb 2016 14:26:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 HifCvnT_E-zL for ; Tue, 23 Feb 2016 14:26:49 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB6231B2E8F for ; Tue, 23 Feb 2016 14:26:48 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id 78so128145lfy.3 for ; Tue, 23 Feb 2016 14:26:48 -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:content-type; bh=AedsG0ugumyPdKO4YvF9hzN6vymeee8THOwP4AFHRwE=; b=RuC9U10EiZmlbshyf9axkxFxZ4SQ5YRE8JjcDDEz42DTPj3wpiTYSPK7uHZnILdMuK 5efhqN5/kns03ubdMbNwdXX5FyBb+K+mCHwmKs0KuznLvMg6O9duuT5IzmNF5HLxc+Fw eVJokbpu9qBYWua+SyhCEYw2N4u5HOIq+jioSzrCXulpQ/EqZZ2D+pAw5aNx+EFyA0sG 7gXBiwB25LKlwp6dF4HK0Yxf8ME1zyNGWROOO28VjcPU6kvR91Tlp7PM8bsYBvMz5onn 0KTMojy8HP2W/Z0jd3PSfihLlPkXkTx/FrlIjgt5ahwWg9gSzzUnObDYylaN831SM+In FV3A== 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:content-type; bh=AedsG0ugumyPdKO4YvF9hzN6vymeee8THOwP4AFHRwE=; b=MXCR0wEKy4omR8bNf9HthPVcpRq4t70/wBCZHF1SX8ZS6Lx4u1RxC0P/Q3TQVyeNIh G8XFsfSn4EE8IA24MDyKkC70ZnQZss/+A6bdZHYjoq1r0Vejr/T6kxv52MJ1JD1RQeNt rADOAEctEhkIQZlNt3vWppWGt0RQ364e/9bdTlszqhCtiWivXEBAM5GCzcI3HbfTsRsZ ekZphrJeddX9/LPN2HWAVTE8s/dTZngva6MrpUZ2Unvdqlugk7jgomoFfNSjfy/WpIR7 tf9GgA8tOQOjem1pS40zvO8hOzZir33T2XKwk15BAgTycJjb1dDnONMbGZXxfbTZpZDh cbnA== X-Gm-Message-State: AG10YOS4yQZm6cImq+Tcua6v6ny1MlrlPT65D3HH/yd7p2YWdAcgfbojIMSYMfPXt3tgqezOPIS8o+iHX5+b3Q== X-Received: by 10.25.21.90 with SMTP id l87mr13063883lfi.64.1456266406845; Tue, 23 Feb 2016 14:26:46 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Tue, 23 Feb 2016 14:26:17 -0800 (PST) In-Reply-To: <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> From: Hugo Krawczyk Date: Tue, 23 Feb 2016 17:26:17 -0500 X-Google-Sender-Auth: geo58GgPwDcKeymBb2JmG1S6O_k Message-ID: To: Karthikeyan Bhargavan Content-Type: multipart/alternative; boundary=001a113d9b54e0e27d052c77715a Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:26:52 -0000 --001a113d9b54e0e27d052c77715a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Karthik, I think that what you are pointing to are cases where the client *is* authenticated via its PSK. There is an important distinction between PSKs that have been authenticated by the client (in a previous exchange) and those that are not. Any PSK-based handshake that uses a (previously) client-authenticated PSK needs to be treated as client-authenticated and replay needs to be dealt with utmost care, including the need to validate via the client finished that the current exchange is not a replay. In the case where the PSK is client-unauthenticated (e.g. a resumption from a server-only authenticated handshake) and the server does not request client authentication then the need for client finished is less crucial. Let me be clear, I prefer a conservative design to a more liberal one so if we can do without 0.5 data then much better. Hugo On Tue, Feb 23, 2016 at 4:58 PM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > =E2=80=8BThat's right, we do not consider downgrades or client authentica= tion but > Martin's suggestion explicitly only applies to the case=E2=80=8B where th= e server > does not require client authentication so the analysis holds in that case= . > As for downgrades, this will be discovered by the server when receiving t= he > client's Finished message. So the only problem I see is that the server > might have been "tricked" to send the 0.5-RTT data with less protection > than intended by the (honest) client. But for that there is no need for > downgrade. The attacker could have generated the exchange with the weaker > ciphersuite by himself (acting as a client). If the server accepts that > ciphersuite it means he is willing to send that particular data with that > level of security to *anyone*. That is the meaning of not requiring clien= t > authentication. > > > Yes Hugo, you=E2=80=99re right that when there is no client auth, the sit= uation is > less problematic. > > However, let=E2=80=99s note there may still be implicit kind of authentic= ation, > for example, what if the client hello requests PSK-based 1-RTT with a > old-broken cipher that the real client would never use. > The server should not, in this case, send user-specific data under the > old-broken cipher until it receives the client finished. > Of course, this could be worked around by having a nice whitelist of > ciphers, or possibly other designs. > I am mainly pointing out that we need to be careful that the guarantees > for 0.5-RTT seem to be strictly weaker than that for 1-RTT. > > > =E2=80=8BOne useful feature of client's finished is to catch 0-RTT replay= s. But > even then I am not sure what damage can be done to the 0.5 data. Either t= he > attacker knows the client's keying material (say PSK) and can generate th= e > client finished by himself or he doesn't know that keying material but th= en > it cannot decrypt 0.5 data. > > > Right, this is the other concern. Suppose a passive adversary records a > clients 0-RTT data (under a PSK that is bound to an authenticated client)= . > He can then go home and replay this 0-RTT request as many times as he > wants and record the server=E2=80=99s 0.5-RTT responses. > They will be encrypted, sure, but maybe even the length of those response= s > may give the attacker useful dynamic information (e.g. he can tell whethe= r > the user=E2=80=99s bank balance went up or down by a digit). > > Yes, this attack is always possible for a persistent passive adversary, > and we can mitigate it with length-hiding techniques, but it gives us an > example of how 0.5-RTT may provide new avenues for attacking encrypted > connections. > > Best, > Karthik > > > > Am I missing something on these particular points? > > > > On the whole, cryptographers including the authors of OPTLS would >> be happier with 0.5-RTT keys >> not being the same as 1-RTT keys. Again, so far, this is a matter >> of taste and proof modularity. >> > > > =E2=80=8BAgreed. > > Hugo > > =E2=80=8B > > >> > On 23 Feb 2016, at 11:27, Martin Thomson >> wrote: >> > >> > Karthik raised some concerns here, and I think that we have some >> > thinking to do. But I don't think that it is intractable, nor even >> > hard, to reason about this problem. >> > >> > The only thing that the client's second flight provides is >> > authentication. The Finished isn't needed if there is no client auth >> > [P]. Hugo's presentation at TRON did not include a client Finished in >> > the earlier, simpler examples. >> > >> > Thus, based on Watson's observation that the client authentication is >> > removable, we might conclude that the handshake is complete from the >> > perspective of a server that does not require client authentication. >> > There are still reasons we might like to keep the client >> > authentication in the handshake, but those are decisions we can make >> > on engineering grounds. >> > >> > If post-handshake client authentication is OK, then 0.5 RTT is equally >> > OK [X]. I would assert that any decision about changing keys after >> > the client Finished applies to post-handshake client auth (or vice >> > versa). >> > >> > If that logic is sound, then I see no reason we can't have some very >> > simple advice: >> > >> > 1. if the server does not request client authentication, it can send >> > application data immediately following its Finished >> > >> > 2. if the server requests client authentication, it MUST NOT send >> > application data until it receives and validates the client's first >> > flight. UNLESS the server is certain that the data it sends does not >> > depend on the client's identity (that is, it would send this >> > application data to anyone). >> > >> >> From an API perspective, I believe that we should recommend that ther= e >> > be a separate function for sending in condition 2, just as we are >> > going to recommend that there is a separate function for sending 0-RTT >> > data (as well as there being one to receive on the server end). >> > >> > Based on this, we should recommend different points in time for the >> > server API to report that the handshake is "complete" at a server. In >> > condition 1, the handshake is complete after the server Finished is >> > sent; in condition 2, the handshake is complete after the client >> > Finished is received. >> > >> > >> > [P] Note that a client Finished does confirm a PSK. Though you might >> > reasonably argue that successfully generating valid application data >> > works equally well in that regard. >> > [X] Post-handshake client authentication has only been analyzed very >> > lightly, so we have to caveat that statement too. >> > >> > _______________________________________________ >> > 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 >> > > --001a113d9b54e0e27d052c77715a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Karthik, I think that what you are pointing to = are cases where the client *is* authenticated via its PSK.

There is an important distinction between PSKs that h= ave been authenticated by the client (in a previous exchange) and those tha= t are not.
Any PSK-based handshake that uses a (previously)= client-authenticated PSK needs to be treated as client-authenticated and r= eplay needs to be dealt with utmost care, including the need to validate vi= a the client finished that the current exchange is not a replay. In the cas= e where the PSK is client-unauthenticated (e.g. a resumption from a server-= only authenticated handshake) and the server does not request client authen= tication then the need for client finished is less crucial.

Let me be clear, I prefer a conservative design to a = more liberal one so if we can do without 0.5 data then much better.=C2=A0

Hugo




On Tue, Feb 23, 2016 at 4:58 PM, Karthikeyan Bhargav= an <karthik.bhargavan@gmail.com> wrote:
=E2=80=8BThat's right, we d= o not consider downgrades or client authentication but Martin's suggest= ion explicitly only applies to the case=E2=80=8B where the server does not = require client authentication so the analysis holds in that case. As for do= wngrades, this will be discovered by the server when receiving the client&#= 39;s Finished message. So the only problem I see is that the server might h= ave been "tricked" to send the 0.5-RTT data with less protection = than intended by the (honest) client. But for that there is no need for dow= ngrade. The attacker could have generated the exchange with the weaker ciph= ersuite by himself (acting as a client). If the server accepts that ciphers= uite it means he is willing to send that particular data with that level of= security to *anyone*. That is the meaning of not requiring client authenti= cation.=C2=A0

Yes = Hugo, you=E2=80=99re right that when there is no client auth, the situation= is less problematic.=C2=A0

However, let=E2=80=99s= note there may still be implicit kind of authentication, for example, what= if the client hello requests PSK-based 1-RTT with a old-broken cipher that= the real client would never use.
The server should not, in this = case, send user-specific data under the old-broken cipher until it receives= the client finished.
Of course, this could be worked around by h= aving a nice whitelist of ciphers, or possibly other designs.
I a= m mainly pointing out that we need to be careful that the guarantees for 0.= 5-RTT seem to be strictly weaker than that for 1-RTT.


=E2=80= =8BOne useful feature of client's finished is to catch 0-RTT replays. B= ut even then I am not sure what damage can be done to the 0.5 data. Either = the attacker knows the client's keying material (say PSK) and can gener= ate the client finished by himself or he doesn't know that keying mater= ial but then it cannot decrypt 0.5 data.

Right, this is the other concern. Suppose a passive = adversary records a clients 0-RTT data (under a PSK that is bound to an aut= henticated client).
He can then go home and replay this 0-RTT req= uest as many times as he wants and record the server=E2=80=99s 0.5-RTT resp= onses.=C2=A0
They will be encrypted, sure, but maybe even the len= gth of those responses may give the attacker useful dynamic information (e.= g. he can tell whether the user=E2=80=99s bank balance went up or down by a= digit).=C2=A0

Yes, this attack is always possible= for a persistent passive adversary, and we can mitigate it with length-hid= ing techniques, but it gives us an example of how 0.5-RTT may provide new a= venues for attacking encrypted connections.

Best,<= /div>
Karthik



Am I missing something on t= hese particular points?



=C2=A0 =C2=A0 =C2=A0 =C2=A0On the whole,= cryptographers including the authors of OPTLS would be happier with 0.5-RT= T keys
=C2=A0 =C2=A0 =C2=A0 =C2=A0not being the same as 1-RTT keys. Agai= n, so far, this is a matter of taste and proof modularity.
=
=C2= =A0

=E2=80=8BAgreed.

Hugo
=C2=A0
=E2=80=8B


> On 23 Feb 2016, at 11:27, Martin Thomson <martin.thomson@gmail.com>= wrote:
>
> Karthik raised some concerns here, and I think that= we have some
> thinking to do.=C2=A0 But I don't think that it i= s intractable, nor even
> hard, to reason about this problem.
>=
> The only thing that the client's second flight provides is
= > authentication.=C2=A0 The Finished isn't needed if there is no cli= ent auth
> [P].=C2=A0 Hugo's presentation at TRON did not include= a client Finished in
> the earlier, simpler examples.
>
>= ; Thus, based on Watson's observation that the client authentication is=
> removable, we might conclude that the handshake is complete from t= he
> perspective of a server that does not require client authenticat= ion.
> There are still reasons we might like to keep the client
&g= t; authentication in the handshake, but those are decisions we can make
= > on engineering grounds.
>
> If post-handshake client authe= ntication is OK, then 0.5 RTT is equally
> OK [X].=C2=A0 I would asse= rt that any decision about changing keys after
> the client Finished = applies to post-handshake client auth (or vice
> versa).
>
&= gt; If that logic is sound, then I see no reason we can't have some ver= y
> simple advice:
>
>=C2=A0 1. if the server does not re= quest client authentication, it can send
> application data immediate= ly following its Finished
>
>=C2=A0 2. if the server requests c= lient authentication, it MUST NOT send
> application data until it re= ceives and validates the client's first
> flight.=C2=A0 UNLESS th= e server is certain that the data it sends does not
> depend on the c= lient's identity (that is, it would send this
> application data = to anyone).
>
>> From an API perspective, I believe that we = should recommend that there
> be a separate function for sending in c= ondition 2, just as we are
> going to recommend that there is a separ= ate function for sending 0-RTT
> data (as well as there being one to = receive on the server end).
>
> Based on this, we should recomm= end different points in time for the
> server API to report that the = handshake is "complete" at a server.=C2=A0 In
> condition 1= , the handshake is complete after the server Finished is
> sent; in c= ondition 2, the handshake is complete after the client
> Finished is = received.
>
>
> [P] Note that a client Finished does conf= irm a PSK.=C2=A0 Though you might
> reasonably argue that successfull= y generating valid application data
> works equally well in that rega= rd.
> [X] Post-handshake client authentication has only been analyzed= very
> lightly, so we have to caveat that statement too.
>
= > _______________________________________________
> TLS mailing li= st
>=C2=A0TLS@ietf.org
>=C2=A0https://www.= ietf.org/mailman/listinfo/tls

__________________________________= _____________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailma= n/listinfo/tls
<= /div>

--001a113d9b54e0e27d052c77715a-- From nobody Tue Feb 23 14:32:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0A421A03A0 for ; Tue, 23 Feb 2016 14:32:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1c2mmUtkFW9G for ; Tue, 23 Feb 2016 14:32:18 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7E061A0193 for ; Tue, 23 Feb 2016 14:32:18 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id u9so226075ykd.1 for ; Tue, 23 Feb 2016 14:32:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kHtzFc6SSPniGiKa56iJv0YSqUoxwZ4DYuPtjC7TXUI=; b=AeoeqxogZo/Zz8eqSPcLu4uvpz0j3yhUPdel39dz37rmMZiLsxpW6aCLPLNINfk4nI 3Q9/NTSgs+nX44w+0QjkLqNIpEgHGdGQPUaMUspVYowYHP7nabSOUl1IDXc3OdFrPUy4 OZt0FQ4VnzQvzXo+lCr1ddMJMDRJaUy/WyxDlAl1Zxz+HYSS1I5Z70ViZv6mfuw02w0B x5vcEgp29fZcR1FHxyvMdEsFkDfX51g1XQDURm1zr/XaKvHvNZR5FXrCJ8tfBAoEz305 5Lp1v2mPrzDKEVbemFRpto5MOrZZqP2FfZnQoGvqnQY11w9ZFPkXkSkqR9HRZx2wvzQg cgFw== 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:date :message-id:subject:from:to:cc:content-type; bh=kHtzFc6SSPniGiKa56iJv0YSqUoxwZ4DYuPtjC7TXUI=; b=cp/ZFkRKA1NB7x159rwVxFpA7GV9TaCRIYj8XdW/M04VyAsJY9jcyKEZCtWIEIr0YA bU3iIJvrx45YLkXW6laxat72PwZPuxarL4ClohXQUCIAfGUYxVE9YoNQeIu6bGvP31jH pcJQvxjn7v3AMThpiKkfnbCep7Q5OuhO/i1WDlqnEhWGcvevV/xLMcyPzrNKzn3ZcwFY i2aRTK73C/yNRZxuohZy0UHzIHOkuS1Ag/KRK9nelwA3XtF/Q09etWUiabHZKscXlf4C ya/L2lBRQh2aX0YigDrrvNgQA1BWndcu86KpL/JzSqB7cg5U6rRmv1cSxtyameEXZydk 1++g== X-Gm-Message-State: AG10YOT1g0+VaejjCPhhjhyad/y5zZ8NxQ2zktOrHS0HUdK9rbnHvYGMRv8nkTwPw80rotH0jIa8rwDSW/tyIw== MIME-Version: 1.0 X-Received: by 10.37.78.5 with SMTP id c5mr18492246ybb.53.1456266737832; Tue, 23 Feb 2016 14:32:17 -0800 (PST) Received: by 10.13.216.138 with HTTP; Tue, 23 Feb 2016 14:32:17 -0800 (PST) Received: by 10.13.216.138 with HTTP; Tue, 23 Feb 2016 14:32:17 -0800 (PST) In-Reply-To: References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> Date: Tue, 23 Feb 2016 14:32:17 -0800 Message-ID: From: Watson Ladd To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=001a113fd6fe9b59e5052c77852f Archived-At: Cc: Karthikeyan Bhargavan , tls@ietf.org Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:32:22 -0000 --001a113fd6fe9b59e5052c77852f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Feb 23, 2016 2:27 PM, "Hugo Krawczyk" wrote: > > Karthik, I think that what you are pointing to are cases where the client *is* authenticated via its PSK. > > There is an important distinction between PSKs that have been authenticated by the client (in a previous exchange) and those that are not= . > Any PSK-based handshake that uses a (previously) client-authenticated PSK needs to be treated as client-authenticated and replay needs to be dealt with utmost care, including the need to validate via the client finished that the current exchange is not a replay. In the case where the PSK is client-unauthenticated (e.g. a resumption from a server-only authenticated handshake) and the server does not request client authentication then the need for client finished is less crucial. Authentication is also handled at a higher layer through HTTP cookies or token binding. We need to ensure our analysis covers these interactions. > > Let me be clear, I prefer a conservative design to a more liberal one so if we can do without 0.5 data then much better. I think we should seperate a conservative TLS 1.3 core consisting only of those features we are absolutely certain function together well, with RSA endpoint cert signatures banned, and no 0-RTT, and encourage implementors to make it easy to restrict to this subset. >From TRON my impressesion is that this includes 1-RTT exchanges and so is already a latency gain over existing TLS. > > Hugo > > > > > On Tue, Feb 23, 2016 at 4:58 PM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: >>> >>> =E2=80=8BThat's right, we do not consider downgrades or client authenti= cation but Martin's suggestion explicitly only applies to the case=E2=80=8B where = the server does not require client authentication so the analysis holds in that case. As for downgrades, this will be discovered by the server when receiving the client's Finished message. So the only problem I see is that the server might have been "tricked" to send the 0.5-RTT data with less protection than intended by the (honest) client. But for that there is no need for downgrade. The attacker could have generated the exchange with the weaker ciphersuite by himself (acting as a client). If the server accepts that ciphersuite it means he is willing to send that particular data with that level of security to *anyone*. That is the meaning of not requiring client authentication. >> >> >> Yes Hugo, you=E2=80=99re right that when there is no client auth, the si= tuation is less problematic. >> >> However, let=E2=80=99s note there may still be implicit kind of authenti= cation, for example, what if the client hello requests PSK-based 1-RTT with a old-broken cipher that the real client would never use. >> The server should not, in this case, send user-specific data under the old-broken cipher until it receives the client finished. >> Of course, this could be worked around by having a nice whitelist of ciphers, or possibly other designs. >> I am mainly pointing out that we need to be careful that the guarantees for 0.5-RTT seem to be strictly weaker than that for 1-RTT. >> >> >>> =E2=80=8BOne useful feature of client's finished is to catch 0-RTT repl= ays. But even then I am not sure what damage can be done to the 0.5 data. Either the attacker knows the client's keying material (say PSK) and can generate the client finished by himself or he doesn't know that keying material but then it cannot decrypt 0.5 data. >> >> >> Right, this is the other concern. Suppose a passive adversary records a clients 0-RTT data (under a PSK that is bound to an authenticated client). >> He can then go home and replay this 0-RTT request as many times as he wants and record the server=E2=80=99s 0.5-RTT responses. >> They will be encrypted, sure, but maybe even the length of those responses may give the attacker useful dynamic information (e.g. he can tell whether the user=E2=80=99s bank balance went up or down by a digit). >> >> Yes, this attack is always possible for a persistent passive adversary, and we can mitigate it with length-hiding techniques, but it gives us an example of how 0.5-RTT may provide new avenues for attacking encrypted connections. >> >> Best, >> Karthik >> >> >>> >>> Am I missing something on these particular points? >>> >>> >>> >>>> On the whole, cryptographers including the authors of OPTLS would be happier with 0.5-RTT keys >>>> not being the same as 1-RTT keys. Again, so far, this is a matter of taste and proof modularity. >>> >>> >>> >>> =E2=80=8BAgreed. >>> >>> Hugo >>> >>> =E2=80=8B >>> >>>> >>>> > On 23 Feb 2016, at 11:27, Martin Thomson wrote: >>>> > >>>> > Karthik raised some concerns here, and I think that we have some >>>> > thinking to do. But I don't think that it is intractable, nor even >>>> > hard, to reason about this problem. >>>> > >>>> > The only thing that the client's second flight provides is >>>> > authentication. The Finished isn't needed if there is no client aut= h >>>> > [P]. Hugo's presentation at TRON did not include a client Finished in >>>> > the earlier, simpler examples. >>>> > >>>> > Thus, based on Watson's observation that the client authentication i= s >>>> > removable, we might conclude that the handshake is complete from the >>>> > perspective of a server that does not require client authentication. >>>> > There are still reasons we might like to keep the client >>>> > authentication in the handshake, but those are decisions we can make >>>> > on engineering grounds. >>>> > >>>> > If post-handshake client authentication is OK, then 0.5 RTT is equally >>>> > OK [X]. I would assert that any decision about changing keys after >>>> > the client Finished applies to post-handshake client auth (or vice >>>> > versa). >>>> > >>>> > If that logic is sound, then I see no reason we can't have some very >>>> > simple advice: >>>> > >>>> > 1. if the server does not request client authentication, it can sen= d >>>> > application data immediately following its Finished >>>> > >>>> > 2. if the server requests client authentication, it MUST NOT send >>>> > application data until it receives and validates the client's first >>>> > flight. UNLESS the server is certain that the data it sends does no= t >>>> > depend on the client's identity (that is, it would send this >>>> > application data to anyone). >>>> > >>>> >> From an API perspective, I believe that we should recommend that there >>>> > be a separate function for sending in condition 2, just as we are >>>> > going to recommend that there is a separate function for sending 0-RTT >>>> > data (as well as there being one to receive on the server end). >>>> > >>>> > Based on this, we should recommend different points in time for the >>>> > server API to report that the handshake is "complete" at a server. In >>>> > condition 1, the handshake is complete after the server Finished is >>>> > sent; in condition 2, the handshake is complete after the client >>>> > Finished is received. >>>> > >>>> > >>>> > [P] Note that a client Finished does confirm a PSK. Though you migh= t >>>> > reasonably argue that successfully generating valid application data >>>> > works equally well in that regard. >>>> > [X] Post-handshake client authentication has only been analyzed very >>>> > lightly, so we have to caveat that statement too. >>>> > >>>> > _______________________________________________ >>>> > 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 > --001a113fd6fe9b59e5052c77852f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 23, 2016 2:27 PM, "Hugo Krawczyk" <hugo@ee.technion.ac.il> wrote:
>
> Karthik, I think that what you are pointing to are cases where the cli= ent *is* authenticated via its PSK.
>
> There is an important distinction between PSKs that have been authenti= cated by the client (in a previous exchange) and those that are not.
> Any PSK-based handshake that uses a (previously) client-authenticated = PSK needs to be treated as client-authenticated and replay needs to be deal= t with utmost care, including the need to validate via the client finished = that the current exchange is not a replay. In the case where the PSK is cli= ent-unauthenticated (e.g. a resumption from a server-only authenticated han= dshake) and the server does not request client authentication then the need= for client finished is less crucial.

Authentication is also handled at a higher layer through HTT= P cookies or token binding. We need to ensure our analysis covers these int= eractions.

>
> Let me be clear, I prefer a conservative design to a more liberal one = so if we can do without 0.5 data then much better.=C2=A0

I think we should seperate a conservative TLS 1.3 core consi= sting only of those features we are absolutely certain function together we= ll, with RSA endpoint cert signatures banned, and no 0-RTT, and encourage i= mplementors to make it easy to restrict to this subset.

From TRON my impressesion is that this includes 1-RTT exchan= ges and so is already a latency gain over existing TLS.

>
> Hugo
>
>
>
>
> On Tue, Feb 23, 2016 at 4:58 PM, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com> wro= te:
>>>
>>> =E2=80=8BThat's right, we do not consider downgrades or cl= ient authentication but Martin's suggestion explicitly only applies to = the case=E2=80=8B where the server does not require client authentication s= o the analysis holds in that case. As for downgrades, this will be discover= ed by the server when receiving the client's Finished message. So the o= nly problem I see is that the server might have been "tricked" to= send the 0.5-RTT data with less protection than intended by the (honest) c= lient. But for that there is no need for downgrade. The attacker could have= generated the exchange with the weaker ciphersuite by himself (acting as a= client). If the server accepts that ciphersuite it means he is willing to = send that particular data with that level of security to *anyone*. That is = the meaning of not requiring client authentication.=C2=A0
>>
>>
>> Yes Hugo, you=E2=80=99re right that when there is no client auth, = the situation is less problematic.=C2=A0
>>
>> However, let=E2=80=99s note there may still be implicit kind of au= thentication, for example, what if the client hello requests PSK-based 1-RT= T with a old-broken cipher that the real client would never use.
>> The server should not, in this case, send user-specific data under= the old-broken cipher until it receives the client finished.
>> Of course, this could be worked around by having a nice whitelist = of ciphers, or possibly other designs.
>> I am mainly pointing out that we need to be careful that the guara= ntees for 0.5-RTT seem to be strictly weaker than that for 1-RTT.
>>
>>
>>> =E2=80=8BOne useful feature of client's finished is to cat= ch 0-RTT replays. But even then I am not sure what damage can be done to th= e 0.5 data. Either the attacker knows the client's keying material (say= PSK) and can generate the client finished by himself or he doesn't kno= w that keying material but then it cannot decrypt 0.5 data.
>>
>>
>> Right, this is the other concern. Suppose a passive adversary reco= rds a clients 0-RTT data (under a PSK that is bound to an authenticated cli= ent).
>> He can then go home and replay this 0-RTT request as many times as= he wants and record the server=E2=80=99s 0.5-RTT responses.=C2=A0
>> They will be encrypted, sure, but maybe even the length of those r= esponses may give the attacker useful dynamic information (e.g. he can tell= whether the user=E2=80=99s bank balance went up or down by a digit).=C2=A0=
>>
>> Yes, this attack is always possible for a persistent passive adver= sary, and we can mitigate it with length-hiding techniques, but it gives us= an example of how 0.5-RTT may provide new avenues for attacking encrypted = connections.
>>
>> Best,
>> Karthik
>>
>>
>>>
>>> Am I missing something on these particular points?
>>>
>>>
>>>
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0On the whole, cryptographers in= cluding the authors of OPTLS would be happier with 0.5-RTT keys
>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0not being the same as 1-RTT key= s. Again, so far, this is a matter of taste and proof modularity.
>>>
>>> =C2=A0
>>>
>>> =E2=80=8BAgreed.
>>>
>>> Hugo
>>> =C2=A0
>>> =E2=80=8B
>>>
>>>>
>>>> > On 23 Feb 2016, at 11:27, Martin Thomson <martin.thomson@gmail.com> wrote= :
>>>> >
>>>> > Karthik raised some concerns here, and I think that w= e have some
>>>> > thinking to do.=C2=A0 But I don't think that it i= s intractable, nor even
>>>> > hard, to reason about this problem.
>>>> >
>>>> > The only thing that the client's second flight pr= ovides is
>>>> > authentication.=C2=A0 The Finished isn't needed i= f there is no client auth
>>>> > [P].=C2=A0 Hugo's presentation at TRON did not in= clude a client Finished in
>>>> > the earlier, simpler examples.
>>>> >
>>>> > Thus, based on Watson's observation that the clie= nt authentication is
>>>> > removable, we might conclude that the handshake is co= mplete from the
>>>> > perspective of a server that does not require client = authentication.
>>>> > There are still reasons we might like to keep the cli= ent
>>>> > authentication in the handshake, but those are decisi= ons we can make
>>>> > on engineering grounds.
>>>> >
>>>> > If post-handshake client authentication is OK, then 0= .5 RTT is equally
>>>> > OK [X].=C2=A0 I would assert that any decision about = changing keys after
>>>> > the client Finished applies to post-handshake client = auth (or vice
>>>> > versa).
>>>> >
>>>> > If that logic is sound, then I see no reason we can&#= 39;t have some very
>>>> > simple advice:
>>>> >
>>>> >=C2=A0 1. if the server does not request client authen= tication, it can send
>>>> > application data immediately following its Finished >>>> >
>>>> >=C2=A0 2. if the server requests client authentication= , it MUST NOT send
>>>> > application data until it receives and validates the = client's first
>>>> > flight.=C2=A0 UNLESS the server is certain that the d= ata it sends does not
>>>> > depend on the client's identity (that is, it woul= d send this
>>>> > application data to anyone).
>>>> >
>>>> >> From an API perspective, I believe that we should= recommend that there
>>>> > be a separate function for sending in condition 2, ju= st as we are
>>>> > going to recommend that there is a separate function = for sending 0-RTT
>>>> > data (as well as there being one to receive on the se= rver end).
>>>> >
>>>> > Based on this, we should recommend different points i= n time for the
>>>> > server API to report that the handshake is "comp= lete" at a server.=C2=A0 In
>>>> > condition 1, the handshake is complete after the serv= er Finished is
>>>> > sent; in condition 2, the handshake is complete after= the client
>>>> > Finished is received.
>>>> >
>>>> >
>>>> > [P] Note that a client Finished does confirm a PSK.= =C2=A0 Though you might
>>>> > reasonably argue that successfully generating valid a= pplication data
>>>> > works equally well in that regard.
>>>> > [X] Post-handshake client authentication has only bee= n analyzed very
>>>> > lightly, so we have to caveat that statement too.
>>>> >
>>>> > _______________________________________________
>>>> > TLS mailing list
>>>> >=C2=A0TLS@ietf.org=
>>>> >=C2=A0https://www.ietf.org/mailman/listinfo/tls
>>>>
>>>> _______________________________________________
>>>> TLS mailing list
>>>> TLS@ietf.org
>>>> http= s://www.ietf.org/mailman/listinfo/tls
>>
>>
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls
>

--001a113fd6fe9b59e5052c77852f-- From nobody Tue Feb 23 14:32:45 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056151B35B5 for ; Tue, 23 Feb 2016 14:32:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 bKvGi7sOXfPQ for ; Tue, 23 Feb 2016 14:32:40 -0800 (PST) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::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 44E081B35B0 for ; Tue, 23 Feb 2016 14:32:40 -0800 (PST) Received: by mail-pa0-x22a.google.com with SMTP id ho8so220951pac.2 for ; Tue, 23 Feb 2016 14:32:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ZgKNAnS+6BAhsIVzxEqr1zepF4BvqvhKBqM7OV0Cwjc=; b=e3JCv98+gpFrXcVmQM/5zlvj7esFSQMRK9xauB8sSL1F8Hi5i2hwZ4gkr79jAeAX5F 1w5aTYg1e5qCcKZ0vRCtkfG0G5it5qCjQ2K2lFkiDad4/Fjbb2CGJd+45v4B+7VR2QKW MSC62YWRhkVb8H/GSXzZKOze0W5pPeUITVmd20867HvUPUmGQ/ESrgm/rlonsgnQbh4i QIDuQNzlvReYI3UYqvtstQJW6r/vhK/HOxjwqiwFIYdcUzMfV/8OGjdLeGk1lAlsPOsy mRZGwhHjuaIM+TfVi9TjlcmAakrPJcUL1T0WYzDkXgWp5cMNBUPUWUiJ7Cw7mWj4JcXX JDTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ZgKNAnS+6BAhsIVzxEqr1zepF4BvqvhKBqM7OV0Cwjc=; b=fgwEbq8QXT/6hfXesUoPCH9HhsYMdPc40CXXuw1l8zqCUGsjHyPARbmxDswGamIhYf 3kk2KaIvZBLkgVuhI+koB2fkSU5OsOl37/zOK/NUelbyZOb+q55lg4CfzFxcTJuFHbmt EmBo+00l2suBkPbIHsKDVAdBcu8jsU5RQLpF1lEFeeXVY3S75xB9Z2a5pXU+sPm12ISt oTa47F0F0EUcR0EL/XXb5ylUWQOFjBCx2y5HS4DJWc6ZHxfrYHY/9+XEbkyZ6SgDWXp7 G7r8PMeSoY/vJyVR3tBo8Z1kDZWkb0rPIww3A9gMZ5IUaTZc3aUuOBEGp1yzQ42euSTJ 3clA== X-Gm-Message-State: AG10YOTItanKI2OZ1MMcca0e3ZbJvmON6fwPU4ab7/n+nHd9w5yKb7AT1pX11D1088DsGA== X-Received: by 10.66.222.129 with SMTP id qm1mr49225586pac.22.1456266759899; Tue, 23 Feb 2016 14:32:39 -0800 (PST) Received: from [172.25.3.130] (rrcs-67-52-140-5.west.biz.rr.com. [67.52.140.5]) by smtp.gmail.com with ESMTPSA id d8sm46642949pas.14.2016.02.23.14.32.38 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Feb 2016 14:32:39 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_399D0F24-F727-4908-89ED-3ECD4AA80142" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Tue, 23 Feb 2016 14:32:38 -0800 Message-Id: <9EE520CD-685F-4470-9638-03AE7374F09E@gmail.com> References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> To: Hugo Krawczyk X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:32:43 -0000 --Apple-Mail=_399D0F24-F727-4908-89ED-3ECD4AA80142 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Any PSK-based handshake that uses a (previously) client-authenticated = PSK needs to be treated as client-authenticated and replay needs to be = dealt with utmost care, including the need to validate via the client = finished that the current exchange is not a replay. In the case where = the PSK is client-unauthenticated (e.g. a resumption from a server-only = authenticated handshake) and the server does not request client = authentication then the need for client finished is less crucial. Hugo, I think you and I are mostly agreeing on these concerns. I will point out that there are other ways of authenticating than = certificate and PSK-based auth that are not necessarily visible to TLS. For example, the application may have used the exporter master secret in = the previous session to authenticate the user=20 Or, more simply, the replayed 0-RTT request may contain a cookie. >=20 > Let me be clear, I prefer a conservative design to a more liberal one = so if we can do without 0.5 data then much better.=20 >=20 > Hugo >=20 >=20 >=20 >=20 > On Tue, Feb 23, 2016 at 4:58 PM, Karthikeyan Bhargavan = > = wrote: >> =E2=80=8BThat's right, we do not consider downgrades or client = authentication but Martin's suggestion explicitly only applies to the = case=E2=80=8B where the server does not require client authentication so = the analysis holds in that case. As for downgrades, this will be = discovered by the server when receiving the client's Finished message. = So the only problem I see is that the server might have been "tricked" = to send the 0.5-RTT data with less protection than intended by the = (honest) client. But for that there is no need for downgrade. The = attacker could have generated the exchange with the weaker ciphersuite = by himself (acting as a client). If the server accepts that ciphersuite = it means he is willing to send that particular data with that level of = security to *anyone*. That is the meaning of not requiring client = authentication.=20 >=20 > Yes Hugo, you=E2=80=99re right that when there is no client auth, the = situation is less problematic.=20 >=20 > However, let=E2=80=99s note there may still be implicit kind of = authentication, for example, what if the client hello requests PSK-based = 1-RTT with a old-broken cipher that the real client would never use. > The server should not, in this case, send user-specific data under the = old-broken cipher until it receives the client finished. > Of course, this could be worked around by having a nice whitelist of = ciphers, or possibly other designs. > I am mainly pointing out that we need to be careful that the = guarantees for 0.5-RTT seem to be strictly weaker than that for 1-RTT. >=20 >=20 >> =E2=80=8BOne useful feature of client's finished is to catch 0-RTT = replays. But even then I am not sure what damage can be done to the 0.5 = data. Either the attacker knows the client's keying material (say PSK) = and can generate the client finished by himself or he doesn't know that = keying material but then it cannot decrypt 0.5 data. >=20 > Right, this is the other concern. Suppose a passive adversary records = a clients 0-RTT data (under a PSK that is bound to an authenticated = client). > He can then go home and replay this 0-RTT request as many times as he = wants and record the server=E2=80=99s 0.5-RTT responses.=20 > They will be encrypted, sure, but maybe even the length of those = responses may give the attacker useful dynamic information (e.g. he can = tell whether the user=E2=80=99s bank balance went up or down by a = digit).=20 >=20 > Yes, this attack is always possible for a persistent passive = adversary, and we can mitigate it with length-hiding techniques, but it = gives us an example of how 0.5-RTT may provide new avenues for attacking = encrypted connections. >=20 > Best, > Karthik >=20 >=20 >>=20 >> Am I missing something on these particular points? >>=20 >>=20 >>=20 >> On the whole, cryptographers including the authors of OPTLS = would be happier with 0.5-RTT keys >> not being the same as 1-RTT keys. Again, so far, this is a = matter of taste and proof modularity. >> =20 >>=20 >> =E2=80=8BAgreed. >>=20 >> Hugo >> =20 >> =E2=80=8B >>=20 >>=20 >> > On 23 Feb 2016, at 11:27, Martin Thomson > wrote: >> > >> > Karthik raised some concerns here, and I think that we have some >> > thinking to do. But I don't think that it is intractable, nor even >> > hard, to reason about this problem. >> > >> > The only thing that the client's second flight provides is >> > authentication. The Finished isn't needed if there is no client = auth >> > [P]. Hugo's presentation at TRON did not include a client Finished = in >> > the earlier, simpler examples. >> > >> > Thus, based on Watson's observation that the client authentication = is >> > removable, we might conclude that the handshake is complete from = the >> > perspective of a server that does not require client = authentication. >> > There are still reasons we might like to keep the client >> > authentication in the handshake, but those are decisions we can = make >> > on engineering grounds. >> > >> > If post-handshake client authentication is OK, then 0.5 RTT is = equally >> > OK [X]. I would assert that any decision about changing keys after >> > the client Finished applies to post-handshake client auth (or vice >> > versa). >> > >> > If that logic is sound, then I see no reason we can't have some = very >> > simple advice: >> > >> > 1. if the server does not request client authentication, it can = send >> > application data immediately following its Finished >> > >> > 2. if the server requests client authentication, it MUST NOT send >> > application data until it receives and validates the client's first >> > flight. UNLESS the server is certain that the data it sends does = not >> > depend on the client's identity (that is, it would send this >> > application data to anyone). >> > >> >> =46rom an API perspective, I believe that we should recommend that = there >> > be a separate function for sending in condition 2, just as we are >> > going to recommend that there is a separate function for sending = 0-RTT >> > data (as well as there being one to receive on the server end). >> > >> > Based on this, we should recommend different points in time for the >> > server API to report that the handshake is "complete" at a server. = In >> > condition 1, the handshake is complete after the server Finished is >> > sent; in condition 2, the handshake is complete after the client >> > Finished is received. >> > >> > >> > [P] Note that a client Finished does confirm a PSK. Though you = might >> > reasonably argue that successfully generating valid application = data >> > works equally well in that regard. >> > [X] Post-handshake client authentication has only been analyzed = very >> > lightly, so we have to caveat that statement too. >> > >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls = >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls = >=20 --Apple-Mail=_399D0F24-F727-4908-89ED-3ECD4AA80142 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Any PSK-based handshake that uses a = (previously) client-authenticated PSK needs to be treated as = client-authenticated and replay needs to be dealt with utmost care, = including the need to validate via the client finished that the current = exchange is not a replay. In the case where the PSK is = client-unauthenticated (e.g. a resumption from a server-only = authenticated handshake) and the server does not request client = authentication then the need for client finished is less = crucial.

Hugo, I think you and I are mostly agreeing on these = concerns.
I will point out that there are other = ways of authenticating than certificate and PSK-based auth that are not = necessarily visible to TLS.
For example, the = application may have used the exporter master secret in the previous = session to authenticate the user 
Or, more = simply, the replayed 0-RTT request may contain a cookie.


Let me be = clear, I prefer a conservative design to a more liberal one so if we can = do without 0.5 data then much better. 

Hugo




On Tue, Feb 23, 2016 at 4:58 PM, Karthikeyan = Bhargavan <karthik.bhargavan@gmail.com> wrote:
=E2=80=8BThat's = right, we do not consider downgrades or client authentication but = Martin's suggestion explicitly only applies to the case=E2=80=8B where = the server does not require client authentication so the analysis holds = in that case. As for downgrades, this will be discovered by the server = when receiving the client's Finished message. So the only problem I see = is that the server might have been "tricked" to send the 0.5-RTT data = with less protection than intended by the (honest) client. But for that = there is no need for downgrade. The attacker could have generated the = exchange with the weaker ciphersuite by himself (acting as a client). If = the server accepts that ciphersuite it means he is willing to send that = particular data with that level of security to *anyone*. That is the = meaning of not requiring client = authentication. 

Yes Hugo, you=E2=80=99re right = that when there is no client auth, the situation is less = problematic. 

However, let=E2=80=99s note there may still be implicit kind = of authentication, for example, what if the client hello requests = PSK-based 1-RTT with a old-broken cipher that the real client would = never use.
The server should not, in this case, = send user-specific data under the old-broken cipher until it receives = the client finished.
Of course, this could be = worked around by having a nice whitelist of ciphers, or possibly other = designs.
I am mainly pointing out that we need to = be careful that the guarantees for 0.5-RTT seem to be strictly weaker = than that for 1-RTT.


=E2=80=8BOne = useful feature of client's finished is to catch 0-RTT replays. But even = then I am not sure what damage can be done to the 0.5 data. Either the = attacker knows the client's keying material (say PSK) and can generate = the client finished by himself or he doesn't know that keying material = but then it cannot decrypt 0.5 data.

Right, this is = the other concern. Suppose a passive adversary records a clients 0-RTT = data (under a PSK that is bound to an authenticated client).
He can then go home and replay this 0-RTT request as many = times as he wants and record the server=E2=80=99s 0.5-RTT = responses. 
They will be encrypted, sure, but = maybe even the length of those responses may give the attacker useful = dynamic information (e.g. he can tell whether the user=E2=80=99s bank = balance went up or down by a digit). 

Yes, this attack is always possible for = a persistent passive adversary, and we can mitigate it with = length-hiding techniques, but it gives us an example of how 0.5-RTT may = provide new avenues for attacking encrypted connections.

Best,
Karthik



Am I missing = something on these particular points?

       On the whole, = cryptographers including the authors of OPTLS would be happier with = 0.5-RTT keys
       not being the same = as 1-RTT keys. Again, so far, this is a matter of taste and proof = modularity.
 

=E2=80=8BAgreed.<= /div>

Hugo
 
=E2=80=8B

> On 23 Feb 2016, at 11:27, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> Karthik raised some concerns here, and I think that we = have some
> thinking to do.  But I don't think = that it is intractable, nor even
> hard, to reason = about this problem.
>
> The only thing = that the client's second flight provides is
> = authentication.  The Finished isn't needed if there is no client = auth
> [P].  Hugo's presentation at TRON did not = include a client Finished in
> the earlier, simpler = examples.
>
> Thus, based on Watson's = observation that the client authentication is
> = removable, we might conclude that the handshake is complete from the
> perspective of a server that does not require client = authentication.
> There are still reasons we might like = to keep the client
> authentication in the handshake, = but those are decisions we can make
> on engineering = grounds.
>
> If post-handshake client = authentication is OK, then 0.5 RTT is equally
> OK = [X].  I would assert that any decision about changing keys after
> the client Finished applies to post-handshake client = auth (or vice
> versa).
>
> If that logic is sound, then I see no reason we can't = have some very
> simple advice:
>
>  1. if the server does not request client = authentication, it can send
> application data = immediately following its Finished
>
>  2. if the server requests client authentication, = it MUST NOT send
> application data until it receives = and validates the client's first
> flight.  UNLESS = the server is certain that the data it sends does not
> = depend on the client's identity (that is, it would send this
> application data to anyone).
>
>> =46rom an API perspective, I believe that we should = recommend that there
> be a separate function for = sending in condition 2, just as we are
> going to = recommend that there is a separate function for sending 0-RTT
> data (as well as there being one to receive on the = server end).
>
> Based on this, we = should recommend different points in time for the
> = server API to report that the handshake is "complete" at a server.  = In
> condition 1, the handshake is complete after the = server Finished is
> sent; in condition 2, the = handshake is complete after the client
> Finished is = received.
>
>
> [P] = Note that a client Finished does confirm a PSK.  Though you = might
> reasonably argue that successfully generating = valid application data
> works equally well in that = regard.
> [X] Post-handshake client authentication has = only been analyzed very
> lightly, so we have to caveat = that statement too.
>
> = _______________________________________________
> 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



= --Apple-Mail=_399D0F24-F727-4908-89ED-3ECD4AA80142-- From nobody Tue Feb 23 14:33:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6E6D1B35DD for ; Tue, 23 Feb 2016 14:33:02 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XypBSGCwMxEu for ; Tue, 23 Feb 2016 14:33: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 976831B35C8 for ; Tue, 23 Feb 2016 14:33:00 -0800 (PST) Received: by mail-io0-x233.google.com with SMTP id z135so5280380iof.0 for ; Tue, 23 Feb 2016 14:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fWtjEChAVZuETeAsplfnYIo95yXoHX8n+KR0uqW4Rp8=; b=WVQ2Trk5+ySZCgaB+tzcFOdEcx3jIF7wIoTI/nhD5gDBaJIKgcnozzJrV4BLc2I7v+ DAMPiWdZuFOafLDTxO06DwPBNL3y4BNOiRWM9YvllNmQb5VyTQWCeGCt1Fga+WuNBMLh C78VVeNoHCvfnFSrQx1rglqit2rN3FzhkR8y95QEXt/tBFuX8Tx9HgXIfUNyftZmHZFP qFHFDTkTyw1gCTMOwpjpNmcBKgb40nFZ5HVnIOEPS0vjyMQkpL3cgakmS5j21zTfaOEF k4LmrUVTEG2laMrfquKZZOTV8aH5MU2vhriweRv2ELfVabDh6ctVQrVNqvBtUr8BryhE dgOg== 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:date :message-id:subject:from:to:cc:content-type; bh=fWtjEChAVZuETeAsplfnYIo95yXoHX8n+KR0uqW4Rp8=; b=OMC9uDpmm26fjnYtJn/iBVRCF9TbpQJSjBlh2XCRm6P9ajijo5oY//V260mKwTncBA V5wf14s0v27EavGwhqSVyXkJB6mJGUJDI6CXKtFptT6PeoWSpEixUItWUrv0OjianW/3 rtLtiRp0M2D+FVMkH63NJHqNvG+jw4RwP31lBypyLSjUNhZRquxKVQv6FxwS94+5Nyg6 AntraIc0xozfNtC/WrdC8yJIszKP7R9GiTVUiOBBFccOmSX7F+HjSJkl046OJzgJSSec Tm159Shn+UaRBWz6v9PZ0+T+FC0Wo6iIP3SrpIBF2MG2EZ51mzL0bidrwhNYL4Pis1dU jEKg== X-Gm-Message-State: AG10YOQSvVvud72QWI1MLsS1S2ZOM/YXwmQ6o796lh0crRyv3qbUXJuRCKwHXr4fA2Jk1niEQNcCjEvSx/HZ8Q== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr38342101iod.190.1456266780093; Tue, 23 Feb 2016 14:33:00 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 14:33:00 -0800 (PST) In-Reply-To: References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> Date: Tue, 23 Feb 2016 14:33:00 -0800 Message-ID: From: Martin Thomson To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:33:02 -0000 On 23 February 2016 at 14:26, Hugo Krawczyk wrote: > Karthik, I think that what you are pointing to are cases where the client > *is* authenticated via its PSK. In the downgrade scenario, that doesn't seem right, but maybe it's just that the client's ClientHello is being authenticated. From nobody Tue Feb 23 14:38:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFA371B2BD6 for ; Tue, 23 Feb 2016 14:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 dM52gTcMWtzW for ; Tue, 23 Feb 2016 14:38:17 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED7311B2AA5 for ; Tue, 23 Feb 2016 14:38:16 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id 78so280638lfy.3 for ; Tue, 23 Feb 2016 14:38:16 -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:content-type; bh=mBOTAbQFNuvbLOcTVJYNK0+GgmBPOsU0NM6JpToFJQk=; b=IgYD08J/8uizZ2RI27WZ9+YgrdZBUq1Cp13M17Hch+96XpcHCpthqyvTJErtewHab3 1BVh6Bfi7/+lHTKjA+zny/EdtGzem7cisOmuVCXBNd40HgCNjwy7LcEWVKL+SEEFZYYP CjioHfRx5xt8k2eDmvlSH4BQBbJUM5Bgb+qtu0UXE415CN0SKNPfNEnddetlhuF4lGLF xNwVGrZ3w/qz8y21VkghXC9S96CDMTmblkAVX6u7xQRZJj3HXnll9ynWEkXAOWUWlwY8 E+pBtMbFcjSnZJCJ4fX11ELOEyu3+T7kqyFQeol64wsAIa+my7XnvhbWgdZk2ZigkSqX vGcg== 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:content-type; bh=mBOTAbQFNuvbLOcTVJYNK0+GgmBPOsU0NM6JpToFJQk=; b=mRZKJlE55CUVpeuzGqXpMuof73W1wj2cI6no3yL69aw16WKGj3by/6LYjJwTth/m22 F4pmfQnU5fI+dxLLjVciSlBPHuxLXfldxXjj5/Zg+TsIAGO14o3aJvF1IPnJHtvmQ6Jq wdzdtQUyU5GrZ8j01LpkjoJkokqzNXMMYIouM1egjlPRMMkAQmkAZ02ieQuO1beq8PoV Vug3qPXK2g7lUp/qcA4m2YHy7wx+jlwG42sPSvLNiCAyjpeCQl+/Eu7ZnXw6yzeJixl9 fXcnOq1mCXJZR4+lIqv+1ga/sggI+k6BPVYdr2M0HbVJ2WGplwq3S9S7bGfuUbo7Uy5d EihQ== X-Gm-Message-State: AG10YOSgUFlHSmkKRCYPIdBD0xkC22zu7cS1PemAyeWqFVUFmVpnjnZSRPgRI2hSZlVsRH8y122beNVrmYc1IQ== X-Received: by 10.25.147.212 with SMTP id v203mr10882113lfd.167.1456267095192; Tue, 23 Feb 2016 14:38:15 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Tue, 23 Feb 2016 14:37:45 -0800 (PST) In-Reply-To: References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> From: Hugo Krawczyk Date: Tue, 23 Feb 2016 17:37:45 -0500 X-Google-Sender-Auth: qBkTWiE7eMPhn9SlLSwPhkt8z1U Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11402438e838be052c779a12 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:38:19 -0000 --001a11402438e838be052c779a12 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 23, 2016 at 5:08 PM, Martin Thomson wrote: > On 23 February 2016 at 14:01, Karthikeyan Bhargavan > wrote: > > The main downgrade concern, I think, is for the 0.5-RTT data=E2=80=99s > confidentiality; i.e. it may have been sent encrypted under a broken ciph= er. > > Hmm, that's a good point. So Antoine's analogy is closer to correct > than I had thought, and the need for Finished remains. > > There's an argument that says that 0.5RTT data isn't confidential > because the server would send it to anyone, but I don't agree with > that viewpoint. =E2=80=8BI would be interested to hear why you don't agree with that viewpo= int. It seems to imply that you are attaching some "client-specific semantics" even to keys that were not authenticated by the client. Understanding such semantics would be a good guide for when 0.5 data may be safe. =E2=80=8BBut the truth is that whatever these semantics are, under your abo= ve viewpoint you should never send 0.5 data.=E2=80=8B =E2=80=8BMatching vague semantics to cryptographic security is too hard a p= roblem to get it right. (In particular, if these semantics may be based on stuff that happens outside TLS, as Karthik and Watson were pointing out, then maybe we really put a "Surgeon General" warning on 0.5 data of equal size to that of 0-RTT.= ) Hugo=E2=80=8B And we're potentially also handling 0-RTT data before > sending 0.5 data. > > Like I said on the weekend, we don't have to solve every problem. > None of the cipher suites in TLS 1.3 would fail to qualify as broken > currently, but if they did, then logic similar to what we recommend > for false start seems reasonable to me. Other than that, we can > simply document the shortcoming. I don't think that any of this > justifies a stronger response than that, and that includes extra key > updates. > --001a11402438e838be052c779a12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 23, 2016 at 5:08 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 23 February 2016 at 14:01, Karthikeyan Bhargavan
<karthik= .bhargavan@gmail.com> wrote:
> The main downgrade concern, I think, is for the 0.5-RTT data=E2=80=99s= confidentiality; i.e. it may have been sent encrypted under a broken ciphe= r.

Hmm, that's a good point.=C2=A0 So Antoine's analogy is clos= er to correct
than I had thought, and the need for Finished remains.

There's an argument that says that 0.5RTT data isn't confidential because the server would send it to anyone, but I don't agree with
that viewpoint.=C2=A0

=E2=80=8BI would be interested to hear why you don't agree with t= hat viewpoint.
It seems to imply = that you are attaching some "client-specific semantics" even to k= eys that were not authenticated by the client.
Understanding such semantics would be a good guide for when= 0.5 data may be safe.

=E2=80=8BB= ut the truth is that whatever these semantics are, under your above viewpoi= nt you should never send 0.5 data.=E2=80=8B
=E2=80=8BMatchi= ng vague semantics to cryptographic security is too hard a problem to get i= t right.

(In particular, if these sema= ntics may be based on stuff that happens outside TLS, as Karthik and Watson= were pointing out, then maybe we really put a "Surgeon General" = warning on 0.5 data of equal size to that of 0-RTT.)

Hugo=E2=80=8B

=

And we're potentially also handling 0-RTT data befor= e
sending 0.5 data.

Like I said on the weekend, we don't have to solve every problem.
None of the cipher suites in TLS 1.3 would fail to qualify as broken
currently, but if they did, then logic similar to what we recommend
for false start seems reasonable to me.=C2=A0 Other than that, we can
simply document the shortcoming.=C2=A0 I don't think that any of this justifies a stronger response than that, and that includes extra key
updates.

--001a11402438e838be052c779a12-- From nobody Tue Feb 23 14:52:05 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C240B1A90AE for ; Tue, 23 Feb 2016 14:52:02 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_ImUcENcEkZ for ; Tue, 23 Feb 2016 14:52: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 2AFD11A909B for ; Tue, 23 Feb 2016 14:52:01 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id g203so6039266iof.2 for ; Tue, 23 Feb 2016 14:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=NbP8U+8OJU4yJ4hmPZFQSfrv4w2md42Mq0BcwuRQvBw=; b=Mw8MIgJGvOnCWNDZE59/xBncnHWT7dgDlZer9vomylJ0WENjM/dnRB/y0zvNvYZwKD C35AnPmlUAJBz28qtmvYQJyzdxEYsQLsL308D9Tx+xXCd+SlXsiK59Ev5mjymWblkHja 61dLub5pTWb8oKzwffANj7YwT7xO/MwJRjz+fzhAKs06079wKXeT16es2iQNqWbmVfk5 q/NnFQa46EuHi2wAn65aDcP9L4f727kSRFt+kP2NcN3bi4VtuC4lrSsltrBEknXZSJZg iRCKpWxMuUKvXs6cJJtH3uBdO9XSWTpY5GiLrWXGUFzRn6MmmYO/Yn2Joq9Z6OqVDNZr BUVA== 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:date :message-id:subject:from:to:cc:content-type; bh=NbP8U+8OJU4yJ4hmPZFQSfrv4w2md42Mq0BcwuRQvBw=; b=jOFN41BDyv/L1CCtOP463rlp7eLWR1sfYF5tidF+VqoR4Jb13uIEAvCbu8ny57Bdku FzHwXF3Co/2Q/EezaCI5lyIqqZldFM6DgI4nMmkrCCwa20ti48iKv+MShyCof/ujDaMp ZwbVaxncPMeVI9zG7kp47TeGuz8nw1PCMbgrfBstJHoqkDuVck3WWOOpxKXvGfI9EXVM sBwmt9EjLdM/CN9a3YoFxogPjhTYCLUabY960ZvSxgr6aI+mTLBgw+ECzY5eicd6K02z 9ZOpXmcT+R3M+xhg6VQ12n3MXIfAcCAKW/s4SYD5N8cgLT3lkMtuNI+81JQIv3Vv3Oea Uq5A== X-Gm-Message-State: AG10YOSZTKhFeSPP3c1XQn3CTwPFNlxXiFSxQvYfU9JvNJ8GTzxxKcWhq56zp11QC216hdJMaKOhbKCqtJaAIA== MIME-Version: 1.0 X-Received: by 10.107.34.139 with SMTP id i133mr33268123ioi.108.1456267920513; Tue, 23 Feb 2016 14:52:00 -0800 (PST) Received: by 10.36.53.79 with HTTP; Tue, 23 Feb 2016 14:52:00 -0800 (PST) In-Reply-To: References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> Date: Tue, 23 Feb 2016 14:52:00 -0800 Message-ID: From: Martin Thomson To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 22:52:02 -0000 On 23 February 2016 at 14:37, Hugo Krawczyk wrote: > It seems to imply that you are attaching some "client-specific semantics" > even to keys that were not authenticated by the client. It's primarily a privacy concern, though it's a pretty weak concern. From nobody Tue Feb 23 15:30:00 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9992B1B37E6 for ; Tue, 23 Feb 2016 15:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 wZBeeQdZ9rul for ; Tue, 23 Feb 2016 15:29:50 -0800 (PST) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) by ietfa.amsl.com (Postfix) with SMTP id 913FA1B37DE for ; Tue, 23 Feb 2016 15:29:50 -0800 (PST) Received: (qmail 15439 invoked by uid 0); 23 Feb 2016 23:29:48 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy4.mail.unifiedlayer.com with SMTP; 23 Feb 2016 23:29:48 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id MzVj1s00u2UhLwi01zVmAp; Tue, 23 Feb 2016 16:29:46 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=OQYI39TyycwA:10 a=jFJIQSaiL_oA:10 a=1ibwJlUuAAAA:8 a=FgQHihVCw9C9XhrnBHMA:9 a=QEXdDO2ut3YA:10 a=Mh7-_8fRqUoA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:To; bh=qOxLYMwcNQxJ3VSHnOlC5Yv6ukdlQeW4Fq80WHoooRU=; b=H/vYHQiUc2pOCOqxwO0/spTSry+S9k6S+rlBKWIOVMYbsppHp6Ug29sJ+2/bm8muayPAvq1IptiqNCaDdY5ScsfrZSALb+hXR9y6pzrv+2ZUniEetNOtJEak3S4N5Q3b; Received: from [70.197.23.113] (port=3545 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aYMOn-0000BZ-3K for tls@ietf.org; Tue, 23 Feb 2016 16:29:45 -0700 To: IETF TLS WG From: =JeffH Message-ID: <56CCEB63.1060104@KingsMountain.com> Date: Tue, 23 Feb 2016 15:29:39 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.23.113 authed with jeff.hodges+kingsmountain.com} Archived-At: Subject: [TLS] TRON notes? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Feb 2016 23:29:51 -0000 is anyone writing up some notes from TRON to share here on the list? especially wrt the "What do we know and where are we going?" topic :) inquiring minds and all... thx =JeffH From nobody Tue Feb 23 16:31:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 646D41B2AFC for ; Tue, 23 Feb 2016 16:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.001 X-Spam-Level: X-Spam-Status: No, score=-102.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12IXURf08Zrw for ; Tue, 23 Feb 2016 16:31:20 -0800 (PST) Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) by ietfa.amsl.com (Postfix) with SMTP id CB3591A9153 for ; Tue, 23 Feb 2016 16:31:20 -0800 (PST) Received: (qmail 26009 invoked by uid 0); 24 Feb 2016 00:31:17 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy7.mail.unifiedlayer.com with SMTP; 24 Feb 2016 00:31:17 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id N7X81s00C2UhLwi017XBWk; Wed, 24 Feb 2016 00:31:14 -0700 X-Authority-Analysis: v=2.1 cv=GOWbTI9K c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=OQYI39TyycwA:10 a=jFJIQSaiL_oA:10 a=48vgC7mUAAAA:8 a=XLRtkrvRo2ALSmYrNkAA:9 a=z9DPM9gKmv5KJI_5:21 a=eAz1EyFha3V2Wtvh:21 a=QEXdDO2ut3YA:10 a=hPK1F0iGenQA:10 a=z_eTP1fv5zAA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=ZquM8xZU6OgbVgPy84WBbi7+oSVqbyIhCFyRjWKu+d8=; b=OtNo5RgG6nAZKbhvdoap1keBANpZZ7G4rHiBD6Y2BQlgu2n/cs2E1xKMztyZH2mdxFUyNecLiMVhBu1YH54YpBTEcpOLqEOkrqT+cIc+zPsr2nYnw+kXCrkaqX2F6HmR; Received: from [70.197.23.113] (port=2706 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aYNME-00007z-PC; Tue, 23 Feb 2016 17:31:10 -0700 To: Ilari Liusvaara From: =JeffH Message-ID: <56CCF9C8.1060905@KingsMountain.com> Date: Tue, 23 Feb 2016 16:31:04 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.197.23.113 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 00:31:22 -0000 Hi Ilari, Ilari replied on Wed, 17 Feb 2016: > On Wed, Feb 17, 2016 at 11:25:12AM -0800, =JeffH wrote: >> Hi, >> >> RFC5705 section 4 "Exporter Definition" [1] states.. >> >> The exporter takes three input values: >> >> o a disambiguating label string, >> >> o a per-association context value provided by the application using >> the exporter, and >> >> o a length value. >> >> If no context is provided, it then computes: >> >> PRF(... >> )[length] >> >> If context is provided, it computes: >> >> PRF(... >> )[length] >> >> >> ..i.e., RFC5705 directly utilizes the TLS PRF (pseudo-random function) >> from TLS {1.0, 1.1, 1.3}. Since the PRF() is no longer defined in TLS >> 1.3, RFC5705 is incompatible with TLS 1.3, yes? [...the above question remains unanswered...] >> >> Also, draft-ietf-tls-tls13-11 seems to contain a built-in keying material >> exporter (KME) in S 7.1 step 8 [2].. >> >> 7.1. Key Schedule >> >> [...] >> >> 8. exporter_secret = HKDF-Expand-Label(master_secret, >> "exporter master secret", >> handshake_hash, L) >> [...] >> >> >> ..i.e., does the above step "8." effectively define the TLS 1.3 keying >> material exporter? >> > > Well, it isn't clear to me what TLS 1.3 exporters should do. Presumably > the "master secret" used for calculations is exporter_secret. agreed -- that is what is being referred to in various msgs on the list as "EMS" (exporter master secret?) ? > However, just replacing the PRF in definition with the standard TLS 1.3 > PRF (HKDF) would leave those exporters using randoms, which aren't > explicitly used anywhere in TLS 1.3. hm, I'm not sure I understand. back on 8-Oct you mused on the below [1].. One idea for TLS-unique for TLS 1.3: Invoke TLS-EXPORTER with: label: "TLS 1.3 tls-unqiue" context: No context Length: 256 And define TLS-EXPORTER for TLS 1.3 as (this looks ugly, have some better way at handling both context and no context cases? In original RFC, those were different): tmp = HKDF-Extract(label, exporter_secret) output = HKDF-Expand(tmp, 0x01 | context, L) or (no context case) tmp = HKDF-Extract(label, exporter_secret) output = HKDF-Expand(tmp, , L) ..where "output" would apparently be the Exported Keying Material value, which seems plausible (modulo refining the Label). So I'm not sure where/what you meant by "using randoms" above... exporter_secret is not a "random", yes? =JeffH [1] https://www.ietf.org/mail-archive/web/tls/current/msg17924.html From nobody Tue Feb 23 17:49:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8D41AD062 for ; Tue, 23 Feb 2016 17:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fisRd3_JCW7D for ; Tue, 23 Feb 2016 17:49:21 -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 AC86C1ACC85 for ; Tue, 23 Feb 2016 17:49:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6EE14BE56; Wed, 24 Feb 2016 01:49:20 +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 T5W7fTSzYV4I; Wed, 24 Feb 2016 01:49:19 +0000 (GMT) Received: from [10.1.1.75] (unknown [216.9.109.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F3A49BE50; Wed, 24 Feb 2016 01:49:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1456278559; bh=4FW5WC7XfZK8/qlpxt1pNzYa0VN0zIL6fXiOe/xenMc=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=df6TlbulmAJ6L3gFTCw/dZfv0fYbL81FpsGI6oAl7UCc80mbEHO9IvwuVcUmEVNCO hbHIP10F1GyzbTYDSmzB4EO2bstosxIYTOgTznH+BmaTq2zM78qEp2wsnuP9r3BE0V XIJkVhaaLJ20Prh7S68M0skDmlRaZc70lJBntU9M= To: Hugo Krawczyk , Martin Thomson References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56CD0C1C.9010501@cs.tcd.ie> Date: Wed, 24 Feb 2016 01:49:16 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030503000405000609090204" Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 01:49:23 -0000 This is a cryptographically signed message in MIME format. --------------ms030503000405000609090204 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/02/16 22:37, Hugo Krawczyk wrote: >=20 > (In particular, if these semantics may be based on stuff that happens > outside TLS, as Karthik and Watson were pointing out, then maybe we rea= lly > put a "Surgeon General" warning on 0.5 data of equal size to that of 0-= RTT.) That, and/or also do a significant amount of work to consider other application uses of TLS that aren't well represented by folks who participate in the development of TLS1.3. And also oddities like EAP-TLS about which I at least am mostly ignorant but where I'd bet there's "fun" to be had with 0rtt. And we have to do that recognising that regardless of what the RFC says, if developers can improve performance by calling tls_send0() and not tls_send(), they will do the former. IOW, if we are going to define dangerous implements, (e.g., with replayable data) then I think the onus is mostly on us to know what bad effects those might have before we've done a good job. (We can try do that at IETF LC, but doing so isn't common and is often messy if we end up surprising folks.) Cheers, S. --------------ms030503000405000609090204 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMjQw MTQ5MTZaMC8GCSqGSIb3DQEJBDEiBCAtC2RMl/FyHR+/mlx0Dr0zzbWekHeWmgy1DHqDjSoY YzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBG8NIbv69AYcEmgcD5v5Ff1DMLppczzpnHHbr8Tb+y6XyOBpDQBUvR cIZIpr6gTCitS2c3joNYT7HU/ATIzp2M7SrfSlqiG/3Malyx3BP8yBwVIYJq7QXMj8IIDmgz nCgbSJh54gDmFaKC4v2ue/x8r5daTlM+8NGiWMOD6JOlE9GK61UYL3qIwX5XEWA6qoN9kzp9 kpArx1nvhsGRoN3yaePpdDXfCg7E83/5Lx+j1GocIp9I7pL6bmfYowcPesTJTdodAZgfDJrH kfLT4B9IUZxEZqYiNXc15uMNPYH0E6CgmTNKj4RgznYhbXPxecz3ru/NNIsJo8Rm7ZHqobIY AAAAAAAA --------------ms030503000405000609090204-- From nobody Tue Feb 23 17:50:53 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77CA1B3475 for ; Tue, 23 Feb 2016 17:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRA5y4tk7QTy for ; Tue, 23 Feb 2016 17:50:50 -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 916561AD062 for ; Tue, 23 Feb 2016 17:50:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 38D4ABE4D; Wed, 24 Feb 2016 01:50:49 +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 J5jTgOjSPy6q; Wed, 24 Feb 2016 01:50:47 +0000 (GMT) Received: from [10.1.1.75] (unknown [216.9.109.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7F6C4BE4C; Wed, 24 Feb 2016 01:50:44 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1456278647; bh=UYbnWfwIpySw1kFrLyPDUGi1ggzWryjLbRhgQHxdu3I=; h=Subject:To:References:From:Date:In-Reply-To:From; b=i2DTBhOnDWYj9yc7GhWwAQpO+ABqpGOrPwGnotlTffeQaHd7AzacNYK6gDkD8yYI7 k5IXAOLlC3uWIQ4j6mMs3gwjxU3FnvneyI4IIYLaPg6hVQF3d0XDaqi5Yn1RmhgThV fxXXiyE/sI9jdtphcviciEgtNP9pvjpXOkCr6xfw= To: =JeffH , IETF TLS WG References: <56CCEB63.1060104@KingsMountain.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <56CD0C71.1090407@cs.tcd.ie> Date: Wed, 24 Feb 2016 01:50:41 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56CCEB63.1060104@KingsMountain.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms050404030709090704000305" Archived-At: Subject: Re: [TLS] TRON notes? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 01:50:52 -0000 This is a cryptographically signed message in MIME format. --------------ms050404030709090704000305 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 23/02/16 23:29, =3DJeffH wrote: > is anyone writing up some notes from TRON > > to share here on the list? >=20 > especially wrt the "What do we know and where are we going?" topic :) >=20 > inquiring minds and all... The WG chairs agreed to do that. With travel and the exceptionally fine content (for which thanks all!), that might take a few days to get done well. S. >=20 > thx >=20 > =3DJeffH >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms050404030709090704000305 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 oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjAyMjQw MTUwNDFaMC8GCSqGSIb3DQEJBDEiBCDKrFBYyKfnLP7IRYNQ3jL9dhaJveyVYthEsCpFRCez CzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBIrCZktDkkIVC65iDKtsMzdySVOZVg8yCn/Htm8Xg1LWdI4ouPEw1K nVeFK21q1rEeGAXUrKTDUEBianXgdMHPqujwNmTLi3jpRAElynSW0TM299bmz+ZqR/SAEUbm /cwYGPOfr3dVxeg2Y75+MRxl9JLQqaYDWX7imTpo3p/qsaj7/QTO7BNUn/Mcv+OU4EBmc0f/ DL2k70L2OjX3t4bbzWmjtK7PUCDC/U967TfyhdRQtM09azD3YInGolk8AldfbRSiLk/CdrIg e5+4vG+SXL6UjZkwe9PBvCmqQ0WbvChuI3NlTCh4KkRtQ5xkmwdhenYRJWFBqvbTDciR8oSa AAAAAAAA --------------ms050404030709090704000305-- From nobody Tue Feb 23 17:57:24 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7847E1B4170 for ; Tue, 23 Feb 2016 17:57:22 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ilyi5Ff_jmh8 for ; Tue, 23 Feb 2016 17:57:21 -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 3E2D01B416C for ; Tue, 23 Feb 2016 17:57:21 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id e63so3891742ywc.3 for ; Tue, 23 Feb 2016 17:57:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=mKz9kkpbU+lIVyGBTDbvhHkpZrRR7j6bzH8IKISzbYY=; b=xsZ4qNh9IMFlY/nCQLfFWjskdjsE7a1PW/XNkppoSRRUXsaxuqSDPugAiAiB5sGhP4 vaXwrpHajbIuJeQeqx6KVsNoa88FpW6sz+0FtjdcqLHozjZt4yzbYdGk2d9+qRH4KFVW hPp28TCXJn3lFh2tI2skTHtuTulTFsNodwk48p1AvY7cKSH8KA7Vox9Qum7RUGzNJCOo PeN76ZvCOD8gfxzyBP0subgHaaiKSUwVfJLzIO5iijEXREP8O70QCzscl8vCthgG+Vqu jDicl5pe2vJCf4A66+vgNaVixdgUS4COw8SdqTch/QBKz7HAvlabExAfYzUKldj0TZXK Tg9g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-type:content-transfer-encoding :message-id; bh=mKz9kkpbU+lIVyGBTDbvhHkpZrRR7j6bzH8IKISzbYY=; b=Osrqze5KTjIhJ9Athd/6GYi9nz2Rk611pCDzEqIk5uBfjmrIqzQB8tIFpPIPeg6XNV lfxd887d86zWHiOYAiIa78ofyREERjr6eao8IlBsNv7kt2n3d1Drzby5oue2hRiNPN4H M8hO949wqEr4OjQlrAEzuBrzFV5/tRETRhOZNyrk16/cDgF3mb/5m2ghuk/JZMV23Srr vmu9pDB/c47bR/iz6qTiJSurWCyGxwUg85D6oYsJ57SnldPU8R3agpysRU98MevCmui/ BAHsiYYFPNKB22n5B3LF40x8TeI4z1JYGb9hZAljDw5v7gtay1y5h1AkHH9dgbK6BSUr 5RLA== X-Gm-Message-State: AG10YOQZyAOnSscj0cqM2yfYtXKEWKC7bZGnnD1ArvkBHvZ31DdfGAHTrvGOXG1wRE5LSA== X-Received: by 10.13.192.130 with SMTP id b124mr20236974ywd.218.1456279040603; Tue, 23 Feb 2016 17:57:20 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id m188sm564481ywe.46.2016.02.23.17.57.19 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 23 Feb 2016 17:57:19 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Tue, 23 Feb 2016 20:57:18 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201602232057.18505.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 01:57:22 -0000 On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: > I propose that we remove DH-based 0-RTT from TLS 1.3. > > As ekr's previous mail noted, the security properties of PSK-based > 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is > much more complex. > > For those who love DH-based 0-RTT, and I know that some people are > fans, here's something that might make you less sad about removing it > from the core spec. You can use DH out of band to negotiate a PSK. > You might even do this as an extension to TLS, but that's of less > value. I think there is a good argument for moving DH 0RTT into a TLS extension. Implementations that are explicitly not going to use it should not be expected to implement it and risk screwing it up. If we accept that premise that online DH 0RTT will be unlikely in practice, then we would be specifying it at least primarily for out-of-band use, and doing it via an extension will probably be cleaner and safer. I would still prefer it be defined in the TLS 1.3 specification document, though optional. Dave From nobody Tue Feb 23 18:38:35 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B857A1B367E for ; Tue, 23 Feb 2016 18:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 TkkOQKRN4p0P for ; Tue, 23 Feb 2016 18:38:32 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 343961B366E for ; Tue, 23 Feb 2016 18:38:32 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id 9so15245054iom.1 for ; Tue, 23 Feb 2016 18:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IrWEzQjbqP/GRf5aO+7mO8L6KNKUrpyiemLya/C8QQ8=; b=dLqg+p1rZCX7yTptwwwFIrmfLlARjAA+f3tRGJwwplMiLptng+mP2g7mKat35ti++f cKoyBDCDLvG7PCskoOFHu6+4zqRyePGUGU7X5AsuC7zbv8coYXpkjoCmNcGUAqSaVlB5 0H50Vf9Pp5lkyuu1ChUGWYK0PoLS9l6ZqXScY4KpnsfEIZ7GoSCTapdM7/Ac9UcSqYZj i5BOFQ+AQcb+ePnPDgR++91QU6CKg5QAjinf+MZWqulduxLTdpghU5ecA/J+lFi75JZr ve+1dSm0yvr0bfE/dxWRYzPCOYnus0J8tb7/aiK9+v8YpaXhuEsyq5igdddvEiYQ+RlK WB7w== 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:date :message-id:subject:from:to:cc:content-type; bh=IrWEzQjbqP/GRf5aO+7mO8L6KNKUrpyiemLya/C8QQ8=; b=RhofCledlIcUCO5/q4txbFuwfCONK/CydWByPpOgCeNqEdD58ZxaD+NTTC8uoT6fFI s5vrU0cV0k1541oawqasQuuAdNjBWnalBPeK7w6zYqtmMmuXESnynxpJ13t3ZcfO+HKZ 1u5VmnJMfQXeaRy/2gC/x/eciXJAYc7V8XmmCdCYP5DBwERsCBjas6EijF80m0FBNHUZ OVleWNwK+3kg89vxHDh1LffMoSHv1eh0WhohEsnDU/w3FNPvX6e+WfaR6Co47uSwqMso k453Cb3Y+LMqx+Rvxl8BHq1iballIO2JMwFmDB5PTfEc6lffF/jML4KEkE0ppIwCisHR FqCg== X-Gm-Message-State: AG10YOTj9tSjyJtnk/7N6AonA4p6o7MakWKaZ1iXfyErrlI3yA7nkH86juo2Ve6VQzVYM7cPF2Z5n9oL6LvBjWnz MIME-Version: 1.0 X-Received: by 10.107.138.90 with SMTP id m87mr39164413iod.127.1456281511554; Tue, 23 Feb 2016 18:38:31 -0800 (PST) Received: by 10.107.183.141 with HTTP; Tue, 23 Feb 2016 18:38:31 -0800 (PST) In-Reply-To: References: Date: Tue, 23 Feb 2016 18:38:31 -0800 Message-ID: From: Bill Cox To: Andrei Popov Content-Type: multipart/alternative; boundary=001a113fe78e30c2aa052c7af603 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 02:38:33 -0000 --001a113fe78e30c2aa052c7af603 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable +1 On Tue, Feb 23, 2016 at 12:02 PM, Andrei Popov wrote: > For general-purpose TLS stacks that have to support PSK anyway (and > therefore already deal with PSK persistence issues), removing DH-based > 0-RTT is a significant simplification. > > Cheers, > > Andrei > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson > Sent: Tuesday, February 23, 2016 11:39 AM > To: Wan-Teh Chang > Cc: tls@ietf.org > Subject: Re: [TLS] Remove DH-based 0-RTT > > On 23 February 2016 at 11:24, Wan-Teh Chang wrote: > > It seems sufficient to just ban client authentication in replayable > > DH-based 0-RTT. Why remove DH-based 0-RTT altogether? > > On the grounds that it is more complex to analyze, build, and test. > And given that deferring the feature does no significant harm to those wh= o > want it. > > I acknowledge that persistence of secrets on clients is a material > difference between that an PSK-based 0-RTT. I just don't think that it's= a > good enough reason to pay for what is a relatively expensive feature. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > > https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ie= tf.org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft= .com%7cf17dcaeb65eb4ecc907e08d33c88ed75%7c72f988bf86f141af91ab2d7cd011db47%= 7c1&sdata=3DiUfZJINzquzcxHr7W6Xf1bo8P34UfkneZOVwj8TjWP0%3d > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113fe78e30c2aa052c7af603 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1

On Tue, Feb 23, 2016 at 12:02 PM, Andrei Popov &l= t;Andrei.Po= pov@microsoft.com> wrote:
F= or general-purpose TLS stacks that have to support PSK anyway (and therefor= e already deal with PSK persistence issues), removing DH-based 0-RTT is a s= ignificant simplification.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.= org] On Behalf Of Martin Thomson
Sent: Tuesday, February 23, 2016 11:39 AM
To: Wan-Teh Chang <wtc@google.com&= gt;
Cc: tls@ietf.org
Subject: Re: [TLS] Remove DH-based 0-RTT

On 23 February 2016 at 11:24, Wan-Teh Chang <wtc@google.com> wrote:
> It seems sufficient to just ban client authentication in replayable > DH-based 0-RTT. Why remove DH-based 0-RTT altogether?

On the grounds that it is more complex to analyze, build, and test.
And given that deferring the feature does no significant harm to those who = want it.

I acknowledge that persistence of secrets on clients is a material differen= ce between that an PSK-based 0-RTT.=C2=A0 I just don't think that it= 9;s a good enough reason to pay for what is a relatively expensive feature.=

_______________________________________________
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protec= tion.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ft= ls&data=3D01%7c01%7cAndrei.Popov%40microsoft.com%7cf17dcaeb65eb4ecc907e= 08d33c88ed75%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=3DiUfZJINzquz= cxHr7W6Xf1bo8P34UfkneZOVwj8TjWP0%3d

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

--001a113fe78e30c2aa052c7af603-- From nobody Tue Feb 23 19:28:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9B121B30A9 for ; Tue, 23 Feb 2016 19:28:14 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ocldd1dN8xGD for ; Tue, 23 Feb 2016 19:28:13 -0800 (PST) Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D20881B2E54 for ; Tue, 23 Feb 2016 19:28:12 -0800 (PST) Received: by mail-yk0-x235.google.com with SMTP id u9so2767001ykd.1 for ; Tue, 23 Feb 2016 19:28: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:date:message-id:subject:from:to :cc:content-type; bh=yMZ7rvlSpxsrJUkyd76erV0+cJVNJyom1X8X59wCi0g=; b=MNwTQu5mcuPgaBKvMeJYEaAkH2NcNUMlHg9gF27LMH1Xo8I/doQk7IB+BXb6bKXsgx 3LXBxpXlDmYiOi2PdHpMnd2hXrkvLBXWoXiKd/2yzWGaArqrN0CJmKGiqfPzGIcosW8c xPtoxCXwMno32cuO6faoSi8OnEMU3dU4Y1lLcWS/D0UTAvYg88vHawOntqjdMXBh6wJZ FLn4XT0T53nbkcRdjEbemApEifgcbdz4z5Y9cznnAKt0Q6je3mtXG2sz9Rt8fqN/wS70 GCwCpdxgr9AQTQeC0FDbKxujcWAQp3/N+Dx1+uwV5ZLjSk4CnHAgBDrv+dBDtw15tETD KxUQ== 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:date :message-id:subject:from:to:cc:content-type; bh=yMZ7rvlSpxsrJUkyd76erV0+cJVNJyom1X8X59wCi0g=; b=HMNT4oAJqLqYZTKy8yZAz5BcVTwQh32gYnNlzFzvXp39pNsK2a9IFW8/+JlJEBJgbX 9i9XUZAVE1qqxWQAbT1ZCT1oSCMJuS/mDNDUkdMdf1i4kSSB3L+E88QE5PJCWXBn1ixi gJS70lK9ljKPfsBiZOnrT1JLcuSKJtqURuNT8rfpwzP6qLh69B/f9H3dAurbP4UIUfzm BH5ilmdR5PF4oXzVucFQKNXRtmkB0dOiI+YoLu+kaVH4gFr/PF8o/excs/2sWNyVWyBi qeO0yDYZ8bgqY5X76iZX1NRjlfbcF4DfoEOE+rkUmzZnl1xVjCRhNy/hq5Ff/1M6lday LuFg== X-Gm-Message-State: AG10YOQgDTWglQwjA0CDnNuwGXpczVQnlfRa3kWVas2dwd+1IEkeaQZVGLXfmFce208KMwbbyzRfLJ3KEv7Jbw== MIME-Version: 1.0 X-Received: by 10.37.25.212 with SMTP id 203mr18503895ybz.163.1456284492150; Tue, 23 Feb 2016 19:28:12 -0800 (PST) Received: by 10.13.216.138 with HTTP; Tue, 23 Feb 2016 19:28:12 -0800 (PST) In-Reply-To: <56CD0C1C.9010501@cs.tcd.ie> References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> <56CD0C1C.9010501@cs.tcd.ie> Date: Tue, 23 Feb 2016 19:28:12 -0800 Message-ID: From: Watson Ladd To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 03:28:15 -0000 On Tue, Feb 23, 2016 at 5:49 PM, Stephen Farrell wrote: > > > On 23/02/16 22:37, Hugo Krawczyk wrote: >> >> (In particular, if these semantics may be based on stuff that happens >> outside TLS, as Karthik and Watson were pointing out, then maybe we really >> put a "Surgeon General" warning on 0.5 data of equal size to that of 0-RTT.) > > That, and/or also do a significant amount of work to consider other > application uses of TLS that aren't well represented by folks who > participate in the development of TLS1.3. And also oddities like > EAP-TLS about which I at least am mostly ignorant but where I'd bet > there's "fun" to be had with 0rtt. Applications shouldn't use 0RTT unless they are absolutely, positively, sure it won't be a problem. It's up to them to determine what the danger is, and up to us to explain what the (minimal) properties provided are. If they rely on extensions then either those extensions need to be included in the security proofs, or we need to make clear that they are not as secure as TLS 1.3, and that implementations which enable both of them can get completely wrecked in new and exciting ways. > > And we have to do that recognising that regardless of what the RFC > says, if developers can improve performance by calling tls_send0() > and not tls_send(), they will do the former. IOW, if we are going > to define dangerous implements, (e.g., with replayable data) then > I think the onus is mostly on us to know what bad effects those > might have before we've done a good job. (We can try do that at > IETF LC, but doing so isn't common and is often messy if we end up > surprising folks.) But will they call tls_send_data_replayable? or tls_send_data_dangerously? API designers need to mark dangerous functions accordingly. (They also need to make APIs easy to use: yes, I am blaming the OpenSSL developers for their repeated and continued failures to do this) > > Cheers, > S. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Feb 23 19:36:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 728FD1B2DA0 for ; Tue, 23 Feb 2016 19:36:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.307 X-Spam-Level: X-Spam-Status: No, score=-4.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0UT4lgNXTofa for ; Tue, 23 Feb 2016 19:36:23 -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 E84FD1B3964 for ; Tue, 23 Feb 2016 19:36:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B03B9BE4D; Wed, 24 Feb 2016 03:36:18 +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 J-WnO0-2LwA1; Wed, 24 Feb 2016 03:36:14 +0000 (GMT) Received: from [127.0.0.1] (unknown [216.9.109.44]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 79EA5BE29; Wed, 24 Feb 2016 03:36:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1456284974; bh=KfYYNyMS3XC7XdMmGARy9yjnPb8ZCmjmmCSdRLA6s5c=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=qPWELI/hZqtNkNpZH/7ogt8OuBfK5FUnlBNdZbAU31mAMlxjNraEfqv90Kb5a2xPv ChTA6L/2sR+3S4fAVuh6KDzbT2iARJy4cNJ4kIBxD/apoxlKW49x7QXKXJDsRqnHV9 Mg/dQ3ONkrQFMcydQC/EMlRXTFOh0qWxo2myux+M= X-Priority: 3 To: watsonbladd@gmail.com From: stephen.farrell@cs.tcd.ie In-Reply-To: References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> <56CD0C1C.9010501@cs.tcd.ie> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Date: Wed, 24 Feb 2016 03:36:03 +0000 Message-ID: MIME-Version: 1.0 Archived-At: Cc: karthik.bhargavan@gmail.com, tls@ietf.org Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 03:36:25 -0000 DQoNCk9uIFR1ZSBGZWIgMjMgMTk6Mjg6MTIgMjAxNiBHTVQtMDgwMCwgV2F0c29uIExhZGQgd3Jv dGU6DQo+IE9uIFR1ZSwgRmViIDIzLCAyMDE2IGF0IDU6NDkgUE0sIFN0ZXBoZW4gRmFycmVsbA0K PiA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+IE9uIDIz LzAyLzE2IDIyOjM3LCBIdWdvIEtyYXdjenlrIHdyb3RlOg0KPiA+Pg0KPiA+PiAoSW4gcGFydGlj dWxhciwgaWYgdGhlc2Ugc2VtYW50aWNzIG1heSBiZSBiYXNlZCBvbiBzdHVmZiB0aGF0IGhhcHBl bnMNCj4gPj4gb3V0c2lkZSBUTFMsIGFzIEthcnRoaWsgYW5kIFdhdHNvbiB3ZXJlIHBvaW50aW5n IG91dCwgdGhlbiBtYXliZSB3ZSByZWFsbHkNCj4gPj4gcHV0IGEgIlN1cmdlb24gR2VuZXJhbCIg d2FybmluZyBvbiAwLjUgZGF0YSBvZiBlcXVhbCBzaXplIHRvIHRoYXQgb2YgMC1SVFQuKQ0KPiA+ DQo+ID4gVGhhdCwgYW5kL29yIGFsc28gZG8gYSBzaWduaWZpY2FudCBhbW91bnQgb2Ygd29yayB0 byBjb25zaWRlciBvdGhlcg0KPiA+IGFwcGxpY2F0aW9uIHVzZXMgb2YgVExTIHRoYXQgYXJlbid0 IHdlbGwgcmVwcmVzZW50ZWQgYnkgZm9sa3Mgd2hvDQo+ID4gcGFydGljaXBhdGUgaW4gdGhlIGRl dmVsb3BtZW50IG9mIFRMUzEuMy4gQW5kIGFsc28gb2RkaXRpZXMgbGlrZQ0KPiA+IEVBUC1UTFMg YWJvdXQgd2hpY2ggSSBhdCBsZWFzdCBhbSBtb3N0bHkgaWdub3JhbnQgYnV0IHdoZXJlIEknZCBi ZXQNCj4gPiB0aGVyZSdzICJmdW4iIHRvIGJlIGhhZCB3aXRoIDBydHQuDQo+IA0KPiBBcHBsaWNh dGlvbnMgc2hvdWxkbid0IHVzZSAwUlRUIHVubGVzcyB0aGV5IGFyZSBhYnNvbHV0ZWx5LA0KPiBw b3NpdGl2ZWx5LCBzdXJlIGl0IHdvbid0IGJlIGEgcHJvYmxlbS4gSXQncyB1cCB0byB0aGVtIHRv IGRldGVybWluZQ0KPiB3aGF0IHRoZSBkYW5nZXIgaXMsIGFuZCB1cCB0byB1cyB0byBleHBsYWlu IHdoYXQgdGhlIChtaW5pbWFsKQ0KPiBwcm9wZXJ0aWVzIHByb3ZpZGVkIGFyZS4gSWYgdGhleSBy ZWx5IG9uIGV4dGVuc2lvbnMgdGhlbiBlaXRoZXIgdGhvc2UNCj4gZXh0ZW5zaW9ucyBuZWVkIHRv IGJlIGluY2x1ZGVkIGluIHRoZSBzZWN1cml0eSBwcm9vZnMsIG9yIHdlIG5lZWQgdG8NCj4gbWFr ZSBjbGVhciB0aGF0IHRoZXkgYXJlIG5vdCBhcyBzZWN1cmUgYXMgVExTIDEuMywgYW5kIHRoYXQN Cj4gaW1wbGVtZW50YXRpb25zIHdoaWNoIGVuYWJsZSBib3RoIG9mIHRoZW0gY2FuIGdldCBjb21w bGV0ZWx5IHdyZWNrZWQNCj4gaW4gbmV3IGFuZCBleGNpdGluZyB3YXlzLg0KPiANCj4gPg0KPiA+ IEFuZCB3ZSBoYXZlIHRvIGRvIHRoYXQgcmVjb2duaXNpbmcgdGhhdCByZWdhcmRsZXNzIG9mIHdo YXQgdGhlIFJGQw0KPiA+IHNheXMsIGlmIGRldmVsb3BlcnMgY2FuIGltcHJvdmUgcGVyZm9ybWFu Y2UgYnkgY2FsbGluZyB0bHNfc2VuZDAoKQ0KPiA+IGFuZCBub3QgdGxzX3NlbmQoKSwgdGhleSB3 aWxsIGRvIHRoZSBmb3JtZXIuIElPVywgaWYgd2UgYXJlIGdvaW5nDQo+ID4gdG8gZGVmaW5lIGRh bmdlcm91cyBpbXBsZW1lbnRzLCAoZS5nLiwgd2l0aCByZXBsYXlhYmxlIGRhdGEpIHRoZW4NCj4g PiBJIHRoaW5rIHRoZSBvbnVzIGlzIG1vc3RseSBvbiB1cyB0byBrbm93IHdoYXQgYmFkIGVmZmVj dHMgdGhvc2UNCj4gPiBtaWdodCBoYXZlIGJlZm9yZSB3ZSd2ZSBkb25lIGEgZ29vZCBqb2IuIChX ZSBjYW4gdHJ5IGRvIHRoYXQgYXQNCj4gPiBJRVRGIExDLCBidXQgZG9pbmcgc28gaXNuJ3QgY29t bW9uIGFuZCBpcyBvZnRlbiBtZXNzeSBpZiB3ZSBlbmQgdXANCj4gPiBzdXJwcmlzaW5nIGZvbGtz LikNCj4gDQo+IEJ1dCB3aWxsIHRoZXkgY2FsbCB0bHNfc2VuZF9kYXRhX3JlcGxheWFibGU/IG9y DQo+IHRsc19zZW5kX2RhdGFfZGFuZ2Vyb3VzbHk/DQoNClNhZGx5LCB5ZXMsIHRoZXkgd2lsbCwg SSB0aGluay4gRXZpZGVuY2Ugd2VsY29tZSB0aG91Z2guIA0KDQpJdCBpcyBhIGJpZyBhbmQgaW1w ZXJmZWN0IHdvcmxkLg0KDQpTLg0KDQoNCj4gQVBJIGRlc2lnbmVycyBuZWVkIHRvIG1hcmsgZGFu Z2Vyb3VzDQo+IGZ1bmN0aW9ucyBhY2NvcmRpbmdseS4gKFRoZXkgYWxzbyBuZWVkIHRvIG1ha2Ug QVBJcyBlYXN5IHRvIHVzZTogeWVzLA0KPiBJIGFtIGJsYW1pbmcgdGhlIE9wZW5TU0wgZGV2ZWxv cGVycyBmb3IgdGhlaXIgcmVwZWF0ZWQgYW5kIGNvbnRpbnVlZA0KPiBmYWlsdXJlcyB0byBkbyB0 aGlzKQ0KPiANCj4gPg0KPiA+IENoZWVycywNCj4gPiBTLg0KPiA+DQo+ID4NCj4gPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IFRMUyBtYWlsaW5n IGxpc3QNCj4gPiBUTFNAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3Rscw0KPiA+DQo+IA0KPiANCj4gDQo+IC0tIA0KPiAiTWFuIGlzIGJvcm4gZnJl ZSwgYnV0IGV2ZXJ5d2hlcmUgaGUgaXMgaW4gY2hhaW5zIi4NCj4gLS1Sb3Vzc2VhdS4NCj4= From nobody Tue Feb 23 19:40:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5CBC1B4155 for ; Tue, 23 Feb 2016 19:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 mLcmh2YBA6Ws for ; Tue, 23 Feb 2016 19:40:09 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6BB1B4043 for ; Tue, 23 Feb 2016 19:40:08 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id l143so3569679lfe.2 for ; Tue, 23 Feb 2016 19:40:08 -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:content-type; bh=OuIhBXZcqaUeXceC6swVSH7lCZvxHYbVKOD6AKWHkRE=; b=fCOzY512H8BN5ebu8EM5Yo+QOKT+VEC8+7PatCBj8QEsql7aDqdAran3UUxUgr2ii8 +cSz4Nb/JkPqi9KwmQqAfE3uau1LqmdyP/QB2+eJdpEhQK4FDeRqjtGKINGQ9oOjrqvI MzdQPVy/A0sjRV/AJNbB+abkf9k00O9bESljFX1zhz4T4DlSO49zqYp6tvaX2TI8NQtI 93yP+JaTYdjoojSF9OAufs/0/FBnVZjfmrJZEuWa5jY4RgigpFDaeyuUig4fy+Z/fYDv tFh/pRK+9UZ6zTcOLDtE/hh0LlvVw8fVbzVafTCXTLOEqrC9wPnjc3TtssU7AlFNQLht xCeQ== 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:content-type; bh=OuIhBXZcqaUeXceC6swVSH7lCZvxHYbVKOD6AKWHkRE=; b=ShykqiXEaaLPYgyRfi/YDRqgtzw+CJFeIC33wYP4sfk9HxZ93cvFm8WtdN/b9Lgpbd AMoHtB31sfHIP0dVqUIjd5PW884Z/hw2vID6gCmd/uNT3lNy5+y/aa9XfQia9P1isjii nnn4gujDCbMJORJRpAVHYQpxTfIuf9r/wIAVlcKJ5tukdgDhN9pytAfWohTWEIdalB// koBzFWZQGaG/07ef3oZlzQ1K5pOEIQGm4phht9GBAmkVMAPNEtdrCH8h7id8DAviF8Pt 7My0llOPWAD2+cDXcYJoPSz8Jh8/o3K0PSY6Z4Y9rjHOxOVMx78SwYTt/VOStVi2gTLz yb0w== X-Gm-Message-State: AG10YOSHNqD+C9P51xskpizv1dbERvM7YEKqS4L/fK3L7+q7ODIKnIqoD0HsVvJ/KfE496HcvKOqwV7Hpew8gg== X-Received: by 10.25.21.90 with SMTP id l87mr13440339lfi.64.1456285206907; Tue, 23 Feb 2016 19:40:06 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Tue, 23 Feb 2016 19:39:37 -0800 (PST) In-Reply-To: <201602232057.18505.davemgarrett@gmail.com> References: <201602232057.18505.davemgarrett@gmail.com> From: Hugo Krawczyk Date: Tue, 23 Feb 2016 22:39:37 -0500 X-Google-Sender-Auth: JI2FdeFJL3o0JUKVmV1-ZrS-V40 Message-ID: To: Dave Garrett Content-Type: multipart/alternative; boundary=001a113d9b54731315052c7bd203 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 03:40:11 -0000 --001a113d9b54731315052c7bd203 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett wrote: > On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: > > I propose that we remove DH-based 0-RTT from TLS 1.3. > > > > As ekr's previous mail noted, the security properties of PSK-based > > 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is > > much more complex. > > > > For those who love DH-based 0-RTT, and I know that some people are > > fans, here's something that might make you less sad about removing it > > from the core spec. You can use DH out of band to negotiate a PSK. > > You might even do this as an extension to TLS, but that's of less > > value. > > I think there is a good argument for moving DH 0RTT into a TLS extension. > Implementations that are explicitly not going to use it should not be > expected to implement it and risk screwing it up. If we accept that premi= se > that online DH 0RTT will be unlikely in practice, then we would be > specifying it at least primarily for out-of-band use, and doing it via an > extension will probably be cleaner and safer. > =E2=80=8BCombining this comment (which I agree with) with the following com= ment from Watson in another thread: =E2=80=8B> =E2=80=8B If they rely on extensions then either those =E2=80=8B> =E2=80=8B extensions need to be included in the security proofs, or we need to =E2=80=8B> =E2=80=8B make clear that they are not as secure as TLS 1.3, and that =E2=80=8B> =E2=80=8B implementations which enable both of them can get completely wrecked >in new and exciting ways. =E2=80=8B =E2=80=8BWe get that even if it is decided not to include the DH-based 0-RT= T=E2=80=8B as part of mandatory-to-implement TLS 1.3, it should be defined as an extension and as part of the TLS 1.3 document. Leaving the reduction from this case to PSK (as Martin suggested) to popular imagination is too dangerous. By including it as part of TLS 1.3 official text we also encourage the groups that are currently analyzing the protocol to include this specific mechanism in their analysis. If they find something wrong with it then even more reason to do the analysis. > I would still prefer it be defined in the TLS 1.3 specification document, > though optional. > =E2=80=8BI suggest to also define TLS 1.3-EZ. A subset of core safe functionality that should address the majority of the usage cases. Hugo =E2=80=8B > > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113d9b54731315052c7bd203 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett <d= avemgarrett@gmail.com> wrote:
On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote:
> I propose that we remove DH-based 0-RTT from TLS 1.3.
>
> As ekr's previous mail noted, the security properties of PSK-based=
> 0-RTT and DH-based 0-RTT are almost identical.=C2=A0 And DH-based 0-RT= T is
> much more complex.
>
> For those who love DH-based 0-RTT, and I know that some people are
> fans, here's something that might make you less sad about removing= it
> from the core spec.=C2=A0 You can use DH out of band to negotiate a PS= K.
> You might even do this as an extension to TLS, but that's of less<= br> > value.

I think there is a good argument for moving DH 0RTT into a TLS exten= sion. Implementations that are explicitly not going to use it should not be= expected to implement it and risk screwing it up. If we accept that premis= e that online DH 0RTT will be unlikely in practice, then we would be specif= ying it at least primarily for out-of-band use, and doing it via an extensi= on will probably be cleaner and safer.

=
=E2=80=8BCombining this comment (which I agree wi= th) with the following comment from Watson in another thread:

=E2=80= =8B> =E2=80=8B
=C2=A0If they rely on extensions then either those
= =E2=80=8B> =E2=80=8B
extensions need to be included in the security= proofs, or we need to
=E2=80=8B> =E2=80=8B
ma= ke clear that they are not as secure as TLS 1.3, and that
=E2=80=8B> =E2=80=8B
implementations which enable both of the= m can get completely wrecked
>in new and exciting ways.
=E2=80=8B
=C2=A0
=E2=80=8BWe get tha= t even if it is decided not to include the DH-based 0-RTT=E2=80=8B as part = of mandatory-to-implement TLS 1.3, it should be defined as an extension and= as part of the TLS 1.3 document. Leaving the reduction from this case to P= SK (as Martin suggested) to popular imagination is too dangerous. By includ= ing it as part of TLS 1.3 official text we also encourage the groups that a= re currently analyzing the protocol to include this specific mechanism in t= heir analysis. If they find something wrong with it then even more reason t= o do the analysis.



I would still prefer it be defined in the TLS 1.3 specification document, t= hough optional.

=E2=80=8BI suggest to also define TLS 1.3-EZ.
A subset of core safe functionality that should address the= majority of the usage cases.
Hugo
=C2=A0=E2=80=8B
=C2=A0


Dave

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

--001a113d9b54731315052c7bd203-- From nobody Tue Feb 23 19:48:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD8011B436C for ; Tue, 23 Feb 2016 19:48:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 jTfDFmplMCyA for ; Tue, 23 Feb 2016 19:48:47 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::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 7663D1B4371 for ; Tue, 23 Feb 2016 19:48:47 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id bc4so3202825lbc.2 for ; Tue, 23 Feb 2016 19:48:47 -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:content-type; bh=mntcWolBdCm3Pl0RqPnPphkZauId3BPSKTkBj035h2o=; b=CoqiGJwHsVUGKwG3q36InZHr9zCECb9BOzzBZUlAPsrYpwyDaHLxQAVygQn1VYODgK LyPdvfVtuc4q8GL+zXe02TwsgVXpDGUAnWy8nyzwpMHCTEAfbX3KdMnAkOCbpFsItN85 +HNaRGG7RhnpvJbpqYF9V9W3tMAwl+uuYjQ9XsTJT8fq3k/J8dLGv4y7mG7zfpCS10CG 7ODMR8J6YapDHuNaeQEIWr+FKvIuuWzY0lQ8Va/+j4q1erFCcXwCukGYxW8plsQ9VZWn XdCSaMN5TvLozwWSpdqr+k5R9YnyTXNB+NmGgNdDbqOim40HfHJEnvWX/tNJAcp6EGQD +mTw== 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:content-type; bh=mntcWolBdCm3Pl0RqPnPphkZauId3BPSKTkBj035h2o=; b=ljbNBWm+8rx7jD4IybF5BxDEjf/LBKEincYeogi6vyYvqMP6k5pKjzhEnoQ2HFmIG3 wi/jH9qc6Kdn8VvzdXCyvxtqU3XXULJwsA8KnHR5DY71YcNF+bwvVBSilAZxil6p1AIy usrROoPQCtgpSn0fyDNHHJo7muvbbdCO28JcY6oG77SZ/dLFA+lkHb9JRB2G7NPtR34P NSXBluS+2SL3S5TLuMCO4+6oIJt8aqEnmfPLubc17vr+IG28UtpoXi+0sQx3+YULdwUI b6Kx16mgDJ5MVJm27bpBIE0QPCvK37I7NQV39ZDCkgaFJAZ1NtvVPYhdku87tecmZWMX /PwQ== X-Gm-Message-State: AG10YORmrak60MtPuqQfSdz//qEZP0WXJEzYJAdZVEfZ+s5fg8h/g/s/Px7EZvQTYvZvpN+6BM8UfAxee/hXbA== X-Received: by 10.112.168.5 with SMTP id zs5mr14343549lbb.56.1456285725382; Tue, 23 Feb 2016 19:48:45 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Tue, 23 Feb 2016 19:48:15 -0800 (PST) In-Reply-To: References: <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> From: Hugo Krawczyk Date: Tue, 23 Feb 2016 22:48:15 -0500 X-Google-Sender-Auth: 8KCUWIUwcO39fYQOz1YAgCkM9-U Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c2409a5a5d88052c7bf15a Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 03:48:49 -0000 --001a11c2409a5a5d88052c7bf15a Content-Type: text/plain; charset=UTF-8 I was trying to articulate what does the analysis in OPTLS that does not include the client's Finished message (or client authentication) means in practical terms for 0.5-RTT data. I think that one way to put it is that for the server it guarantees confidentiality against passive (only) attackers and for the client it provides data authentication (proof of origin and integrity). Note that confidentiality against passive attackers is the same type of assurance we provide to the encrypted server's identity. The same way a server needs to "understand" that any active attacker can learn its identity from a TLS handshake, it also needs to understand that 0.5 data is open to any active attacker. Any expectations of 0.5 data being directed to a specific client need to be eliminated. Hugo On Tue, Feb 23, 2016 at 5:52 PM, Martin Thomson wrote: > On 23 February 2016 at 14:37, Hugo Krawczyk > wrote: > > It seems to imply that you are attaching some "client-specific semantics" > > even to keys that were not authenticated by the client. > > It's primarily a privacy concern, though it's a pretty weak concern. > --001a11c2409a5a5d88052c7bf15a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was trying to articulate what does the analys= is in OPTLS that does not include the client's Finished message (or cli= ent authentication) means in practical terms for 0.5-RTT data. I think that= one way to put it is that for the server it guarantees confidentiality aga= inst passive (only) attackers and for the client it provides data authentic= ation (proof of origin and integrity).

Note that =C2=A0confidentiality against passive attackers is the same type= of assurance we provide to the encrypted server's identity. The same w= ay a server needs to "understand" that any active attacker can le= arn its identity from a TLS handshake, it also needs to understand that 0.5= data is open to any active attacker. Any expectations of 0.5 data being di= rected to a specific client need to be eliminated.

Hugo
=C2=A0
On Tue, Feb 23, 2016 at 5:52 PM, Martin Thomso= n <martin.thomson@gmail.com> wrote:
On 23 February 2016 at 14:37, Hugo Krawc= zyk <hugo@ee.technion.ac.il> wrote:
> It seems to imply that you are attaching some "client-specific se= mantics"
> even to keys that were not authenticated by the client.

It's primarily a privacy concern, though it's a pretty weak = concern.

--001a11c2409a5a5d88052c7bf15a-- From nobody Tue Feb 23 20:04:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3891B43C9 for ; Tue, 23 Feb 2016 20:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.367 X-Spam-Level: X-Spam-Status: No, score=-102.367 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jW5kFivDNaZ5 for ; Tue, 23 Feb 2016 20:04:33 -0800 (PST) Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) by ietfa.amsl.com (Postfix) with SMTP id 8039B1B43CB for ; Tue, 23 Feb 2016 20:04:33 -0800 (PST) Received: (qmail 23276 invoked by uid 0); 24 Feb 2016 04:04:31 -0000 Received: from unknown (HELO CMOut01) (10.0.90.82) by gproxy8.mail.unifiedlayer.com with SMTP; 24 Feb 2016 04:04:31 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id N44R1s00W2UhLwi0144Uwl; Tue, 23 Feb 2016 21:04:30 -0700 X-Authority-Analysis: v=2.1 cv=O8aq4nNW c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=-GPFTR9Xtg4A:10 a=jFJIQSaiL_oA:10 a=1ibwJlUuAAAA:8 a=rf1afZWjskZX-JQqEL8A:9 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc:To; bh=UofHAyv59t+gH08+qjpcHScdSRfavVrrjv+UphjiHFk=; b=U/AlhIe1aunqq50WzxUQbGf9Q2cwnM7hdBdsX25YKLdik2ac50jMo1GCxeMcf2J8569uoSIalTaINbaNtQ9AloccwPSZeiLCyosiataoqyuBtYei5K6ahDIXwiOMpjzo; Received: from [73.202.80.238] (port=48325 helo=[192.168.11.22]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aYQgc-0001xD-GO; Tue, 23 Feb 2016 21:04:26 -0700 To: Stephen Farrell From: =JeffH Message-ID: <56CD2BC7.6030005@KingsMountain.com> Date: Tue, 23 Feb 2016 20:04:23 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 73.202.80.238 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] TRON notes? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 04:04:35 -0000 Stephen replied: > On 23/02/16 23:29, =JeffH wrote: >> is anyone writing up some notes from TRON >> >> to share here on the list? >> >> especially wrt the "What do we know and where are we going?" topic :) >> >> inquiring minds and all... > > The WG chairs agreed to do that. With travel and the exceptionally > fine content (for which thanks all!), that might take a few days > to get done well. great, thx, glad to know they will be forthcoming :) =JeffH From nobody Tue Feb 23 23:11:20 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B36D31B4633 for ; Tue, 23 Feb 2016 23:11:19 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL9iJ3jH4FKA for ; Tue, 23 Feb 2016 23:11:17 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801731B461F for ; Tue, 23 Feb 2016 23:11:17 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id e63so8323953ywc.3 for ; Tue, 23 Feb 2016 23:11:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=s8pQie+DuwBF07io071/K28Oq9qeUCW9bHL2f7tXiEU=; b=uU/VFktaIl941hcbgpIl0TcZzyZ655FJSPjaKPJee4AR9mfX6pvlwKr517TpiN/Cxv ffVOVJrHeM3x0XRKMHOpz/MWgu4VAXbGz866++XrJYPZmBq0hHe6GBOaGRSsENgbMH/+ 3PjrBdrjnu4ycfeqc5cpl0ZCqNeELIIQU/0CZbr+KwGyeXweOvwPss77ku7TrGqzvI0U MQ/kGDtqdJh+QvZnFjH+zURsWpvkeYKYw2tvzNPYPkJ/OXSLJg+CFHOS5Zfix5rL9XLl J14yORaKgoerwtV1ARzBx7oc2Y+mXXsb2w8i7W9VI7ZUXra0QCyfBnKmXoxI91WmfJq8 L4kA== 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:date :message-id:subject:from:to:cc:content-type; bh=s8pQie+DuwBF07io071/K28Oq9qeUCW9bHL2f7tXiEU=; b=Ez3UnEAXQVzextYvxgAfMcXsBayIrulQfsnXqmj6rNjrSkK15njJJ0KbGSmCyXhMSh k4on2hJZdFBqc9qKzDQrvRdVEqvRKyRXv1pvBfSmnqTVZF37rwFQMf7kxrWU1FQ6sdJ7 DR5pjA5Tq6ldY32cnA3XKCNs0iR5iFgb8Ceic73K2QiZ2j7e9hpi++HWe51He692XD4h JNFVW0kopsgjIc+U3sMaczhsdkc+80Yg6r2WRuYZjgc252BLZ12J2cL8f9CVR0DVpdD0 u5BEfP11Xdyi9ez32zX2ZF9FuQcR9SON3bNxMt93hOfLDjwOKCw5KurXqiwT05WmX9l+ G4tA== X-Gm-Message-State: AG10YOTmo9sPcpHn06noeWKVVIFDELwMGYuI+k0g0zn0jBDWXSOV7QS2mZ7yVlbu/ut+0LnFQ7X7ICObkTN8cw== MIME-Version: 1.0 X-Received: by 10.129.45.2 with SMTP id t2mr19032634ywt.182.1456297876827; Tue, 23 Feb 2016 23:11:16 -0800 (PST) Received: by 10.13.216.138 with HTTP; Tue, 23 Feb 2016 23:11:16 -0800 (PST) In-Reply-To: References: <201602232057.18505.davemgarrett@gmail.com> Date: Tue, 23 Feb 2016 23:11:16 -0800 Message-ID: From: Watson Ladd To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 07:11:19 -0000 On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk wrote: > > > On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett > wrote: >> >> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: >> > I propose that we remove DH-based 0-RTT from TLS 1.3. >> > >> > As ekr's previous mail noted, the security properties of PSK-based >> > 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is >> > much more complex. >> > >> > For those who love DH-based 0-RTT, and I know that some people are >> > fans, here's something that might make you less sad about removing it >> > from the core spec. You can use DH out of band to negotiate a PSK. >> > You might even do this as an extension to TLS, but that's of less >> > value. >> >> I think there is a good argument for moving DH 0RTT into a TLS extension. >> Implementations that are explicitly not going to use it should not be >> expected to implement it and risk screwing it up. If we accept that premise >> that online DH 0RTT will be unlikely in practice, then we would be >> specifying it at least primarily for out-of-band use, and doing it via an >> extension will probably be cleaner and safer. > > > Combining this comment (which I agree with) with the following comment from > Watson in another thread: > >> > If they rely on extensions then either those >> > extensions need to be included in the security proofs, or we need to >> > make clear that they are not as secure as TLS 1.3, and that >> > implementations which enable both of them can get completely wrecked >>in new and exciting ways. > > We get that even if it is decided not to include the DH-based 0-RTT as part > of mandatory-to-implement TLS 1.3, it should be defined as an extension and > as part of the TLS 1.3 document. Leaving the reduction from this case to PSK > (as Martin suggested) to popular imagination is too dangerous. By including > it as part of TLS 1.3 official text we also encourage the groups that are > currently analyzing the protocol to include this specific mechanism in their > analysis. If they find something wrong with it then even more reason to do > the analysis. > > >> >> I would still prefer it be defined in the TLS 1.3 specification document, >> though optional. > > > I suggest to also define TLS 1.3-EZ. > A subset of core safe functionality that should address the majority of the > usage cases. I strongly encourage this proposal, and will even massacre the markdown to attempt it. I also commit to implementing TLS 1.3-EZ in Go, and possibly in C based on Amazon's s2n. (A trustable X509 library in C is still beyond my reach, so that C might be server-only). > > Hugo > > >> >> >> >> Dave >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Feb 23 23:43:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E6D61B4691 for ; Tue, 23 Feb 2016 23:43:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 mvM24oANxUgn for ; Tue, 23 Feb 2016 23:43:01 -0800 (PST) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF091B4726 for ; Tue, 23 Feb 2016 23:43:00 -0800 (PST) Received: by mail-yk0-x232.google.com with SMTP id z13so4565081ykd.0 for ; Tue, 23 Feb 2016 23:43: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:content-type; bh=0VuQpjSg48QdluQdSSyizPJ8PkEqwwuGZAZZavcXuWY=; b=Nr05oz9JbxbAKarGkHmuYYic2tMVTN1v1ZBHdZAI9jNhGjLNdUKT0yqiETVHX+1e93 tIR4aYVQc22fAj/Um8zURmtwxIM6qBGSHx3X+4MsKChtTxHPzxR2NOyclMRNaQZNGT7W YSpiNltX1Z1wZm7re2x6jmJ0hVhz63/ZrBEGjuTGMsU/lCNmtYfLBnOZCb32oEqWusHZ zIWqab5c3rUgAlUP9U309bOMEmpracQTPOVH2Cuzb+qZllSwXIYenWWSlFatBgjgMHRr /v6oSwp+DnuGizZ3XwApLO7nNfNZqoW986GNUdxlihPt7DgfsNVgtbQieN0beXnSS20V S6RA== 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-type; bh=0VuQpjSg48QdluQdSSyizPJ8PkEqwwuGZAZZavcXuWY=; b=cGdQ3/BeJn0I4IHRrdQAZMt3+XhSVcZIUhKA92w8S5J88RXhMoXp7AfMF/1Xk1IICp MCEOnonxxiSkhCQjV8FmJgVYZ9pCsEZ5ppgElARygCRyEjDdrGP6uz5lUFrOWllgl/+v z9h8P0UF+g4wm+DnnNFwV7zXADSvfFKAGLe7VOX3TQGZrPWniiqH8cLuadLFsYY5BCzQ ncUNmUAlhNwiK+MuaiW07vfGnFMSrEqIIWNdvUKxN5uEY3dcy7PzI9zWn82mgccdh0xb K5g8rfIsGlThO7tKynmXXFQpgeu1N6I6m7uzeon4tlTw4bTTQ8qeivfU7jKmQc0pPSnt 20Uw== X-Gm-Message-State: AG10YOQzyEbMSZQPItdCLhCrEnk7VdBAe8gJ0GXfI0KavlE+NQBwEUkaaTBRBz+luPVgT4nh0yNOEurAlBCxOQ== X-Received: by 10.37.230.210 with SMTP id d201mr1942939ybh.74.1456299780258; Tue, 23 Feb 2016 23:43:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Tue, 23 Feb 2016 23:42:20 -0800 (PST) In-Reply-To: References: <201602232057.18505.davemgarrett@gmail.com> From: Eric Rescorla Date: Wed, 24 Feb 2016 15:42:20 +0800 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=94eb2c0a8b5416f4a6052c7f37c7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 07:43:03 -0000 --94eb2c0a8b5416f4a6052c7f37c7 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd wrote: > On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk > wrote: > > > > > > On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett > > wrote: > >> > >> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: > >> > I propose that we remove DH-based 0-RTT from TLS 1.3. > >> > > >> > As ekr's previous mail noted, the security properties of PSK-based > >> > 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is > >> > much more complex. > >> > > >> > For those who love DH-based 0-RTT, and I know that some people are > >> > fans, here's something that might make you less sad about removing it > >> > from the core spec. You can use DH out of band to negotiate a PSK. > >> > You might even do this as an extension to TLS, but that's of less > >> > value. > >> > >> I think there is a good argument for moving DH 0RTT into a TLS > extension. > >> Implementations that are explicitly not going to use it should not be > >> expected to implement it and risk screwing it up. If we accept that > premise > >> that online DH 0RTT will be unlikely in practice, then we would be > >> specifying it at least primarily for out-of-band use, and doing it via > an > >> extension will probably be cleaner and safer. > > > > > > Combining this comment (which I agree with) with the following comment > from > > Watson in another thread: > > > >> > > If they rely on extensions then either those > >> > > extensions need to be included in the security proofs, or we need to > >> > > make clear that they are not as secure as TLS 1.3, and that > >> > > implementations which enable both of them can get completely wrecked > >>in new and exciting ways. > > > > We get that even if it is decided not to include the DH-based 0-RTT as > part > > of mandatory-to-implement TLS 1.3, it should be defined as an extension > and > > as part of the TLS 1.3 document. Leaving the reduction from this case to > PSK > > (as Martin suggested) to popular imagination is too dangerous. By > including > > it as part of TLS 1.3 official text we also encourage the groups that are > > currently analyzing the protocol to include this specific mechanism in > their > > analysis. If they find something wrong with it then even more reason to > do > > the analysis. > > > > > >> > >> I would still prefer it be defined in the TLS 1.3 specification > document, > >> though optional. > > > > > > I suggest to also define TLS 1.3-EZ. > > A subset of core safe functionality that should address the majority of > the > > usage cases. > > I strongly encourage this proposal, and will even massacre the > markdown to attempt it. Great. Let's sync up as we get a little closer to done. I also commit to implementing TLS 1.3-EZ in > Go, and possibly in C based on Amazon's s2n. (A trustable X509 library > in C is still beyond my reach, so that C might be server-only). > I believe Richard Barnes has already started something along these lines, so maybe you guys could join forces (not sure how confident he is in it). https://github.com/bifurcation/mint This library currently interoperates with my experimental implementation in NSS. -Ekr > > > > Hugo > > > > > >> > >> > >> > >> Dave > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0a8b5416f4a6052c7f37c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:
>
>
> On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
>>
>> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: >> > I propose that we remove DH-based 0-RTT from TLS 1.3.
>> >
>> > As ekr's previous mail noted, the security properties of = PSK-based
>> > 0-RTT and DH-based 0-RTT are almost identical.=C2=A0 And DH-b= ased 0-RTT is
>> > much more complex.
>> >
>> > For those who love DH-based 0-RTT, and I know that some peopl= e are
>> > fans, here's something that might make you less sad about= removing it
>> > from the core spec.=C2=A0 You can use DH out of band to negot= iate a PSK.
>> > You might even do this as an extension to TLS, but that's= of less
>> > value.
>>
>> I think there is a good argument for moving DH 0RTT into a TLS ext= ension.
>> Implementations that are explicitly not going to use it should not= be
>> expected to implement it and risk screwing it up. If we accept tha= t premise
>> that online DH 0RTT will be unlikely in practice, then we would be=
>> specifying it at least primarily for out-of-band use, and doing it= via an
>> extension will probably be cleaner and safer.
>
>
> Combining this comment (which I agree with) with the following comment= from
> Watson in another thread:
>
>>
>=C2=A0 If they rely on extensions then either those
>>
> extensions need to be included in the security proofs, or we need to >>
> make clear that they are not as secure as TLS 1.3, and that
>>
> implementations which enable both of them can get completely wrecked >>in new and exciting ways.
>
> We get that even if it is decided not to include the DH-based 0-RTT as= part
> of mandatory-to-implement TLS 1.3, it should be defined as an extensio= n and
> as part of the TLS 1.3 document. Leaving the reduction from this case = to PSK
> (as Martin suggested) to popular imagination is too dangerous. By incl= uding
> it as part of TLS 1.3 official text we also encourage the groups that = are
> currently analyzing the protocol to include this specific mechanism in= their
> analysis. If they find something wrong with it then even more reason t= o do
> the analysis.
>
>
>>
>> I would still prefer it be defined in the TLS 1.3 specification do= cument,
>> though optional.
>
>
> I suggest to also define TLS 1.3-EZ.
> A subset of core safe functionality that should address the majority o= f the
> usage cases.

I strongly encourage this proposal, and will even massacre the<= br> markdown to attempt it.

Great. Let's sy= nc up as we get a little closer to done.


I also commit to implementing TLS 1.3-EZ in
Go, and possibly in C based on Amazon's s2n. (A trustable X509 library<= br> in C is still beyond my reach, so that C might be server-only).

I believe Richard Barnes has already started somet= hing along these lines,
so maybe you guys could join forces (not = sure how confident he is in
it).


This library currently interoperates wit= h my experimental implementation
in NSS.

-Ekr


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



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

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

--94eb2c0a8b5416f4a6052c7f37c7-- From nobody Wed Feb 24 07:44:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53E751B368C for ; Wed, 24 Feb 2016 07:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 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, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx4u8tfitvKB for ; Wed, 24 Feb 2016 07:44:26 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7F41B372B for ; Wed, 24 Feb 2016 07:44:26 -0800 (PST) Received: from pps.filterd (m0001303.ppops.net [127.0.0.1]) by m0001303.ppops.net (8.15.0.59/8.15.0.59) with SMTP id u1OFg08k002616; Wed, 24 Feb 2016 07:44:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=bpFYki6V1TlJW5he7dHeH8ynl/G5PNR/SckBU9EXPbE=; b=dd6xoz11ugrudPU0cp8egR1t+MFkK110dH5TYU8jJp4mX5aezLyeLOsseooh4se73CUq c4niTDXtxTbhLgHmB1Lz7wrhpQ1hj0XojEevEqIMUzna8zZ/FAyNcLwwcF8WcSFc5/SY WGk40mgnQ/Ki3WLUJ4b+FzcVgoe7vFW61Ys= Received: from mail.thefacebook.com ([199.201.64.23]) by m0001303.ppops.net with ESMTP id 218wt8bxrw-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 24 Feb 2016 07:44:20 -0800 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.151]) by PRN-CHUB15.TheFacebook.com ([fe80::3479:9544:c2df:1fc0%12]) with mapi id 14.03.0248.002; Wed, 24 Feb 2016 07:44:18 -0800 From: Subodh Iyengar To: Eric Rescorla , Watson Ladd Thread-Topic: [TLS] Remove DH-based 0-RTT Thread-Index: AQHRbmz3h1PWJrQdf02SDKus8BJPkJ869qMAgAAcl4CAADsiAIAACK4A///+s+8= Date: Wed, 24 Feb 2016 15:44:17 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99564E7F92@PRN-MBX01-4.TheFacebook.com> References: <201602232057.18505.davemgarrett@gmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: multipart/alternative; boundary="_000_974CF78E8475CD4CA398B1FCA21C8E99564E7F92PRNMBX014TheFac_" MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-24_09:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 15:44:29 -0000 --_000_974CF78E8475CD4CA398B1FCA21C8E99564E7F92PRNMBX014TheFac_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Removing DH based 0-RTT would make it more important to make the lifetime o= f the ticket enforced. One interesting difference is that DH based 0-RTT requires proof of possess= ion of the private key for the client to accept the connection, however PSK= based 0-RTT might not be associated with a certificate at all. Thus the on= ly way to prove that the key is still fresh is to limit the time that the P= SK is valid and strictly bound that time. Unless we add a way for the clien= t to require a server authentication during PSK resumption. This is relevant in situations where compromise of the ephemeral key does n= ot mean that the long term private key has been compromised like in ssl off= loading type scenarios. Subodh Iyengar ________________________________ From: TLS [tls-bounces@ietf.org] on behalf of Eric Rescorla [ekr@rtfm.com] Sent: Tuesday, February 23, 2016 11:42 PM To: Watson Ladd Cc: tls@ietf.org Subject: Re: [TLS] Remove DH-based 0-RTT On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd > wrote: On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk > wrote: > > > On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett > > wrote: >> >> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: >> > I propose that we remove DH-based 0-RTT from TLS 1.3. >> > >> > As ekr's previous mail noted, the security properties of PSK-based >> > 0-RTT and DH-based 0-RTT are almost identical. And DH-based 0-RTT is >> > much more complex. >> > >> > For those who love DH-based 0-RTT, and I know that some people are >> > fans, here's something that might make you less sad about removing it >> > from the core spec. You can use DH out of band to negotiate a PSK. >> > You might even do this as an extension to TLS, but that's of less >> > value. >> >> I think there is a good argument for moving DH 0RTT into a TLS extension= . >> Implementations that are explicitly not going to use it should not be >> expected to implement it and risk screwing it up. If we accept that prem= ise >> that online DH 0RTT will be unlikely in practice, then we would be >> specifying it at least primarily for out-of-band use, and doing it via a= n >> extension will probably be cleaner and safer. > > > Combining this comment (which I agree with) with the following comment fr= om > Watson in another thread: > >> > If they rely on extensions then either those >> > extensions need to be included in the security proofs, or we need to >> > make clear that they are not as secure as TLS 1.3, and that >> > implementations which enable both of them can get completely wrecked >>in new and exciting ways. > > We get that even if it is decided not to include the DH-based 0-RTT as pa= rt > of mandatory-to-implement TLS 1.3, it should be defined as an extension a= nd > as part of the TLS 1.3 document. Leaving the reduction from this case to = PSK > (as Martin suggested) to popular imagination is too dangerous. By includi= ng > it as part of TLS 1.3 official text we also encourage the groups that are > currently analyzing the protocol to include this specific mechanism in th= eir > analysis. If they find something wrong with it then even more reason to d= o > the analysis. > > >> >> I would still prefer it be defined in the TLS 1.3 specification document= , >> though optional. > > > I suggest to also define TLS 1.3-EZ. > A subset of core safe functionality that should address the majority of t= he > usage cases. I strongly encourage this proposal, and will even massacre the markdown to attempt it. Great. Let's sync up as we get a little closer to done. I also commit to implementing TLS 1.3-EZ in Go, and possibly in C based on Amazon's s2n. (A trustable X509 library in C is still beyond my reach, so that C might be server-only). I believe Richard Barnes has already started something along these lines, so maybe you guys could join forces (not sure how confident he is in it). https://github.com/bifurcation/mint This library currently interoperates with my experimental implementation in NSS. -Ekr > > Hugo > > >> >> >> >> Dave >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_974CF78E8475CD4CA398B1FCA21C8E99564E7F92PRNMBX014TheFac_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Removing DH based 0-RTT would make it more important to make the lif= etime of the ticket enforced. 

One interesting difference is that DH based 0-RTT requires proof of po= ssession of the private key for the client to accept the connection, howeve= r PSK based 0-RTT might not be associated with a certificate at all. Thus t= he only way to prove that the key is still fresh is to limit the time that the PSK is valid and strictly bou= nd that time. Unless we add a way for the client to require a server authen= tication during PSK resumption.

This is relevant in situations where compromise of the ephemeral key does n= ot mean that the long term private key has been compromised like in ssl off= loading type scenarios.

Subodh Iyengar
From: TLS [tls-bounces@ietf.org] on behal= f of Eric Rescorla [ekr@rtfm.com]
Sent: Tuesday, February 23, 2016 11:42 PM
To: Watson Ladd
Cc: tls@ietf.org
Subject: Re: [TLS] Remove DH-based 0-RTT



On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd <watsonbladd@= gmail.com> wrote:
On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk <hugo@ee.technion.ac.i= l> wrote:
>
>
> On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett <davemgarrett@gmail.com>
> wrote:
>>
>> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote: >> > I propose that we remove DH-based 0-RTT from TLS 1.3.
>> >
>> > As ekr's previous mail noted, the security properties of PSK-= based
>> > 0-RTT and DH-based 0-RTT are almost identical.  And DH-b= ased 0-RTT is
>> > much more complex.
>> >
>> > For those who love DH-based 0-RTT, and I know that some peopl= e are
>> > fans, here's something that might make you less sad about rem= oving it
>> > from the core spec.  You can use DH out of band to negot= iate a PSK.
>> > You might even do this as an extension to TLS, but that's of = less
>> > value.
>>
>> I think there is a good argument for moving DH 0RTT into a TLS ext= ension.
>> Implementations that are explicitly not going to use it should not= be
>> expected to implement it and risk screwing it up. If we accept tha= t premise
>> that online DH 0RTT will be unlikely in practice, then we would be=
>> specifying it at least primarily for out-of-band use, and doing it= via an
>> extension will probably be cleaner and safer.
>
>
> Combining this comment (which I agree with) with the following comment= from
> Watson in another thread:
>
>>
>  If they rely on extensions then either those
>>
> extensions need to be included in the security proofs, or we need to >>
> make clear that they are not as secure as TLS 1.3, and that
>>
> implementations which enable both of them can get completely wrecked >>in new and exciting ways.
>
> We get that even if it is decided not to include the DH-based 0-RTT as= part
> of mandatory-to-implement TLS 1.3, it should be defined as an extensio= n and
> as part of the TLS 1.3 document. Leaving the reduction from this case = to PSK
> (as Martin suggested) to popular imagination is too dangerous. By incl= uding
> it as part of TLS 1.3 official text we also encourage the groups that = are
> currently analyzing the protocol to include this specific mechanism in= their
> analysis. If they find something wrong with it then even more reason t= o do
> the analysis.
>
>
>>
>> I would still prefer it be defined in the TLS 1.3 specification do= cument,
>> though optional.
>
>
> I suggest to also define TLS 1.3-EZ.
> A subset of core safe functionality that should address the majority o= f the
> usage cases.

I strongly encourage this proposal, and will even massacre the
markdown to attempt it.

Great. Let's sync up as we get a little closer to done.


I also commit to implementing TLS 1.3-EZ in
Go, and possibly in C based on Amazon's s2n. (A trustable X509 library
in C is still beyond my reach, so that C might be server-only).

I believe Richard Barnes has already started something along these lin= es,
so maybe you guys could join forces (not sure how confident he is in
it).


This library currently interoperates with my experimental implementati= on
in NSS.

-Ekr


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



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

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

--_000_974CF78E8475CD4CA398B1FCA21C8E99564E7F92PRNMBX014TheFac_-- From nobody Wed Feb 24 07:54:30 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B9691ACEF7 for ; Wed, 24 Feb 2016 07:54:29 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejEAfRGxiAX9 for ; Wed, 24 Feb 2016 07:54:28 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 E0AB31A92E4 for ; Wed, 24 Feb 2016 07:54:27 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id g203so47670960iof.2 for ; Wed, 24 Feb 2016 07:54:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Od9Vt1ZjuMkdtrn9+GFbTaBwGCo5oRf7T1ymAq/Yvi8=; b=OSSHQNSMJ9Gd6NmHqyKgvjhZGPfPAmHoy9K3C3XiXp1TS3UssmaFHDXYMMX2pspaW2 b6wAyk8oeJOEbVlaKI0pPAHHG9/mvI03E6WZ9mtj7EA3Renh/6wAeIUMThfhOe/2lq4I zejaPBcN9+eUPXkg2AmIsZ/ESIVh34gDnaBmnuFJ154gN2MKSBTdUMVaZomkGTFmHpmB YJfAf1O4Fvg2GQ3lz4PDi5ENnwqjU1nNcW5NWhrKQ1IcjFjtkAxuiIsCk8el7qvJ53r4 F7OakvV4A39pv3h9x8EssJ4k+brFR2Tn1fo/NuceZ2hPddCu0av8C6CmJSj/nArcjApx 2nog== 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:date :message-id:subject:from:to:cc:content-type; bh=Od9Vt1ZjuMkdtrn9+GFbTaBwGCo5oRf7T1ymAq/Yvi8=; b=U03PSbHt7GMzu5jkK59whgLAT7mM5aTsFvy+AlYViCsTfEJW+5RkH+IMyBw3JQKIaP 574tJhnyN37cV2Ze0grrNgqLbyLP/jzGmGRpofORfKUE/oQviuan6Dlz4fEnUZS2pEQ5 V38f2jLD9RrQW2+A0/+E0YVa9DbFz/Fpx5z4+Z+Wp9eEtLK544VuhwpwJcin0+RMxpST KbwLedRw3U+XdCgtmhjAwcajol59giEblwdPqW8BcpyV/qAoeW2vwKtCYQfTgUl5PzSp c4C9Qs1F1PzSqR9gu4f6O21tzgy9CkXHuqBMVex2rLCfnd+Wz75F1gpeG8Qp9fKH58Sm onpQ== X-Gm-Message-State: AG10YORtMqhk+R8lvjkCHCwtwRwj5RrqmAmK/0nCOnalURbgk6Pcow9ZVtG9wLsr6SQLE+K5jEHBLeE58HVdLw== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr41809460iod.190.1456329267267; Wed, 24 Feb 2016 07:54:27 -0800 (PST) Received: by 10.36.53.79 with HTTP; Wed, 24 Feb 2016 07:54:27 -0800 (PST) In-Reply-To: <974CF78E8475CD4CA398B1FCA21C8E99564E7F92@PRN-MBX01-4.TheFacebook.com> References: <201602232057.18505.davemgarrett@gmail.com> <974CF78E8475CD4CA398B1FCA21C8E99564E7F92@PRN-MBX01-4.TheFacebook.com> Date: Wed, 24 Feb 2016 07:54:27 -0800 Message-ID: From: Martin Thomson To: Subodh Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 15:54:29 -0000 On 24 February 2016 at 07:44, Subodh Iyengar wrote: > Unless we add a way for the client to require a server authentication during > PSK resumption. I have been arguing for this now for a while. If there is an incentive to do "PSK resumption" (there is), and that does not provide the client a way to verify server certificates, then clients are forced to make a choice between performance and checking that the server holds the private key for the certificate. I'd like to see a mode where 0-RTT is grafted on to a full handshake with DHE and signing. Unfortunately, that gives us an almost full matrix of options: PSK only PSK + DHE PSK + DHE + signing DHE + signing But at least we can remove "DH0RTT + DHE + signing" and maybe other combinations (though which ones we have currently isn't 100% clear to me). From nobody Wed Feb 24 08:34:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A0F1B38A6 for ; Wed, 24 Feb 2016 08:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=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 czIIJ09S7cCg for ; Wed, 24 Feb 2016 08:34:25 -0800 (PST) Received: from mail-yk0-x22f.google.com (mail-yk0-x22f.google.com [IPv6:2607:f8b0:4002:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE8A1B38A3 for ; Wed, 24 Feb 2016 08:34:25 -0800 (PST) Received: by mail-yk0-x22f.google.com with SMTP id r207so10148676ykd.2 for ; Wed, 24 Feb 2016 08:34:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=fu8q+AffX5U2473+jYZOxPk3Wrn6qoYnDZaXcgvb43Y=; b=BRy8MKCc55wvTPwhI4a0RG3a9/qY02V/2UCBED2X8qqzCROqdWc5N6GuegyQjtq6M6 QgBBmtYlEpIJaOfnjXzCEPgg8mVcfIcGRzwbLOGdBIKlCMJ7lbOnhyt4A63gzpr8LfHL 9WbTuOIokkqvcZmnTeL75k0rj9RkSbpA+upWDkO33AXyrDHHtnrSJdjiUHIlE1fA+x5R rLQPXuG2auwuz61D6/jYkTZDWQqogAHFE/GsvJ8wtN9TWJNsFJpPWIytrJ4PvM2wC/v+ QltPzXlUa+CpNMsPkCblL0d8J1a8KFbNNQXf1R7+r+xpHcMRLIBhVETtaBEAfQFdkCA6 DLrg== 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:date :message-id:subject:from:to:cc:content-type; bh=fu8q+AffX5U2473+jYZOxPk3Wrn6qoYnDZaXcgvb43Y=; b=EYIzOTKVTGq+6vXvZvxKPy2uqySOfUrx+A9w3OVu28/GuwEBsWOjzFbut2O4SnEUvS LjiCB7bPi6QPIYB3s2yOHa4zDZyZNK/0OD2lyOrLyGibwQ2jbG6YnA2fTZ3MFUKlm/DZ 6IUt8BvGR4POD08ggZZTBOkLAd31N1YyBbP80T6xn6YWrTwmZ8QUK0GUJ8C+p/jWZDz5 EbD5XvCKf0aJVMMma3MVUKQgU66JEq7xmDwM5F+/7xjhZEOvxRryTn1PyOQlfnHD2Rz6 pBaNwE358kv6xw1hFTQ2TDgD4EYvcWiJ6S8ffvas5TlRg/ASFOeHub9bh3sQAfUXt8XE sBbg== X-Gm-Message-State: AG10YOTSzAZEuhGfvSENF64VIWv++F7QHuf9St9R1Gn8G6i9sLZym3AwjmnPUJn3GW3Z1uuLas3/oP33tneQxQ== MIME-Version: 1.0 X-Received: by 10.37.25.212 with SMTP id 203mr20368328ybz.163.1456331664655; Wed, 24 Feb 2016 08:34:24 -0800 (PST) Received: by 10.13.216.138 with HTTP; Wed, 24 Feb 2016 08:34:24 -0800 (PST) In-Reply-To: References: <201602232057.18505.davemgarrett@gmail.com> <974CF78E8475CD4CA398B1FCA21C8E99564E7F92@PRN-MBX01-4.TheFacebook.com> Date: Wed, 24 Feb 2016 08:34:24 -0800 Message-ID: From: Watson Ladd To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 16:34:26 -0000 On Wed, Feb 24, 2016 at 7:54 AM, Martin Thomson wrote: > On 24 February 2016 at 07:44, Subodh Iyengar wrote: >> Unless we add a way for the client to require a server authentication during >> PSK resumption. > > I have been arguing for this now for a while. If there is an > incentive to do "PSK resumption" (there is), and that does not provide > the client a way to verify server certificates, then clients are > forced to make a choice between performance and checking that the > server holds the private key for the certificate. I'd like to see a > mode where 0-RTT is grafted on to a full handshake with DHE and > signing. Unfortunately, that gives us an almost full matrix of > options: Part of the motivation for session tickets in the first place was the cost of signing and DH. So long as servers can negotiate a resumption mode without these, and clients offer it, there is no liveness check. And if we require a DH+sign every resumption, we don't gain anything over the full exchange except 0-RTT. Why is this server liveness issue not considered a problem for TLS 1.2 resumption? > > PSK only > PSK + DHE > PSK + DHE + signing > DHE + signing > > But at least we can remove "DH0RTT + DHE + signing" and maybe other > combinations (though which ones we have currently isn't 100% clear to > me). -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Wed Feb 24 09:04:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7BC1B3592 for ; Wed, 24 Feb 2016 09:04:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=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 jfSIKWVXB-3l for ; Wed, 24 Feb 2016 09:04:49 -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 0F8091A89FC for ; Wed, 24 Feb 2016 09:04:45 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id 9so49092336iom.1 for ; Wed, 24 Feb 2016 09:04:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=MsjPo3P14t5jUQvTqgWi/5Z/QdpAoVBD1jVpGXROMdE=; b=iLZ0oOzbdBpickxfiNO/o/xUR44oY6whv2hRQ3Hse2Qrqkol0sZ8iHNNbcCSwaE8lG Eiiuc/Bk906Es/zo5m4Yyn2PZuSCZiSTghT6aUJHs84G1IZn98euzsYff3AyW7B1XW9X QMsvAybkc5aUDOId5skELyOUveE5cXWiQEBhq2k4zzNIGOrioo8qP+gU3npvPKXa8BLM llHF/WRINcP1gtT/xa+DAooFOD+iNlHCOjvBEE8u4E7xF6SoJa38SWjOKtH+VSOnWNqr EFnLcBhpc5vO/+Wkfimfd6jjfHG/6vsB+B3Niq+5VKypeDsG2Ft7DEssZwDuOTi9kyWX wRjg== 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:date :message-id:subject:from:to:cc:content-type; bh=MsjPo3P14t5jUQvTqgWi/5Z/QdpAoVBD1jVpGXROMdE=; b=m5WXH24Xa5JxfbcXF/KuUqbhRRDNUpO9C6mZqYIMs8+d9dvxaQushbFMbXcHyhUN+C 5X/d3+pfnV/1KJLYgaIbegrGE4zoJfPzwaczKnkIYy/IWyIPe3itGnr283b5Sq6rksOb jzQD2k9a1z6BTs6JJEQcy3PEJLalisSwLM+TYrJ1BFMNRCZZsA5qG/nlLymf4BC8ZgIa 58kyxtMGodHwzKvUMcnkUWYccCoV4yIcACvOdYiQ7UM87LSIzTd2THAUabSkWuV3bWa2 zYRCnm7aQoX3tBDWAL4kjukSi9hcN4M1zJiQBGSJLXsBxrSJtzynAUNP7lWIEihisw9L L+hQ== X-Gm-Message-State: AG10YOSMnlDnCjT8jczgxQx8qS2oVMJWkfyvxPGrqnAf4zU655yelVmopv80unxMH6UhyusoJ47TNEUqpoUZKA== MIME-Version: 1.0 X-Received: by 10.50.180.35 with SMTP id dl3mr11985964igc.94.1456333479595; Wed, 24 Feb 2016 09:04:39 -0800 (PST) Received: by 10.36.53.79 with HTTP; Wed, 24 Feb 2016 09:04:39 -0800 (PST) In-Reply-To: References: <201602232057.18505.davemgarrett@gmail.com> <974CF78E8475CD4CA398B1FCA21C8E99564E7F92@PRN-MBX01-4.TheFacebook.com> Date: Wed, 24 Feb 2016 09:04:39 -0800 Message-ID: From: Martin Thomson To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 17:04:50 -0000 On 24 February 2016 at 08:34, Watson Ladd wrote: > And if we require a DH+sign every resumption, we don't gain anything > over the full exchange except 0-RTT. Why is this server liveness issue > not considered a problem for TLS 1.2 resumption? It wouldn't be a requirement, merely an option. In 1.2, resumption and false start have the same latency profile. Here, resumption will be faster. From nobody Wed Feb 24 10:00:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C67E1B3AD1 for ; Wed, 24 Feb 2016 10:00:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wf64TlDzXJNc for ; Wed, 24 Feb 2016 10:00:52 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 415A21B354F for ; Wed, 24 Feb 2016 10:00:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 251C29BE; Wed, 24 Feb 2016 20:00:50 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id HHybc8F0MKNj; Wed, 24 Feb 2016 20:00:49 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DE0D821C; Wed, 24 Feb 2016 20:00:49 +0200 (EET) Date: Wed, 24 Feb 2016 20:00:45 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160224180045.GA28926@LK-Perkele-V2.elisa-laajakaista.fi> References: <201602232057.18505.davemgarrett@gmail.com> <974CF78E8475CD4CA398B1FCA21C8E99564E7F92@PRN-MBX01-4.TheFacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 18:00:54 -0000 On Wed, Feb 24, 2016 at 07:54:27AM -0800, Martin Thomson wrote: > PSK + DHE + signing Be careful with that: One can get server impersonation attacks unless one somehow binds the SS into signature (and unlike with client sigs, there is no straightforward way). -Ilari From nobody Wed Feb 24 10:08:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B311AD2A9 for ; Wed, 24 Feb 2016 10:08:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NVq2GNkwMeX0 for ; Wed, 24 Feb 2016 10:08:07 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::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 2269E1AC3B8 for ; Wed, 24 Feb 2016 10:08:07 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id g203so55871020iof.2 for ; Wed, 24 Feb 2016 10:08:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XLfNusmRmg66n7ZD5DTHwz7QmnLXufND1XEO2Q4GPrU=; b=ZN2wLu+uLMDZnLYGbjJhCWjcXkVRRzqOlujtGFaJGRErptKeKShY4KjpEtCDV4KZOY rvRlsg4mablVYjgY93zuiKzJoOdKOaUhORqc+jbBq/Cu0wk5vEtxbKvf0kw/7jsCoArf m3VmZe7WJV2ZP37CH6p9i5+OkB1IOtmUNYFhZsboVpRHq/uu0M07GeDFPiZisSY+SiOV AcESYLjsMN2JAi5MKO3xmgkhzeI9wOPFAEciOwJko3h6krbrNBw0ymiiylYrc73Zi1Mh L2dOSxnzHSWHVGUvXLJWriHPwkDsKghGLOtboTq/R1ZkK0NvagSNmWjsR//bXUk+cwUG p9hg== 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:date :message-id:subject:from:to:cc:content-type; bh=XLfNusmRmg66n7ZD5DTHwz7QmnLXufND1XEO2Q4GPrU=; b=USuLQmvQK1m3E/Opy+1rLTSh5C578aScnHG01P5/OfVP3NLCnzZcwDyiJhHqvblfeA 7MwENjyXoh9zAMmZjQozg5guwMkoWvXj+badm53briISvJaJnqaCahDZIQD89mLQSCrF Bb8xedms4Q5AOtT86l8FLs5QPTpSl2lwu5bu1rVuJxfOg5XuyJ7NHrZCUgn0fJq9yiiK E5TGXrL0GxMoGBCONLAFQ25/Ezgc/Ukz/uKyNCSrIjHgsFHzI+UOxO4wjm30KgDIph5F ZwKU2/yD0IpYfFPgU00eVqSD28tgYx8zxto85HHOzPEXARGkIPN/3E4cqYOzchEC7ymd Lngg== X-Gm-Message-State: AG10YOR+3scFUpzm9F5qzbCAhsz1WsXAxudZtySY/ZYYvdZyIDwQYVxYWsELWO2iKcuiY96eswIOgFl9ZEnvaw== MIME-Version: 1.0 X-Received: by 10.107.41.133 with SMTP id p127mr28411773iop.100.1456337282628; Wed, 24 Feb 2016 10:08:02 -0800 (PST) Received: by 10.36.53.79 with HTTP; Wed, 24 Feb 2016 10:08:02 -0800 (PST) In-Reply-To: <20160224180045.GA28926@LK-Perkele-V2.elisa-laajakaista.fi> References: <201602232057.18505.davemgarrett@gmail.com> <974CF78E8475CD4CA398B1FCA21C8E99564E7F92@PRN-MBX01-4.TheFacebook.com> <20160224180045.GA28926@LK-Perkele-V2.elisa-laajakaista.fi> Date: Wed, 24 Feb 2016 10:08:02 -0800 Message-ID: From: Martin Thomson To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 18:08:09 -0000 On 24 February 2016 at 10:00, Ilari Liusvaara wrote: > Be careful with that: One can get server impersonation attacks unless > one somehow binds the SS into signature (and unlike with client sigs, > there is no straightforward way). The key schedule, in every variation I've seen proposed, does that. From nobody Wed Feb 24 10:14:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6525F1B34C1 for ; Wed, 24 Feb 2016 10:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cFrmboakyNRk for ; Wed, 24 Feb 2016 10:14:57 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id E31BB1B2CD4 for ; Wed, 24 Feb 2016 10:14:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 757E1597; Wed, 24 Feb 2016 20:14:55 +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 JAmrvQPjfyr0; Wed, 24 Feb 2016 20:14:55 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1EA292316; Wed, 24 Feb 2016 20:14:55 +0200 (EET) Date: Wed, 24 Feb 2016 20:14:51 +0200 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20160224181450.GB28926@LK-Perkele-V2.elisa-laajakaista.fi> References: <201602232057.18505.davemgarrett@gmail.com> <974CF78E8475CD4CA398B1FCA21C8E99564E7F92@PRN-MBX01-4.TheFacebook.com> <20160224180045.GA28926@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 18:14:58 -0000 On Wed, Feb 24, 2016 at 10:08:02AM -0800, Martin Thomson wrote: > On 24 February 2016 at 10:00, Ilari Liusvaara wrote: > > Be careful with that: One can get server impersonation attacks unless > > one somehow binds the SS into signature (and unlike with client sigs, > > there is no straightforward way). > > The key schedule, in every variation I've seen proposed, does that. The server signature is essentially over raw handshake messages, up to and including ServerCertificate. The first message that would depend on actual value of SS is ServerFinished, which comes after that point... -Ilari From nobody Wed Feb 24 11:31:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D59E1B3D7C for ; Wed, 24 Feb 2016 11:31:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.706 X-Spam-Level: X-Spam-Status: No, score=-2.706 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEu0HSMStfdW for ; Wed, 24 Feb 2016 11:31:45 -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 D99E41B2E03 for ; Wed, 24 Feb 2016 11:31:43 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D9E3D4237B6; Wed, 24 Feb 2016 19:31:42 +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 C3D2F423798; Wed, 24 Feb 2016 19:31:42 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456342302; bh=VLsBsZCsYhiytQcb8A4VKVYVuVi61LJ6m6qZvChA+Yg=; l=2953; h=To:References:From:Date:In-Reply-To:From; b=RSf1xbWbDcdAl3597XdYFk9wncLJwVbFgJxEOHqDGZ4F022K2p0khvHKFbqdFJ75T 4ffYvrpK9U25O+2m1+rbsXvpnMdwOHpnf5HxB6wWOtxKrvyiemW7uzx/RhphF3WDJg oaXuE1TMMxL5iFhWL99w8KOlHOOK4QLRG5A6BFtk= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 9A30C1FC8E; Wed, 24 Feb 2016 19:31:42 +0000 (GMT) To: Yaron Sheffer , tls@ietf.org References: <20160206202554.8543.90496.idtracker@ietfa.amsl.com> <56B65966.3020005@gmail.com> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: <56CE051E.5020604@akamai.com> Date: Wed, 24 Feb 2016 13:31:42 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56B65966.3020005@gmail.com> Content-Type: multipart/alternative; boundary="------------050103060407050005080305" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-sheffer-tls-pinning-ticket-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 19:31:47 -0000 This is a multi-part message in MIME format. --------------050103060407050005080305 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 02/06/2016 02:36 PM, Yaron Sheffer wrote: > The draft describes using an opaque ticket (similar to a session > resumption ticket) to pin the identity of a TLS server. The new > version addresses several comments on this list, in particular > regarding the message syntax, and requesting a comparison with TACK - > thanks Dave and Daniel. I only skimmed, but a couple things stood out: "bricking" is kind of an informal term I usually think of "identity" as being some concrete thing that can be named, so that when it says "identity pinning", I expected there to be some name or similar concrete identifier. It seems to me that what is going on is really that this is a scheme to ensure that subsequent communications are talking to the same entity by proof-of-possession of a token/key exchanged on the first communication, but that token does not contain any particular nameable entity. It seems that rewording the entire document in such a fashion would be pretty tedious and result in somewhat more stilted language, though, so I'm hesitant to recommend that course of action. -Ben --------------050103060407050005080305 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 02/06/2016 02:36 PM, Yaron Sheffer wrote:
The draft describes using an opaque ticket (similar to a session resumption ticket) to pin the identity of a TLS server. The new version addresses several comments on this list, in particular regarding the message syntax, and requesting a comparison with TACK - thanks Dave and Daniel.

I only skimmed, but a couple things stood out:

"bricking" is kind of an informal term

I usually think of "identity" as being some concrete thing that can be named, so that when it says "identity pinning", I expected there to be some name or similar concrete identifier.  It seems to me that what is going on is really that this is a scheme to ensure that subsequent communications are talking to the same entity by proof-of-possession of a token/key exchanged on the first communication, but that token does not contain any particular nameable entity.  It seems that rewording the entire document in such a fashion would be pretty tedious and result in somewhat more stilted language, though, so I'm hesitant to recommend that course of action.

-Ben
--------------050103060407050005080305-- From nobody Wed Feb 24 11:41:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A6A1A8883 for ; Wed, 24 Feb 2016 11:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EpC84395Oxm3 for ; Wed, 24 Feb 2016 11:41:18 -0800 (PST) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0759.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:759]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BDD31B3E1F for ; Wed, 24 Feb 2016 11:40:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=o4Ie6JaW+aGUGWrlwqPuzQ/F2I6rSNWAkIvYyFI6yOo=; b=maHnUOPeaEBrHoX51hA+Pw1sjgekRcSqTCiQPkN+P/efZwpnsjil1V5W43XamKkp2uYZ8qRjrTRspDlFAlG4N+FadhQXpqB/WqHHABj7T9PK5wHWb+TcgkeuQv5fCyr0qIC7eW9Bd1QijSmIXQd3B43rihp6fl4ntluML74rcsc= Received: from BLUPR03MB1396.namprd03.prod.outlook.com (10.163.81.142) by BLUPR03MB1395.namprd03.prod.outlook.com (10.163.81.141) with Microsoft SMTP Server (TLS) id 15.1.409.15; Wed, 24 Feb 2016 19:40:37 +0000 Received: from BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) by BLUPR03MB1396.namprd03.prod.outlook.com ([10.163.81.142]) with mapi id 15.01.0409.024; Wed, 24 Feb 2016 19:40:37 +0000 From: Andrei Popov To: =JeffH , Ilari Liusvaara Thread-Topic: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ? Thread-Index: AQHRbpq2w7vtZL/adUqDXJhUT+elNJ87lZNg Date: Wed, 24 Feb 2016 19:40:36 +0000 Message-ID: References: <56CCF9C8.1060905@KingsMountain.com> In-Reply-To: <56CCF9C8.1060905@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: KingsMountain.com; dkim=none (message not signed) header.d=none;KingsMountain.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:3::1d2] x-ms-office365-filtering-correlation-id: c4dfc7cc-b11e-47f1-dbc0-08d33d525eb0 x-microsoft-exchange-diagnostics: 1; BLUPR03MB1395; 5:wU2nLSHZizHztfMSZWr2sJhbitutJbdW0I60HMbcaDj/U1zJn1POHjfHXHWUg2LZalVVcu5Jleys7xPVGZpcMjH94vZa75zhnWueZhEmi+Q4d+tBnadNtrv/OHTus9rLFB/ES3CM/i9VBpU2LqBYeg==; 24:+w1wsSP5IcR3dGeag9K5akPXQiQHxc8uRdIAO+59/w97e++yevBHzj5eh57WG3MdVeDCmBxvC83VgKAv1X5TpT1V22QZgtSbpOktisSLEWE= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR03MB1395; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(61426038)(61427038); SRVR:BLUPR03MB1395; BCL:0; PCL:0; RULEID:; SRVR:BLUPR03MB1395; x-forefront-prvs: 08626BE3A5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(377454003)(24454002)(102836003)(586003)(6116002)(1096002)(33656002)(1220700001)(8990500004)(5005710100001)(10400500002)(10290500002)(5004730100002)(5008740100001)(2900100001)(5002640100001)(2906002)(2950100001)(5001770100001)(19580405001)(4326007)(15975445007)(92566002)(189998001)(74316001)(3280700002)(77096005)(5003600100002)(19580395003)(5001960100002)(86612001)(40100003)(76576001)(87936001)(122556002)(10090500001)(106116001)(11100500001)(99286002)(50986999)(54356999)(86362001)(76176999)(3660700001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB1395; H:BLUPR03MB1396.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 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: 24 Feb 2016 19:40:37.2289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR03MB1395 Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 19:41:22 -0000 Hi Jeff, Tls13-11 I-D is not very clear on this, but my reading is that exporter_sec= ret is the TLS 1.3 version of the Keying Material Exporters. If this is cor= rect, then there are two pieces currently missing: the ability to specify a= custom label and the ability to mix in application context. I don't know w= here this should live; perhaps RFC 5705 will need to be updated once TLS 1.= 3 is sufficiently baked. I also presume that exporter_secret (or a similar construction defined in t= he updated RFC 5705) will become the recommended replacement for tls-unique= . The 1.3 key schedule appears to be under discussion, so things might chan= ge. Cheers, Andrei =20 -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of =3DJeffH Sent: Tuesday, February 23, 2016 4:31 PM To: Ilari Liusvaara Cc: IETF TLS WG Subject: Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applica= ble to TLS 1.3 ? Hi Ilari, Ilari replied on Wed, 17 Feb 2016: > On Wed, Feb 17, 2016 at 11:25:12AM -0800, =3DJeffH wrote: >> Hi, >> >> RFC5705 section 4 "Exporter Definition" [1] states.. >> >> The exporter takes three input values: >> >> o a disambiguating label string, >> >> o a per-association context value provided by the application using >> the exporter, and >> >> o a length value. >> >> If no context is provided, it then computes: >> >> PRF(... >> )[length] >> >> If context is provided, it computes: >> >> PRF(... >> )[length] >> >> >> ..i.e., RFC5705 directly utilizes the TLS PRF (pseudo-random function) = >> from TLS {1.0, 1.1, 1.3}. Since the PRF() is no longer defined in TLS = >> 1.3, RFC5705 is incompatible with TLS 1.3, yes? [...the above question remains unanswered...] >> >> Also, draft-ietf-tls-tls13-11 seems to contain a built-in keying materi= al >> exporter (KME) in S 7.1 step 8 [2].. >> >> 7.1. Key Schedule >> >> [...] >> >> 8. exporter_secret =3D HKDF-Expand-Label(master_secret, >> "exporter master secret", >> handshake_hash, L) >> [...] >> >> >> ..i.e., does the above step "8." effectively define the TLS 1.3 keying = >> material exporter? >> > > Well, it isn't clear to me what TLS 1.3 exporters should do. Presumably = > the "master secret" used for calculations is exporter_secret. agreed -- that is what is being referred to in various msgs on the list as = "EMS" (exporter master secret?) ? > However, just replacing the PRF in definition with the standard TLS 1.3 > PRF (HKDF) would leave those exporters using randoms, which aren't > explicitly used anywhere in TLS 1.3. hm, I'm not sure I understand. back on 8-Oct you mused on the below [1].. One idea for TLS-unique for TLS 1.3: Invoke TLS-EXPORTER with: label: "TLS 1.3 tls-unqiue" context: No context Length: 256 And define TLS-EXPORTER for TLS 1.3 as (this looks ugly, have some better way at handling both context and no context cases? In original RFC, those were different): tmp =3D HKDF-Extract(label, exporter_secret) output =3D HKDF-Expand(tmp, 0x01 | context, L) or (no context case) tmp =3D HKDF-Extract(label, exporter_secret) output =3D HKDF-Expand(tmp, , L) ..where "output" would apparently be the Exported Keying Material value,=20 which seems plausible (modulo refining the Label). So I'm not sure=20 where/what you meant by "using randoms" above... exporter_secret is not a=20 "random", yes? =3DJeffH [1] https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.= ietf.org%2fmail-archive%2fweb%2ftls%2fcurrent%2fmsg17924.html&data=3D01%7c0= 1%7cAndrei.Popov%40microsoft.com%7c92109063b8904679be8f08d33cb1d6b8%7c72f98= 8bf86f141af91ab2d7cd011db47%7c1&sdata=3D8kyi1lG2n6i4M40Uo2p%2bwA%2fi7in%2by= 1TcgiZcwZbXiIY%3d _______________________________________________ TLS mailing list TLS@ietf.org https://na01.safelinks.protection.outlook.com/?url=3Dhttps%3a%2f%2fwww.ietf= .org%2fmailman%2flistinfo%2ftls&data=3D01%7c01%7cAndrei.Popov%40microsoft.c= om%7c92109063b8904679be8f08d33cb1d6b8%7c72f988bf86f141af91ab2d7cd011db47%7c= 1&sdata=3D24nM3SyRy4yzg3lznrwYx5ECzf3ZkJqkRcYWQwlJn20%3d From nobody Wed Feb 24 13:00:49 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89EAF1B2DB2 for ; Wed, 24 Feb 2016 13:00:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.667 X-Spam-Level: X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 iMrbmPLCiM6o for ; Wed, 24 Feb 2016 13:00:46 -0800 (PST) Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) by ietfa.amsl.com (Postfix) with SMTP id 7A4021B3F40 for ; Wed, 24 Feb 2016 13:00:46 -0800 (PST) Received: (qmail 16300 invoked by uid 0); 24 Feb 2016 21:00:46 -0000 Received: from unknown (HELO cmgw2) (10.0.90.83) by gproxy2.mail.unifiedlayer.com with SMTP; 24 Feb 2016 21:00:46 -0000 Received: from box514.bluehost.com ([74.220.219.114]) by cmgw2 with id NM0g1s01P2UhLwi01M0j3q; Wed, 24 Feb 2016 14:00:44 -0700 X-Authority-Analysis: v=2.1 cv=PPOcp5aC c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=48vgC7mUAAAA:8 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=o8x0CelELPUA:10 a=jFJIQSaiL_oA:10 a=WlxsqyjbAAAA:8 a=UqCG9HQmAAAA:8 a=yMhMjlubAAAA:8 a=YQ246BAETzN11YYJCgwA:9 a=WcVKV2y--jPWfSvT:21 a=FOOxSty1iXvg7TnK:21 a=QEXdDO2ut3YA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Cc:Subject:From:To; bh=NpS/gybR4StDbTia6keIY2w7hUtc91HggS7wBHyUf2Y=; b=Tdt5CZDsIIRhCaCJdZz4Kyjs2iCrGM+ymSOU+YGhSV0aWhS1pPRgadE6eK9eLXS4CXSIawlDu6BFclpBTIdz16ARlzbSNB5R2s0x7kIi+Om2qQD/cRxn5I8ziJ1M4cq0; Received: from [70.213.12.105] (port=6577 helo=[10.0.0.1]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from ) id 1aYgY6-0002hO-IX; Wed, 24 Feb 2016 14:00:42 -0700 To: Andrei Popov From: =JeffH Message-ID: <56CE19F5.2050101@KingsMountain.com> Date: Wed, 24 Feb 2016 13:00:37 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 70.213.12.105 authed with jeff.hodges+kingsmountain.com} Archived-At: Cc: IETF TLS WG Subject: [TLS] IETF TLS WG X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:00:48 -0000 > Tls13-11 I-D is not very clear on this, but my reading is that > exporter_secret is the TLS 1.3 version of the Keying Material Exporters. > If this is correct, then there are two pieces currently missing: the > ability to specify a custom label and the ability to mix in application > context. I don't know where this should live; perhaps RFC 5705 will need > to be updated once TLS 1.3 is sufficiently baked. > > I also presume that exporter_secret (or a similar construction defined > in the updated RFC 5705) will become the recommended replacement for > tls-unique. The 1.3 key schedule appears to be under discussion, so > things might change. Thanks Andrei, the above confirms my own assessment/suspicions. =JeffH > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of =JeffH > Sent: Tuesday, February 23, 2016 4:31 PM > To: Ilari Liusvaara > Cc: IETF TLS WG > Subject: Re: [TLS] RFC5705 Keying Material Exporters for TLS -- not applicable to TLS 1.3 ? > > Hi Ilari, > > Ilari replied on Wed, 17 Feb 2016: > > On Wed, Feb 17, 2016 at 11:25:12AM -0800, =JeffH wrote: > >> Hi, > >> > >> RFC5705 section 4 "Exporter Definition" [1] states.. > >> > >> The exporter takes three input values: > >> > >> o a disambiguating label string, > >> > >> o a per-association context value provided by the application using > >> the exporter, and > >> > >> o a length value. > >> > >> If no context is provided, it then computes: > >> > >> PRF(... > >> )[length] > >> > >> If context is provided, it computes: > >> > >> PRF(... > >> )[length] > >> > >> > >> ..i.e., RFC5705 directly utilizes the TLS PRF (pseudo-random function) >> from TLS {1.0, 1.1, 1.3}. Since the PRF() is no longer defined in TLS >> 1.3, RFC5705 is incompatible with TLS 1.3, yes? > > [...the above question remains unanswered...] > > >> > >> Also, draft-ietf-tls-tls13-11 seems to contain a built-in keying material >> exporter (KME) in S 7.1 step 8 [2].. > >> > >> 7.1. Key Schedule > >> > >> [...] > >> > >> 8. exporter_secret = HKDF-Expand-Label(master_secret, > >> "exporter master secret", > >> handshake_hash, L) > >> [...] > >> > >> > >> ..i.e., does the above step "8." effectively define the TLS 1.3 keying >> material exporter? > >> > > > > Well, it isn't clear to me what TLS 1.3 exporters should do. Presumably > the "master secret" used for calculations is exporter_secret. > > agreed -- that is what is being referred to in various msgs on the list as "EMS" (exporter master secret?) ? > > > > However, just replacing the PRF in definition with the standard TLS 1.3 > > PRF (HKDF) would leave those exporters using randoms, which aren't > > explicitly used anywhere in TLS 1.3. > > hm, I'm not sure I understand. > > back on 8-Oct you mused on the below [1].. > > One idea for TLS-unique for TLS 1.3: Invoke TLS-EXPORTER with: > > label: "TLS 1.3 tls-unqiue" > context: No context > Length: 256 > > And define TLS-EXPORTER for TLS 1.3 as (this looks ugly, have some > better way at handling both context and no context cases? In original > RFC, those were different): > > tmp = HKDF-Extract(label, exporter_secret) > output = HKDF-Expand(tmp, 0x01 | context, L) > > or (no context case) > > tmp = HKDF-Extract(label, exporter_secret) > output = HKDF-Expand(tmp, , L) > > > ..where "output" would apparently be the Exported Keying Material value, > which seems plausible (modulo refining the Label). So I'm not sure > where/what you meant by "using randoms" above... exporter_secret is not a > "random", yes? > > =JeffH > > [1] https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmail-archive%2fweb%2ftls%2fcurrent%2fmsg17924.html&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c92109063b8904679be8f08d33cb1d6b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=8kyi1lG2n6i4M40Uo2p%2bwA%2fi7in%2by1TcgiZcwZbXiIY%3d > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2ftls&data=01%7c01%7cAndrei.Popov%40microsoft.com%7c92109063b8904679be8f08d33cb1d6b8%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=24nM3SyRy4yzg3lznrwYx5ECzf3ZkJqkRcYWQwlJn20%3d > > From nobody Wed Feb 24 13:53:26 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9E11B30B1 for ; Wed, 24 Feb 2016 13:53:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz0EmwJjbLX9 for ; Wed, 24 Feb 2016 13:53:23 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401051A6F45 for ; Wed, 24 Feb 2016 13:53:23 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id g62so2227434wme.0 for ; Wed, 24 Feb 2016 13:53:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=azet.org; s=gmail; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=s1hgHjLGqqxANpYeChadG2oYuJuIv1bgbNAtgGqaloM=; b=bby029mlVBCKwpuepV8dSKRG/FkfSLWHXBOnlhg3N9kLyOFO2RLM7jNvt3oTszHXna q7sa8bQsXH6KpsHvYmQLLO1FykcICXX3q1h31K7AFpq1TowWole65bHS1YHi8wjjttOB rpvczsTtlBwM0BWjpvFbD7jzMdOcnRATH2/2g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=s1hgHjLGqqxANpYeChadG2oYuJuIv1bgbNAtgGqaloM=; b=iMxLUn86dHRUxNrZ04CMZd5L3L7v5upqvFynpUh1t8oW9I1xtNSvtiZhI3AuvYLqEZ bLjltSyejkdcq/4fa+bVXS8GRU7RdYqUASguPlTOXbBMqf+Y0yO1792U6/PT7lXwMpSb oI5IcJEApuF+d2lGAQlOmyZjBZKGN6+eIpSav+Qq3h6s6WtYmIra6lz5+tw1y9NJjgCy cpjt1CQubEVb883BhX6zZV2E7I7UBCNrFnCtnKdKAjWphTPARe1d/iRhjK4l2Ru4TaP9 f0A1ywN2Wwct9vtgmd8wY52w5nYXqO2fQ27V1D7LptmnHicnknKrsOBw/i+GS/2/wuNA bxkg== X-Gm-Message-State: AG10YORjPDfagWKFGENqUJbY7opcNjZgRaoCdLvaKKy462mxiJTbwnHe/L9lzZwNCxhnaw== X-Received: by 10.28.48.137 with SMTP id w131mr125758wmw.73.1456350801795; Wed, 24 Feb 2016 13:53:21 -0800 (PST) Received: from aarons-macbook.home.azet.org (chello080108049181.14.11.vie.surfer.at. [80.108.49.181]) by smtp.gmail.com with ESMTPSA id t205sm136794wmt.23.2016.02.24.13.53.19 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 24 Feb 2016 13:53:20 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D318FC67-4335-4FC0-99E1-7A50D90A2A3B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.6b2 From: Aaron Zauner In-Reply-To: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 24 Feb 2016 22:53:17 +0100 Message-Id: <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:53:25 -0000 --Apple-Mail=_D318FC67-4335-4FC0-99E1-7A50D90A2A3B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 23 Feb 2016, at 16:34, Salz, Rich wrote: >=20 > Is anyone using SRP with TLS? The OpenSSL implementation in = particular? >=20 I have been in the past and know of some installations and customers = that actually use it. Although the lack of modern cipher-suites for SRP makes it not very = attractive these days. Aaron --Apple-Mail=_D318FC67-4335-4FC0-99E1-7A50D90A2A3B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJWziZOAAoJEOTbZJL9ubXVFwMP/1SWW5PvEIVqg5rBpav3rKwx +HXIj0lLKZcGh7rIWrP/KuhSdBmrAs5h1xjYUOgXM9rMW6YV5vrvejnPCjtQ525+ bG6LJuJJNNTWsj9UqukABBIk4W0soCg7NlLC9Sr2r1sY0E6/ve6t/PE2MnlKpzGj OgQee3T4z2ge9E9diHoiPhDrXAttoVN8vP/tfDQrqiZEjXtY+7ERA1XpAlGGEv7+ dA9zO0BipfEpaDUqfITOPB9pRf+vEauMVu4Z017c+YyOg05tOA/9/FfGO6YDQz9y MSn3vpfQeM/eNE3q1aT1emg/AoTseT+xXQgbNfECbAK5FlxsJ/CB5pp6FIN9Gl1s EmCjh5tTY7qgw8Ohowll2/sqmkpmpzrDycO9KT9hs+/hM2ZIq5WtVByKjNuqzT5v hx3CeBcrbYdhumy63vusfjtjScnsL+fwldpG4XXWAQjfgr6DqD42EzgAtp+NMMOD TYDGded+Fa/YujI62DZv1Syy3dv+dmwo+yYF7/mm5TzXmrBOtrPgStyeOL7XvmkV aCVUlyp1Ih7zQQJ6rGUB0f3T0mNM2sw8UAeRKNScYWJg8IRxWFCtfRP4Wp4Zrouu vGboBf7PxdHegEPOtHM1U0DUcZuFW53+tL4qaAEOUxFXi0D+U+ihEO7suUo0b+tH 5LlRc2x1NeKJbBvHbSVa =XrOn -----END PGP SIGNATURE----- --Apple-Mail=_D318FC67-4335-4FC0-99E1-7A50D90A2A3B-- From nobody Wed Feb 24 13:54:22 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22BC91B4031 for ; Wed, 24 Feb 2016 13:54:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.201 X-Spam-Level: X-Spam-Status: No, score=-1.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=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 nFGi1xxDSJ9j for ; Wed, 24 Feb 2016 13:54:19 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id D17521B3FEB for ; Wed, 24 Feb 2016 13:54:19 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 37C0116BFA6; Wed, 24 Feb 2016 21:54:19 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 219FC16BE1B; Wed, 24 Feb 2016 21:54:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456350859; bh=+uRH7SAFS6sgUKdtc2x7kvKhruhb+wnIR1V63N+qdfc=; l=160; h=From:To:CC:Date:References:In-Reply-To:From; b=rKOi/I+6sd+iXMzjHottb1AhsLcKbG21Myt9DrBbVf4XWrFuXjwNI/RzOKjjR/1s1 6uSCntUZKeryVa33EVz6UHKDmLffSP3d9qRs71FLQDPAc3a4hfkvrc0U2Py/I3dq8K 9S9y8D/mH7x1WGxCgEi+9Ax0CyDvxpi/sFNjLyqU= Received: from email.msg.corp.akamai.com (ustx2ex-cas4.msg.corp.akamai.com [172.27.25.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 1EEFA1E07C; Wed, 24 Feb 2016 21:54:19 +0000 (GMT) Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 24 Feb 2016 15:54:18 -0600 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1076.000; Wed, 24 Feb 2016 15:54:18 -0600 From: "Salz, Rich" To: Aaron Zauner Thread-Topic: [TLS] SRP ? Thread-Index: AdFuT674UuyzJsa5Tha9ZPuI0hYuYgBMGAeAAAyPBEA= Date: Wed, 24 Feb 2016 21:54:17 +0000 Message-ID: <1445a459b4b44326b9ec7ae6e9927950@ustx2ex-dag1mb1.msg.corp.akamai.com> References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> In-Reply-To: <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.233] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:54:21 -0000 Thanks for the feedback, everyone. The OpenSSL SRP code is staying. -- =20 Senior Architect, Akamai Technologies IM: richsalz@jabber.at Twitter: RichSalz From nobody Wed Feb 24 13:59:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C823F1B3180 for ; Wed, 24 Feb 2016 13:59:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iPhrAFg1Wnvb for ; Wed, 24 Feb 2016 13:59:52 -0800 (PST) Received: from lb3-smtp-cloud2.xs4all.net (lb3-smtp-cloud2.xs4all.net [194.109.24.29]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 405E81B310E for ; Wed, 24 Feb 2016 13:59:52 -0800 (PST) Received: from airhead.local ([83.161.146.46]) by smtp-cloud2.xs4all.net with ESMTP id NMzn1s00L10HQrX01MzoAt; Wed, 24 Feb 2016 22:59:50 +0100 Message-ID: <56CE27D1.7060002@openfortress.nl> Date: Wed, 24 Feb 2016 22:59:45 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Aaron Zauner References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> In-Reply-To: <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 21:59:55 -0000 Hi, > Although the lack of modern cipher-suites for SRP makes it not very > attractive these days. > Does anyone know if work on something like "ECSRP" is going on, anywhere? We've recently worked on getting it working with PKCS #11, https://github.com/arpa2/srp-pkcs11 https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf It could be interesting to see if this translates to the Elliptic Curve arena. I heard rumours of alternatives being weighed against one another, but failed to find anything concrete. Links are quite welcome! -Rick From nobody Wed Feb 24 15:29:03 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3F3F1A8919 for ; Wed, 24 Feb 2016 15:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_39=0.6, SPF_PASS=-0.001] autolearn=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 Ntexkt0-rla9 for ; Wed, 24 Feb 2016 15:29:00 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698501A88EB for ; Wed, 24 Feb 2016 15:28:59 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id a4so4657985wme.1 for ; Wed, 24 Feb 2016 15:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=84y0RGwvG+BxvrX4gJL7ZpU1SRnPlzxHzumxmeeEDOU=; b=oXbKIZwdeLbGrA4srS6WM3xj6UfC21CgGrJylDHW7VCVkuroljaocpItiuA/rcMmTT CBsXnt9IdFdSHF0qlajoXf/tIRXdD6/kRMfWGYY74i7ZCmn8Tgqw7YjwC49e01h+rWGt cD8cK9SJ79fBS01qlicSWAPnE4WGk2Pd1mhLkVJko+z9Am04fB8hdLtrjHa6t2+CdTgQ VXNlRB4c9CgFnlun0qm7qpL+rlkWWBhk8F/feIKy6W4FfbbHFvPyRI6VGqRWE1eQ8bRc 4ad/XPrVuOWOtjvBtvQit5Csh5Nszz31Pwu4ucq793SszoTNObSAfNkFgBI87VQbDcH4 ESmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=84y0RGwvG+BxvrX4gJL7ZpU1SRnPlzxHzumxmeeEDOU=; b=iThse3PsJOPsAI0LyVbKaIxA0vGETZlThm9TJz2xSWaVScFU079Chk3/dYe6vos/Ji tYKvyC51GfiOkqipQCMakdnrZxRLL8sPVSi0JLm3U1tMwvVkN/zmSBrtVVKg9ejbrVLX AfhvL7vzVxXvGLwwYg6FS49oNk+yJQ4go5XxwX+NagiB0tMbrwvZb2sCGlcWR7DzQzVb G0joUllc/PrH0RHZfztgrbM1iME+KLAHQp0oJoHz+xaoJcwAZE0gNHBVc076dadTETOM 65VMUvH4JV7ThTeXqmn190mIeAseUrfBpVCkCeYdyg2uyEei2oFTO/1Y0hpqYJOW+Phm DFQA== X-Gm-Message-State: AG10YOTYXRc55g6N9SHZhW/fNsB4t16gW84s9jJnoiBmId6FPmjX9jfJhDOyhYNVS2fd0A== X-Received: by 10.194.116.9 with SMTP id js9mr49972891wjb.112.1456356537960; Wed, 24 Feb 2016 15:28:57 -0800 (PST) Received: from [192.168.0.12] (89-156-8-219.rev.numericable.fr. [89.156.8.219]) by smtp.gmail.com with ESMTPSA id w136sm428817wmw.0.2016.02.24.15.28.56 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 15:28:57 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Karthikeyan Bhargavan In-Reply-To: <20160224181450.GB28926@LK-Perkele-V2.elisa-laajakaista.fi> Date: Thu, 25 Feb 2016 00:28:56 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201602232057.18505.davemgarrett@gmail.com> <974CF78E8475CD4CA398B1FCA21C8E99564E7F92@PRN-MBX01-4.TheFacebook.com> <20160224180045.GA28926@LK-Perkele-V2.elisa-laajakaista.fi> <20160224181450.GB28926@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Feb 2016 23:29:01 -0000 >=20 > The server signature is essentially over raw handshake messages, up > to and including ServerCertificate. The first message that would > depend on actual value of SS is ServerFinished, which comes after > that point=E2=80=A6 Yes Ilari, you=E2=80=99re right. In my TRON talk, I described an attack on PSK+Signature server auth which showed that the natural way of composing PSK + Sigs won=E2=80=99t = work. (And no it doesn=E2=80=99t work for PSK-ECDHE either.) I think the proper way to do it is that the pre_shared_key extension should include a ps_context value derived from the PSK. E.g for = resumption, it could include the session hash of the previous connection. For pure PSK, it could include a MAC computed using the PSK. It is worth noting that having such a psk_context in the client hello would=E2=80=99ve prevented the attack that Cremers et al found in = Tamarin as well. Best, Karthik >=20 >=20 > -Ilari >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Feb 25 04:30:01 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC6E1A876E for ; Thu, 25 Feb 2016 04:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.951 X-Spam-Level: X-Spam-Status: No, score=-5.951 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tze2trS2cGz8 for ; Thu, 25 Feb 2016 04:29:57 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 753B51A873C for ; Thu, 25 Feb 2016 04:29:57 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 6206644BB5; Thu, 25 Feb 2016 13:29:55 +0100 (CET) X-purgate-ID: 152705::1456403395-00007292-2A56C2CE/0/0 X-purgate-size: 568 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 2F27C41613; Thu, 25 Feb 2016 13:29:54 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 9F45D1A43F; Thu, 25 Feb 2016 13:29:54 +0100 (CET) In-Reply-To: <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> To: Karthikeyan Bhargavan Date: Thu, 25 Feb 2016 13:29:54 +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: <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 12:29:59 -0000 Karthikeyan Bhargavan wrote: > > Yes Hugo, you?re right that when there is no client auth, > the situation is less problematic. I'm not so sure. There might be the desire of the server to keep some data confidential, and your argument is that if the data wasn't confidential to begin with, the server is not "breaking" confidentiality--although the server is clearly doing this. But what about the client and the client's desire to keep confidential, which particular "public data" it is just requesting and receiving from the server. -Martin From nobody Thu Feb 25 04:40:47 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F0191A8BBE for ; Thu, 25 Feb 2016 04:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r3gJsaCtu0Vq for ; Thu, 25 Feb 2016 04:40:44 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18421A8A6E for ; Thu, 25 Feb 2016 04:40:43 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (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 95F0344BC9; Thu, 25 Feb 2016 13:40:42 +0100 (CET) X-purgate-ID: 152705::1456404042-000073AB-DFBE0B12/0/0 X-purgate-size: 160 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 835A7410DF; Thu, 25 Feb 2016 13:40:42 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 2FFF91A43F; Thu, 25 Feb 2016 13:40:42 +0100 (CET) In-Reply-To: To: Watson Ladd Date: Thu, 25 Feb 2016 13:40:42 +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: <20160225124042.2FFF91A43F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 25 Feb 2016 12:40:46 -0000 Watson Ladd wrote: > > But will they call tls_send_data_replayable? The proper name would be tls_send_data_replayable_and_NO_forward_secrecy. -Martin From nobody Thu Feb 25 05:55:34 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ECC1ACD47 for ; Thu, 25 Feb 2016 05:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.098 X-Spam-Level: * X-Spam-Status: No, score=1.098 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_32=0.6, J_CHICKENPOX_65=0.6, SPF_PASS=-0.001] autolearn=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 6WthdpSNAVBZ for ; Thu, 25 Feb 2016 05:55:31 -0800 (PST) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 624821ACD35 for ; Thu, 25 Feb 2016 05:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Message-ID:References:In-Reply-To:Subject:Cc:To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=Tv1TNsvWRwuZlAq4Nhj54w6ZvwUfu8DLixK6qIaCTwM=; b=pPTK7tmVIOHUcJhUz5enopwap+xEIZNAt9xiTInVIkRr10Vl63mPNy+0XszqO9f9gqeMwBo8BvQYBHaqggJK4IJAxWnRt7vYhg6PC6efriu2U1z4OWvwchbZ2+6mog9UNhoflqXO7MeGEON4sFsicxrC+18SNdnUdbYznQHPM/vWtFrl7tDZR7I8oFL0nbU15MQ2Z3GaC3bar4j6Ot/h7W53f/D7d16x9iD3WjxMMKozmszI88PxK7lPtCgxMbhDUzMsv3bDyECDYhWTG9bJtyYxDwWKMyrf3D2oM+vwYypVkCXwOxQ/eQziTvzWIgFOdta4nOeMoKhO2m+wBHBdwQ==; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpa (envelope-from ) id 1aYwO8-0000Xm-7K ; Thu, 25 Feb 2016 14:55:28 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 25 Feb 2016 13:55:27 +0000 From: Antoine Delignat-Lavaud To: tls@ietf.org Organization: Microsoft Research In-Reply-To: <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp> References: <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp> Message-ID: <6ff7fd3f6e7b177800c388e5496387b6@maxg.info> X-Sender: antoine@delignat-lavaud.fr User-Agent: Roundcube Webmail/1.0.2 Archived-At: Cc: Karthikeyan Bhargavan Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 13:55:33 -0000 Le 2016-02-25 12:29, mrex@sap.com a écrit : > Karthikeyan Bhargavan wrote: >> >> Yes Hugo, you?re right that when there is no client auth, >> the situation is less problematic. > > I'm not so sure. QUIC gives a pretty good idea of how 0-RTT is going to be used in browsers: they will almost certainly send 0-RTT requests that contain session cookies and servers will return confidential data in 0.5-RTT routinely. I think it is very important to assume that this usage scenario is part of the core features of 1.3 that we model and analyze. There is little doubt that 0.5-RTT will leak some bits of information due to replayability; nevertheless, assuming that 0.5-RTT data is always public and give it the same guarantees as handshake encryption is a bad way to deal with these problems. Under the current key schedule, an active adversary still needs to break the PSK in order to decrypt 0.5-RTT data; this is a forward secrecy problem rather than a confidentiality one. Even if the 0-RTT finished message is removed, the context of the 0-RTT data key will still include the current ClientHello, and thus, downgrade in the style of Logjam+False Start requires PSK compromise as well. Concerning agility, a simple strategy is to pre-negotiate 0-RTT handshake parameters (including ciphersuite) when the PSK is established (i.e. extend the NewSessionTicket message). Best, Antoine From nobody Thu Feb 25 06:03:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3691ACD8D for ; Thu, 25 Feb 2016 06:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGBkyEy3UBKz for ; Thu, 25 Feb 2016 06:03:35 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id A0EA61ACD7E for ; Thu, 25 Feb 2016 06:03:35 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 39270B88; Thu, 25 Feb 2016 16:03:34 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id RDrBNA-fzNvh; Thu, 25 Feb 2016 16:03:33 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 01719C4; Thu, 25 Feb 2016 16:03:32 +0200 (EET) Date: Thu, 25 Feb 2016 16:03:28 +0200 From: Ilari Liusvaara To: Hugo Krawczyk Message-ID: <20160225140328.GA29904@LK-Perkele-V2.elisa-laajakaista.fi> References: <201602232057.18505.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Remove DH-based 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 14:03:42 -0000 On Tue, Feb 23, 2016 at 10:39:37PM -0500, Hugo Krawczyk wrote: > On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett > wrote: > > ​I suggest to also define TLS 1.3-EZ. > A subset of core safe functionality that should address the majority of the > usage cases. What restrictions should there be for that subset? I think at least the following: - No 0-RTT (if you are looking for "exciting" security analysis, this is the best place to look at). - Server waits until ClientFinished before sending data (see the 0.5-RTT thread about excitement if you don't). - No Server configs (but this might be going anyway). - No post-handshake client auth (dangerous if used wrong). - No SHA1 hashalgorithm (broken!) - No TLS-Unique (deprecated due to breakage in earlier versions) The rest of potentially troublesome stuff seems to be extensions, e.g. anything defining new handshake messages (except OCSP extensions, since those messages presumably will be folded to Certificate messages). (There's plenty of crap in the registeries, but most of it has gotten killed off from TLS 1.3 anyway). -Ilari From nobody Thu Feb 25 08:06:08 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE101B2C15 for ; Thu, 25 Feb 2016 08:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.069 X-Spam-Level: X-Spam-Status: No, score=0.069 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc1ewOOTZmFN for ; Thu, 25 Feb 2016 08:06:04 -0800 (PST) Received: from st11p02im-asmtp001.me.com (st11p02im-asmtp001.me.com [17.172.220.113]) (using TLSv1.2 with cipher DHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D98151B2BFC for ; Thu, 25 Feb 2016 08:06:03 -0800 (PST) Received: from 94.9.168.191.isp.timbrasil.com.br (unknown [64.210.40.106]) by st11p02im-asmtp001.me.com (Oracle Communications Messaging Server 7.0.5.36.0 64bit (built Sep 8 2015)) with ESMTPSA id <0O34006YH21YAS30@st11p02im-asmtp001.me.com> for tls@ietf.org; Thu, 25 Feb 2016 16:06:00 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-02-25_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1510270003 definitions=main-1602250226 From: Shin'ichiro Matsuo Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable Date: Thu, 25 Feb 2016 08:05:58 -0800 Message-id: To: "" MIME-version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Archived-At: Subject: [TLS] Formal Verification of TLS 1.3 Full Handshake Protocol Using ProVerif (Draft-11) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 16:06:06 -0000 Hi all, [Introduction] CELLOS (Cryptographic protocol Evaluation toward Long-Lived Outstanding = Security) forms a team for formal verification of TLS. It has modeled = TLS 1.3 draft specification and conducted verification by using = ProVerif. Until now, we have modeled the full handshake protocol in = draft-06, -09, -10, and -11. As a result of this formal verification, we = did not find any security flaw. You can freely download the latest = descitption of formal model at = https://www.cellos-consortium.org/studygroup/TLS1.3-fullhandshake-draft11.= pv =20 Any comments, advices, requests and modification from TLS experts are = welcome for further evaluations. We share the models and verification = results. Our modeling policy is straightforward formalization, that is, we aim to = faithfully follow the draft specification. In other words, we did not = simplify the protocol (at least at the symbolic level) and all the = variables appeared in the draft are included in the formalized model. On the other hand, the sizes of the variables are not modeled and = side-channel attacks (including padding oracle attack) are not taken = into account. [Target version] TLS 1.3 draft-11 full handshake protocol ------------------------------------- [Tool] ProVerif 1.92 http://prosecco.gforge.inria.fr/personal/bblanche/proverif/ After installing the latest version of ProVerif, run the following = command to execute the evaluation. $ proverif -in pitype TLS1.3-fullhandshake-draft11.pv [What's checked] We checked the TLS draft-11 full handshake protocol for the following = two properties. * Secrecy of payload: Can the attacker know the encrypted payload? * Authenticity: Can the attacker impersonate the server? [Evaluation results] * Secrecy: secure (ProVerif outputs "true") * Authentication: secure We did not find an attack against the full handshake protocol in = draft-11 in above setting. [Evaluation environment and evaluation time] CPU: Intel Core i7-4600U (2.10 GHz) Memory: 16 GB OS: Windows 7 (64-bit) Time: 56 minutes Regards, Shin=E2=80=99ichiro Matsuo =20 From nobody Thu Feb 25 11:54:38 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532A21B335D for ; Thu, 25 Feb 2016 11:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001] autolearn=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 q3s8MmBbTCZg for ; Thu, 25 Feb 2016 11:54:35 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 774321B3356 for ; Thu, 25 Feb 2016 11:54:35 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id 78so40172721lfy.3 for ; Thu, 25 Feb 2016 11:54:35 -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:content-type; bh=UzfGIVsYPT44z5b6dgokvWItE4lJAcXGGOSwEzGMxY8=; b=XYtCtq8s/Y8CtSqHURtb4UTDaU/GZUPOWonMbcwxcdMkE9mV0PioQg71etn7jfTdqM htcfPdPg08QDCWaEj16boDHwKWyYL6i0BOEKuwgzYpovxgDRFLaEPVD/0tAiHZf6lFNv NsK89AQrwetd7rvCb59SoLmMdZAoJRtkAx3Cvgy9+fAqHb+ernt6s3rWxMsSmGaLq44I wXY2nyUsV4elqRzjlYtM646O9JcuFlG+4C9EyKHLFeRilaLDIT+QMCMjYj1iA8nvo/eN bAMnDwIdvG6u/b55nJIff0EsGp2VKEXaztQs6j3mseBXLS+/rUkUD9wVwyV2Jk1PYEil jZ6A== 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:content-type; bh=UzfGIVsYPT44z5b6dgokvWItE4lJAcXGGOSwEzGMxY8=; b=KYirCMfqOsDimEZ3XPImx7S3PIC0BZ0cQvOsofDEOLKv76PWusQHv6FPH40KFwHl4s 6JeC5eJdYUpsqXV1qGYU27K4g4VLRHWI18T1e2TsMbFoqg39pK9VkojgDzGFdP/0fP1I csiqMWY5VBnWrc916f83jxSDgmWtUdz/0TXqrQLxZgAH9Rk3VAR+TUmuVWmsRSRW1oxf E/gWlrMicaghn+xcLyGYP2cS9yGe7+SqDnlMYllsLnJowq7aCOUot7n8DCIez9feacux 8BICt8zUzCdTACvWpAFYNxJQzXwYEwSVxsVj9nJ5dLG1aVYoeUJLBq0V+Kzvl+/duris YO1w== X-Gm-Message-State: AG10YOQe/z4+ilbbZQTpBECy0Cq3FiMflTJyeR/PeT8meldl7xRsp4WELFZispxpL8BSI0Ys1IOHHCtaWHWojw== X-Received: by 10.25.136.139 with SMTP id k133mr17383316lfd.157.1456430073644; Thu, 25 Feb 2016 11:54:33 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Thu, 25 Feb 2016 11:54:04 -0800 (PST) In-Reply-To: <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp> References: <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp> From: Hugo Krawczyk Date: Thu, 25 Feb 2016 14:54:04 -0500 X-Google-Sender-Auth: q6zlLyU5Wq3YwCwMJR165zCvsbk Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=001a113f38942e0fa6052c9d8de8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 19:54:37 -0000 --001a113f38942e0fa6052c9d8de8 Content-Type: text/plain; charset=UTF-8 As I said in another email, without client authentication (which is the scenario in the Karthik quote), data sent by the server should be considered secure only against passive adversaries. Any additional assumption on confidentiality (i.e., restricting the power of an active attacker) must consider some form of client authentication, either implicit or explicit. Both cases must be dealt with with care, especially the implicit ones (e.g. authentication implied by application mechanisms and semantics). On Thu, Feb 25, 2016 at 7:29 AM, Martin Rex wrote: > Karthikeyan Bhargavan wrote: > > > > Yes Hugo, you?re right that when there is no client auth, > > the situation is less problematic. > > I'm not so sure. > > There might be the desire of the server to keep some data confidential, > and your argument is that if the data wasn't confidential to begin with, > the server is not "breaking" confidentiality--although the server is > clearly doing this. > > But what about the client and the client's desire to keep confidential, > which particular "public data" it is just requesting and receiving > from the server. > > > -Martin > --001a113f38942e0fa6052c9d8de8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I said in another email, without client auth= entication (which is the scenario in the Karthik quote), data sent by the s= erver should be considered secure only against passive adversaries. Any add= itional assumption on confidentiality (i.e., restricting the power of an ac= tive attacker) must consider some form of client authentication, either imp= licit or explicit. Both cases must be dealt with with care, especially the = implicit ones (e.g. authentication implied by application mechanisms and se= mantics).


On Thu, Feb 25, 2016 at 7:29 AM, Martin Rex <mrex@sap.= com> wrote:
Karthikeyan Bha= rgavan wrote:
>
> Yes Hugo, you?re right that when there is no client auth,
> the situation is less problematic.

I'm not so sure.

There might be the desire of the server to keep some data confidential,
and your argument is that if the data wasn't confidential to begin with= ,
the server is not "breaking" confidentiality--although the server= is
clearly doing this.

But what about the client and the client's desire to keep confidential,=
which particular "public data" it is just requesting and receivin= g
from the server.


-Martin

--001a113f38942e0fa6052c9d8de8-- From nobody Thu Feb 25 12:11:33 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3165A1B33E2 for ; Thu, 25 Feb 2016 12:11:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_46=0.6, RP_MATCHES_RCVD=-0.006] autolearn=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 IAe1Df5q0sew for ; Thu, 25 Feb 2016 12:11:29 -0800 (PST) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 968D61A1B91 for ; Thu, 25 Feb 2016 12:11:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id DB0ADCB9; Thu, 25 Feb 2016 22:11:28 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 7sLsr9Tdx3AK; Thu, 25 Feb 2016 22:11:28 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7D02F286; Thu, 25 Feb 2016 22:11:28 +0200 (EET) Date: Thu, 25 Feb 2016 22:11:24 +0200 From: Ilari Liusvaara To: Shin'ichiro Matsuo Message-ID: <20160225201124.GB30171@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.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] Formal Verification of TLS 1.3 Full Handshake Protocol Using ProVerif (Draft-11) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 20:11:31 -0000 On Thu, Feb 25, 2016 at 08:05:58AM -0800, Shin'ichiro Matsuo wrote: > > ------------------------------------- > > [What's checked] > We checked the TLS draft-11 full handshake protocol for the following two properties. > * Secrecy of payload: Can the attacker know the encrypted payload? > * Authenticity: Can the attacker impersonate the server? I think the following should be checked as well (once the relevant definitions are available): - signed TLS-EXPORTER results can be used for authentication. - TLS-EXPORTER results can be used as secure encryption keys. There are many pieces of sofware that rely on those two properties. Also, reading the .pv file, it seems like only 1-RTT GDHE-CERT mode is verified, not GDHE-PSK nor PSK nor any kind of 0-RTT mode. (And then there are possibly even worse problems with usage... Not that I know what's the "correct" model there). -Ilari From nobody Thu Feb 25 12:47:31 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DC101B3515 for ; Thu, 25 Feb 2016 12:47:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, J_CHICKENPOX_65=0.6] autolearn=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 tTvNzr8A1h29 for ; Thu, 25 Feb 2016 12:47:29 -0800 (PST) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0FB21B350D for ; Thu, 25 Feb 2016 12:47:28 -0800 (PST) Received: by mail-yk0-x236.google.com with SMTP id u9so27496000ykd.1 for ; Thu, 25 Feb 2016 12:47:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=QcxrIi3yx/y9Fu0SYfW4WgdFBwMlLGYMnXOt/upQL+w=; b=MOfIvUahOunc8LPBXq9WIAsyKCZR7exSQwt1ZpQER/vSfnM6p72WjL0ep2HB02G8pd uHB68bTZ6V7s89NHHLnNXyQFtDAbMIXCC0fWZr6vtAw8R4Ch/xy3QvTxIRmjWTXL6NAk mWrcUn7q/OfOJFYJQjSmdzPdGo1vAhJNSDygS5EWsWh+fDYew2fJIULaq5ImXh4xCroz ERLB/PajOMtocmdkNbEsZ+gbUb9MHkCQ1ujdkSl301Y5NRWF/9E1n9RXfpKaI3mmZAqH LnWCdw/56q4yM/eKcX6KUXCrZYRaVpN8pGAsUy6FXLCVvtY7JfcbGMYC2dNIYAxA6AEI aFfg== 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-type; bh=QcxrIi3yx/y9Fu0SYfW4WgdFBwMlLGYMnXOt/upQL+w=; b=B/pLtT1RpsaGHi6XUt0rqWDGnR7lLkBhG1eSg6E9Ck0Upz87pe9m/ifjWkb9Fn7QzR xclKqYrHNElAFBhphmLoOKTN5+uDkJafPC6T+4oGPlZrV1CfEoKZCv2C+RitMaJLzONI hOyoUyWCtLrqqwL1gzHO72NN2dqaDalXYDFXx0FaTEEvysC/xFcQx3VWvrefoeigEIex 9IoDxvLSb5iSuow4qa0y4Y3fA9bnNlDkXPrPGO0+74U8HJQq3hP3XnsBqL4vDA1TxbjG 2TyIHFbbhS/Bsm0agK6Hh064FItM3c6ftC8TJJRdmXtlVwbdvs5mDSxbeULD7VTD4fmH fsZA== X-Gm-Message-State: AG10YOQxWPdJEwsMmfsgs+6V8XmQ6qJ6qS0q+/GjBQHuX65u3ze4p3n6gkAcytfP8BFfgSBLoPWsSdnut6cHsA== X-Received: by 10.37.230.210 with SMTP id d201mr7590700ybh.74.1456433248071; Thu, 25 Feb 2016 12:47:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Thu, 25 Feb 2016 12:46:48 -0800 (PST) In-Reply-To: <6ff7fd3f6e7b177800c388e5496387b6@maxg.info> References: <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp> <6ff7fd3f6e7b177800c388e5496387b6@maxg.info> From: Eric Rescorla Date: Fri, 26 Feb 2016 04:46:48 +0800 Message-ID: To: Antoine Delignat-Lavaud Content-Type: multipart/alternative; boundary=94eb2c0a8b546426b2052c9e4aa2 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Feb 2016 20:47:30 -0000 --94eb2c0a8b546426b2052c9e4aa2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 25, 2016 at 9:55 PM, Antoine Delignat-Lavaud < antoine@delignat-lavaud.fr> wrote: > Le 2016-02-25 12:29, mrex@sap.com a =C3=A9crit : > >> Karthikeyan Bhargavan wrote: >> >>> >>> Yes Hugo, you?re right that when there is no client auth, >>> the situation is less problematic. >>> >> >> I'm not so sure. >> > > QUIC gives a pretty good idea of how 0-RTT is going to be used in > browsers: they will almost certainly send 0-RTT requests that contain > session cookies and servers will return confidential data in 0.5-RTT > routinely. I think it is very important to assume that this usage scenari= o > is part of the core features of 1.3 that we model and analyze. > Yes, that's correct. > There is little doubt that 0.5-RTT will leak some bits of information due > to replayability; nevertheless, assuming that 0.5-RTT data is always publ= ic > and give it the same guarantees as handshake encryption is a bad way to > deal with these problems. > > Under the current key schedule, an active adversary still needs to break > the PSK in order to decrypt 0.5-RTT data; this is a forward secrecy probl= em > rather than a confidentiality one. > > Even if the 0-RTT finished message is removed, the context of the 0-RTT > data key will still include the current ClientHello, and thus, downgrade = in > the style of Logjam+False Start requires PSK compromise as well. > > Concerning agility, a simple strategy is to pre-negotiate 0-RTT handshake > parameters (including ciphersuite) when the PSK is established (i.e. exte= nd > the NewSessionTicket message). > My thought of how to deal with this was to simply *infer* the 0-RTT parameters from those when the PSK was established. This is the natural extension of what the document currently says about DHE-0RTT but can be simpler because the ticket can contain the full state. -Ekr > Best, > > Antoine > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0a8b546426b2052c9e4aa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 25, 2016 at 9:55 PM, Antoine Delignat-Lavaud <ant= oine@delignat-lavaud.fr> wrote:
Le 2016-02-25 12:29, mrex@sap.com a =C3=A9crit=C2=A0:
Karthikeyan Bhargavan wrote:

Yes Hugo, you?re right that when there is no client auth,
the situation is less problematic.

I'm not so sure.

 QUIC gives a pretty good idea of how 0-RTT is going to be used in browsers:= they will almost certainly send 0-RTT requests that contain session cookie= s and servers will return confidential data in 0.5-RTT routinely. I think i= t is very important to assume that this usage scenario is part of the core = features of 1.3 that we model and analyze.

<= div>Yes, that's correct.
=C2=A0
There is little doubt that 0.5-RTT will leak some bits of information due t= o replayability; nevertheless, assuming that 0.5-RTT data is always public = and give it the same guarantees as handshake encryption is a bad way to dea= l with these problems.

Under the current key schedule, an active adversary still needs to break th= e PSK in order to decrypt 0.5-RTT data; this is a forward secrecy problem r= ather than a confidentiality one.

Even if the 0-RTT finished message is removed, the context of the 0-RTT dat= a key will still include the current ClientHello, and thus, downgrade in th= e style of Logjam+False Start requires PSK compromise as well.

Concerning agility, a simple strategy is to pre-negotiate 0-RTT handshake p= arameters (including ciphersuite) when the PSK is established (i.e. extend = the NewSessionTicket message).

My thoug= ht of how to deal with this was to simply *infer* the 0-RTT parameters
from those when the PSK was established. This is the natural extensio= n of what
the document currently says about DHE-0RTT but can be s= impler because
the ticket can contain the full state.
<= br>
-Ekr
=C2=A0
Best,

Antoine


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

--94eb2c0a8b546426b2052c9e4aa2-- From nobody Thu Feb 25 19:20:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16AA81A88AF for ; Thu, 25 Feb 2016 19:20:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 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, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001] autolearn=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 PUluvog-EzOB for ; Thu, 25 Feb 2016 19:20:47 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60EA31A88A0 for ; Thu, 25 Feb 2016 19:20:47 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id e63so59629717ywc.3 for ; Thu, 25 Feb 2016 19:20: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:date:message-id:subject:from:to :cc:content-type; bh=R5uRgdUmWkuDKg5gvawLwgqsnPmAGzwduv4FV5CWoFs=; b=wHWiDW9YhuZwx+RAtL1tc3NrCXdQ1wxNxYxY0ZoJZej4OS2+Vmw4ELeApaA7Q0wodQ Jfn+glQJyCtikDby3BhcPg2bV7xYkRAFiuDz5CqsQ2c3ywaVL2S8NCcIQeCR2L559sod igeVZRWim7ddVqPJAPNAdxyUVFRA7AhLtyXsaiYmhpZkl4i1l/ZyOXuimkAOxsoocYaw YTSIvTmikmhtGlXGb/QOFi0WYi/5spJt/INM1/p9JDBVVUl+acVsPSfIQhxrMnvBo1FA RbIVzWB/Dh3ZH7r7Hg+dW2gybyBCjo1gP0kwum3osP96N6FUKV4z9orloyE3l3Vy/K+a rd6A== 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:date :message-id:subject:from:to:cc:content-type; bh=R5uRgdUmWkuDKg5gvawLwgqsnPmAGzwduv4FV5CWoFs=; b=aMFl9cTEBf7Ays9qx14oLRebjK4vjBM47y+nUEhex6zn3J4h78Hrlv+Cjqnn60en8z lTwewbbN4QLZugrH43krF2127iP4+Qj+s1H53BjzDQNsJLcnSo7n5s2I9NQfsEWpGjlI WG6Va2TouaNagso1q/GK/9nBz5GJfpb5PcF94hJHs1jrTmnZNl2qgH8SHAdOKj00tRQS GOSVvMR8P9DUZ78EkEwLw0yYs9VczG9IP3EaXf1jR2rHx1EVcC0vZQaCmC4yvkyp97CJ Y9zPIgSichEtbu+hKiTxhbO+/1EsihywtOzdx6VOPNffLEdHmgJR+NKJz6nJNXYXXG9V +88w== X-Gm-Message-State: AG10YOT+OHVw+ZnNMAYtDleGg8T3YGaIeJjGei3bIwZLwPyUO5E6HH/V6LMQPoY27gS+8oFkxiiAccoVdChx3w== MIME-Version: 1.0 X-Received: by 10.129.0.9 with SMTP id 9mr25192172ywa.101.1456456846577; Thu, 25 Feb 2016 19:20:46 -0800 (PST) Received: by 10.13.216.138 with HTTP; Thu, 25 Feb 2016 19:20:46 -0800 (PST) In-Reply-To: References: <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp> Date: Thu, 25 Feb 2016 19:20:46 -0800 Message-ID: From: Watson Ladd To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 03:20:49 -0000 On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk wrote: > As I said in another email, without client authentication (which is the > scenario in the Karthik quote), data sent by the server should be considered > secure only against passive adversaries. Any additional assumption on > confidentiality (i.e., restricting the power of an active attacker) must > consider some form of client authentication, either implicit or explicit. > Both cases must be dealt with with care, especially the implicit ones (e.g. > authentication implied by application mechanisms and semantics). I think this is unnecessarily pessimistic/ignores the ways in which higher-level applications may have authentication and what we need from them. The below should be taken as a clever guess, rather than representative of the truth. First, we know that negotiation doesn't work in 0-RTT. But that's ok: we need to limit to only strong ciphers anyway, because negotiation doesn't work/general depreciation. This means that clients can be fooled by attackers into using the weakest notion they support for continued authentication of PSKs: this applies to resumption with tickets as well. We also know that each PSK is only shared between one server and one other client from the unpredictability of the negotiated keys. And so when when a server decrypts a ticket, it knows that whatever data it saved in the ticket negotiated in the original negotiation applies to whoever sent it this 0-RTT data, and it knows its response will go only to someone who *at one point* sent this 0-RTT data. And so if there is a cookie or url parameter authenticating the client that is not tied to the PSK, so long as the PSK is secure there is only one party that could have sent that cookie, and the response will go to it. The same is true for prior client authentication, saved in the ticket. Formalizing the above is likely to be a bit tricky, but I don't see why it wouldn't be possible. > > > On Thu, Feb 25, 2016 at 7:29 AM, Martin Rex wrote: >> >> Karthikeyan Bhargavan wrote: >> > >> > Yes Hugo, you?re right that when there is no client auth, >> > the situation is less problematic. >> >> I'm not so sure. >> >> There might be the desire of the server to keep some data confidential, >> and your argument is that if the data wasn't confidential to begin with, >> the server is not "breaking" confidentiality--although the server is >> clearly doing this. >> >> But what about the client and the client's desire to keep confidential, >> which particular "public data" it is just requesting and receiving >> from the server. >> >> >> -Martin > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Feb 25 23:30:06 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 63BE61ACDC7; Thu, 25 Feb 2016 23:30:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160226073003.29464.2450.idtracker@ietfa.amsl.com> Date: Thu, 25 Feb 2016 23:30:03 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-pwd-07.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 07:30:03 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : Secure Password Ciphersuites for Transport Layer Security (TLS) Authors : Dan Harkins Dave Halasz Filename : draft-ietf-tls-pwd-07.txt Pages : 36 Date : 2016-02-25 Abstract: This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The ciphersuites are all based on an authentication and key exchange protocol that is resistant to off-line dictionary attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-pwd-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-pwd-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 25 23:33:28 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D9D41ACDF1 for ; Thu, 25 Feb 2016 23:33:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.167 X-Spam-Level: X-Spam-Status: No, score=-1.167 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDle2mWt-nbR for ; Thu, 25 Feb 2016 23:33:25 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 609B61ACDE7 for ; Thu, 25 Feb 2016 23:33:25 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id A998C10224008; Thu, 25 Feb 2016 23:33:24 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Thu, 25 Feb 2016 23:33:25 -0800 (PST) Message-ID: <984408eba26e6fd8474bfa45ec317ddc.squirrel@www.trepanning.net> In-Reply-To: <56CE27D1.7060002@openfortress.nl> References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> <56CE27D1.7060002@openfortress.nl> Date: Thu, 25 Feb 2016 23:33:25 -0800 (PST) From: "Dan Harkins" To: "Rick van Rein" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 07:33:27 -0000 Hi, On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote: > Hi, > >> Although the lack of modern cipher-suites for SRP makes it not very >> attractive these days. >> > Does anyone know if work on something like "ECSRP" is going on, anywhere? > > We've recently worked on getting it working with PKCS #11, > > https://github.com/arpa2/srp-pkcs11 > https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf > > It could be interesting to see if this translates to the Elliptic Curve > arena. > > I heard rumours of alternatives being weighed against one another, but > failed to find anything concrete. Links are quite welcome! Well there's TLS-PWD. Works just fine with ECC. Also provides for protection of the client username from passive attack. https://tools.ietf.org/html/draft-ietf-tls-pwd-07 Thanks for reminding me to update that draft :-) Dan. > -Rick > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Feb 25 23:41:43 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA861ACDE9 for ; Thu, 25 Feb 2016 23:41:41 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52r8su8vOE5v for ; Thu, 25 Feb 2016 23:41:40 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAD51ACDDE for ; Thu, 25 Feb 2016 23:41:40 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id u200so63256731ywf.0 for ; Thu, 25 Feb 2016 23:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=MRQD71UP8V0sxFNvfjIPU4/mmT7Fl+eXUXfk3RTcxLU=; b=HaXD35bZfN0RuQDMbB3Yulqum0FqIHb9Vh01pmjEHDGik8PaZt7yrmtlmkXxaCldQq JhT7+/nBJ29uZNYI4ldX2uluSgO+1sJyLGWL2NLpOATPkx0rUj+u80EoCrlMjr3PIOaW uLjLRP4SdjVLi8Gow0SWWYWIUNbW6NrGw1KJqa7+9R2o23kQOzjZ++wK2guidaNS+fOq j2W7RWFha0zuCu5rKeuxn8sRmDyodx04cEVbGfeO8KOX+ZPDVhrG4zLb/xHe/xCxx5kP ZP1ojzPysno/E6WrUMgDllu9jsNB8Awl6j48K9nWY534Ph41NEnHwaKeLsYXaS0UTEZi rvlA== 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:date :message-id:subject:from:to:cc; bh=MRQD71UP8V0sxFNvfjIPU4/mmT7Fl+eXUXfk3RTcxLU=; b=YNSvi5ctQuU0jvUYxBxCqpt+KF3j0zHPjtEy+fUqHE7yxIdhAPXTMQShI1UAxZvdfx 2xSHQj+Ovhz3Gvx1XORSV2qc8FeWrlvytr5WVFuxE6/U6xBAeKV4lOjKcB+zdDe+pOHU bGHUEguHnHqGODb+0qCM6kagoW9fOtYtEb0YhB2ATj1ZmRltSluQmdG4HWAir3jF0Nzq 14UoaIupZg5Urh4Kzj4ACV0sqDHYlXa4BR6e4CWr2+8nW4hh/6XmL38uXcqjGAseENqY TmIkBNxvyd4P1ZxrbAQhAvOyRZwDgVv2p1HS1xy9cObqMM7PwxP4HTe/gbLBCLlp4TCZ zXPQ== X-Gm-Message-State: AD7BkJI25QGQlmoaA0bnKNgkeedLfBR32LS3wIZmL6NqdNE/RCvOwqb1lFTRSaPf3hRYcrVojVd2aomGhu0aHQ== MIME-Version: 1.0 X-Received: by 10.13.229.71 with SMTP id o68mr54992ywe.326.1456472499481; Thu, 25 Feb 2016 23:41:39 -0800 (PST) Received: by 10.13.216.138 with HTTP; Thu, 25 Feb 2016 23:41:39 -0800 (PST) In-Reply-To: <984408eba26e6fd8474bfa45ec317ddc.squirrel@www.trepanning.net> References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> <56CE27D1.7060002@openfortress.nl> <984408eba26e6fd8474bfa45ec317ddc.squirrel@www.trepanning.net> Date: Thu, 25 Feb 2016 23:41:39 -0800 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 07:41:42 -0000 On Thu, Feb 25, 2016 at 11:33 PM, Dan Harkins wrote: > > Hi, > > On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote: >> Hi, >> >>> Although the lack of modern cipher-suites for SRP makes it not very >>> attractive these days. >>> >> Does anyone know if work on something like "ECSRP" is going on, anywhere? >> >> We've recently worked on getting it working with PKCS #11, >> >> https://github.com/arpa2/srp-pkcs11 >> https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf >> >> It could be interesting to see if this translates to the Elliptic Curve >> arena. >> >> I heard rumours of alternatives being weighed against one another, but >> failed to find anything concrete. Links are quite welcome! > > Well there's TLS-PWD. Works just fine with ECC. Also provides > for protection of the client username from passive attack. > > https://tools.ietf.org/html/draft-ietf-tls-pwd-07 As well as my SPAKE2 draft, which can fit in TLS easily. The real problem here is that there is no reason not to use certificates in a lot of cases. > > Thanks for reminding me to update that draft :-) > > Dan. > >> -Rick >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Feb 26 01:27:52 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F397E1A0110 for ; Fri, 26 Feb 2016 01:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oCv3FVl77y8x for ; Fri, 26 Feb 2016 01:27:49 -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 684611A010B for ; Fri, 26 Feb 2016 01:27:46 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id g203so116542705iof.2 for ; Fri, 26 Feb 2016 01:27:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc; bh=gsv/IgNYRm72ERo5v7M6ZFpTptbiQO4g3HRFxat6apg=; b=m7BaF/RP2/nMGPHhHFOnSsFLluTCkfjbKVIXvOZvMz5+EGMWQ2V0rNfbyEXNFOCvHP jvoTCy+WM7DBu5lPwbLPknInQKq9Z8DIomQO2voL0Qm5r4WkzfL/MX7irqk3u5tjOVNF Sh2Dv7LSi1ghNL3qF3rizh7FMcEdwIW108aWpXYx7q8Ij9fMF000nvh3hOoo3rRbXKxh oCoc3s09oyQMFQMYev7Uoo0IfJRKPM1q6QEv67zEXw0RgIn+bQQ7LpSRydA/6Nk912n8 FTVuHhumX02PXK/OOHT/+McMwPKZvzq7hPf1CwTCdqP9yP6NFT2edBUyPKNvbJLacs5f l5gA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to:cc; bh=gsv/IgNYRm72ERo5v7M6ZFpTptbiQO4g3HRFxat6apg=; b=cuvzO8nsiMQwl4J9BPj+6Gp49TYzH6/6f2rSA776FPwxHemTiAH7Yz7OIEdtUYcTd6 7En5BkFMANRTTv51eBFGV+nnL217lCuIIJb7re1sDIGgI5kuFNuvZ2nN1UVMF3C6a58F zMjCPF+spxhXOxCDgPA8tgozKn3xiNTqUIBD2sPywUZnrXwtVrdETUq1MMqGxwayCDO5 T69GY3P8XMpL+gE7LaZDW5Tw5zp48R8uLjvSSY3xxXGwegNLX2kd6oqqnkKAnh0oyKFn 9q5jSl7iez5huYXuHdWgv+ZzetYWyWYI9027kvwPoA/4AmFVhV0XJ+15cFlkh8spuLPO k5Rw== X-Gm-Message-State: AG10YOTP1sEUovrqekgW/gB+ia/SdThHnsFNSMv0EZZ8EYb51mumo4Gg65yVONzBhqo9LLRP/8xT6CKAYFxGyA== MIME-Version: 1.0 X-Received: by 10.107.131.206 with SMTP id n75mr7168082ioi.189.1456478865813; Fri, 26 Feb 2016 01:27:45 -0800 (PST) Received: by 10.64.156.234 with HTTP; Fri, 26 Feb 2016 01:27:45 -0800 (PST) Date: Fri, 26 Feb 2016 01:27:45 -0800 Message-ID: From: Judson Wilson To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a113ed3586b770d052ca8e9d5 Archived-At: Cc: Dan Boneh , Philip Levis , Judson Wilson , Keith Winstein , Henry Corrigan-Gibbs , "Riad S. Wahby" Subject: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 09:27:51 -0000 --001a113ed3586b770d052ca8e9d5 Content-Type: text/plain; charset=UTF-8 Hello folks, We'd like to add a field to the KeyUpdate message that represents the generation of receive traffic keys in use by the sender of the KeyUpdate message. (Our pull request: https://github.com/tlswg/tls13-spec/pull/426) How this helps: In the current draft, an endpoint that sends a KeyUpdate message and later receives a KeyUpdate message cannot know whether the other side has actually updated its receive keys. The two messages may have been generated independently and crossed in flight. Putting a receive_generation field in the KeyUpdate message lets an endpoint confirm that the other side has received and acted upon an earlier KeyUpdate message. Why we want this: We've been researching how to restrict corporate middleboxes like intrusion-detection systems and virus scanners. Today, these scanners generally demand man-in-the-middle access to TLS traffic and require users to install a private root CA. We think it would be better if they only had "read-only" access and didn't MITM the traffic. One way for a client to grant delayed read-only access in TLS 1.3 is with a "rotate and release." The client starts by sending a KeyUpdate. Later, after all traffic keys from the previous generation have been superseded on both sides, the client releases the (superseded) traffic keys to the middlebox. The middlebox can use the keys to decrypt the previous generation of ciphertext, without danger of compromising the integrity of the session. The challenge is that an endpoint can't safely release its old send keys until it knows that the other side has updated its receive keys. Hence the receive_generation field. We think this is a pretty lightweight way to resolve the ambiguity from KeyUpdates crossing in flight; it doesn't add any blocking, waiting, or extra rounds or messages. Thanks in advance for any feedback. Sincerely, Judson Wilson (+ Henry Corrigan-Gibbs, Riad S. Wahby Keith Winstein, Philip Levis, and Dan Boneh) Stanford University --001a113ed3586b770d052ca8e9d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello folks,

We'd like t= o add a field to the KeyUpdate message that represents the generation of re= ceive traffic keys in use by the sender of the KeyUpdate message. (Our pull= request: https://= github.com/tlswg/tls13-spec/pull/426)

How this= helps: In the current draft, an endpoint that sends a KeyUpdate message an= d later receives a KeyUpdate message cannot know whether the other side has= actually updated its receive keys. The two messages may have been generate= d independently and crossed in flight. Putting a receive_generation field i= n the KeyUpdate message lets an endpoint confirm that the other side has re= ceived and acted upon an earlier KeyUpdate message.

Why we want this: We've been researching how to restrict corporate mi= ddleboxes like intrusion-detection systems and virus scanners. Today, these= scanners generally demand man-in-the-middle access to TLS traffic and requ= ire users to install a private root CA. We think it would be better if they= only had "read-only" access and didn't MITM the traffic.

One way for a client to grant delayed read-only acces= s in TLS 1.3 is with a "rotate and release." The client starts by= sending a KeyUpdate. Later, after all traffic keys from the previous gener= ation have been superseded on both sides, the client releases the (supersed= ed) traffic keys to the middlebox. The middlebox can use the keys to decryp= t the previous generation of ciphertext, without danger of compromising the= integrity of the session. The challenge is that an endpoint can't safe= ly release its old send keys until it knows that the other side has updated= its receive keys. Hence the receive_generation field.

=
We think this is a pretty lightweight way to resolve the ambiguity fro= m KeyUpdates crossing in flight; it doesn't add any blocking, waiting, = or extra rounds or messages. Thanks in advance for any feedback.
=
Sincerely,
Judson Wilson (+ Henry Corrigan-Gibbs, = Riad S. Wahby
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Keith Winstein, Philip Levis, and Dan Boneh)
Stanfor= d University
--001a113ed3586b770d052ca8e9d5-- From nobody Fri Feb 26 04:24:36 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 588B61A0161 for ; Fri, 26 Feb 2016 04:24:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ok_vqsNwvvRN for ; Fri, 26 Feb 2016 04:24:33 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 22A3C1A013F for ; Fri, 26 Feb 2016 04:24:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 0530CF16; Fri, 26 Feb 2016 14:24:31 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id xCmFFGHXl7R7; Fri, 26 Feb 2016 14:24:30 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id A91B1C4; Fri, 26 Feb 2016 14:24:30 +0200 (EET) Date: Fri, 26 Feb 2016 14:24:25 +0200 From: Ilari Liusvaara To: Judson Wilson Message-ID: <20160226122425.GA32313@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.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: Dan Boneh , Philip Levis , Judson Wilson , tls@ietf.org, Keith Winstein , Henry Corrigan-Gibbs , "Riad S. Wahby" Subject: Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 12:24:35 -0000 On Fri, Feb 26, 2016 at 01:27:45AM -0800, Judson Wilson wrote: > Hello folks, > > How this helps: In the current draft, an endpoint that sends a KeyUpdate > message and later receives a KeyUpdate message cannot know whether the > other side has actually updated its receive keys. The two messages may have > been generated independently and crossed in flight. Putting a > receive_generation field in the KeyUpdate message lets an endpoint confirm > that the other side has received and acted upon an earlier KeyUpdate > message. Well, the KeyUpdates are designed to be asynchronous so that the other end does not need to know if the other has acted on KeyUpdate. > One way for a client to grant delayed read-only access in TLS 1.3 is with a > "rotate and release." The client starts by sending a KeyUpdate. Later, > after all traffic keys from the previous generation have been superseded on > both sides, the client releases the (superseded) traffic keys to the > middlebox. The middlebox can use the keys to decrypt the previous > generation of ciphertext, without danger of compromising the integrity of > the session. The challenge is that an endpoint can't safely release its old > send keys until it knows that the other side has updated its receive keys. > Hence the receive_generation field. There are better (and less broken) ways to do this kind of thing (involving two MACs). > We think this is a pretty lightweight way to resolve the ambiguity from > KeyUpdates crossing in flight; it doesn't add any blocking, waiting, or > extra rounds or messages. Thanks in advance for any feedback. The KeyUpdate design is so that crossings don't matter. -Ilari From nobody Fri Feb 26 11:26:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB4951B2ED9 for ; Fri, 26 Feb 2016 11:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.867 X-Spam-Level: X-Spam-Status: No, score=-3.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zClQEGJwDtI0 for ; Fri, 26 Feb 2016 11:26:06 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1061ACD0B for ; Fri, 26 Feb 2016 11:26:06 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 9A33B10224008; Fri, 26 Feb 2016 11:26:04 -0800 (PST) Received: from 104.36.248.13 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Fri, 26 Feb 2016 11:26:06 -0800 (PST) Message-ID: In-Reply-To: References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> <56CE27D1.7060002@openfortress.nl> <984408eba26e6fd8474bfa45ec317ddc.squirrel@www.trepanning.net> Date: Fri, 26 Feb 2016 11:26:06 -0800 (PST) From: "Dan Harkins" To: "Watson Ladd" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 19:26:08 -0000 On Thu, February 25, 2016 11:41 pm, Watson Ladd wrote: > On Thu, Feb 25, 2016 at 11:33 PM, Dan Harkins wrote: >> >> Hi, >> >> On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote: >>> Hi, >>> >>>> Although the lack of modern cipher-suites for SRP makes it not very >>>> attractive these days. >>>> >>> Does anyone know if work on something like "ECSRP" is going on, >>> anywhere? >>> >>> We've recently worked on getting it working with PKCS #11, >>> >>> https://github.com/arpa2/srp-pkcs11 >>> https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf >>> >>> It could be interesting to see if this translates to the Elliptic Curve >>> arena. >>> >>> I heard rumours of alternatives being weighed against one another, but >>> failed to find anything concrete. Links are quite welcome! >> >> Well there's TLS-PWD. Works just fine with ECC. Also provides >> for protection of the client username from passive attack. >> >> https://tools.ietf.org/html/draft-ietf-tls-pwd-07 > > As well as my SPAKE2 draft, which can fit in TLS easily. The real > problem here is that there is no reason not to use certificates in a > lot of cases. Well if you're using a browser I'd agree with you. But when TLS is used to protect non-browser traffic there are plenty of cases where you won't have an implicit trust anchor database or you're going to some server administered by someone who most likely only has a self-signed cert (Let's Encrypt makes it easy to get a cert for a web server but, again, that's kind of browser-centric). I address the case for certificate-less authentication in section 1.1 of the TLS-PWD I-D. regards, Dan. >> >> Thanks for reminding me to update that draft :-) >> >> Dan. >> >>> -Rick >>> >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > From nobody Fri Feb 26 13:18:55 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A755C1B308C for ; Fri, 26 Feb 2016 13:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MwlINK7lq59O for ; Fri, 26 Feb 2016 13:18:52 -0800 (PST) Received: from lb1-smtp-cloud2.xs4all.net (lb1-smtp-cloud2.xs4all.net [194.109.24.21]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8F001B308B for ; Fri, 26 Feb 2016 13:18:51 -0800 (PST) Received: from airhead.local ([145.15.244.38]) by smtp-cloud2.xs4all.net with ESMTP id P9Jm1s0100qRbpd019JnFm; Fri, 26 Feb 2016 22:18:49 +0100 Message-ID: <56D0C135.6050007@openfortress.nl> Date: Fri, 26 Feb 2016 22:18:45 +0100 From: Rick van Rein User-Agent: Postbox 3.0.11 (Macintosh/20140602) MIME-Version: 1.0 To: Dan Harkins References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> <56CE27D1.7060002@openfortress.nl> <984408eba26e6fd8474bfa45ec317ddc.squirrel@www.trepanning.net> In-Reply-To: X-Enigmail-Version: 1.2.3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 21:18:53 -0000 Hello, g/html/draft-ietf-tls-pwd- >> The real >> problem here is that there is no reason not to use certificates in a >> lot of cases. > > when TLS > is used to protect non-browser traffic there are plenty of cases > where you won't have an implicit trust anchor database or you're > going to some server administered by someone who most likely only > has a self-signed cert +1 -Rick From nobody Fri Feb 26 14:00:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EED01B3117 for ; Fri, 26 Feb 2016 14:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5HZVZXsMP97 for ; Fri, 26 Feb 2016 14:00:56 -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 3718E1B3109 for ; Fri, 26 Feb 2016 14:00:56 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id u200so80132545ywf.0 for ; Fri, 26 Feb 2016 14:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=tUSZsBfJ4YEx8+fcPwGqzoZvrO98zWhSG1Pg5FvDJEo=; b=voQDZk0yN3Ob4ZcEW9Vc88eQWzCmqlvxw254avwLQQTW2hcUpMznX70IkSAsozO1Cw ET4QWrjyZZN9ZtlTaU4cbkiCYJiQVgrgJrgUDkgdH2xtzSTCAR91B5cSPo14MHTG0cln wxVBZQyKQQHYGZpFtKzgLwkiHp+02Nkvf0zUSSubGfA/1dCIFWTZz1VMVt/f3DOklrdm +YVqFZN2UkKKbTF3HOTcYu6XiSNInGN06abtJaZHidO0wmnn4JyddXLFSKr/vuGnbuiL TWszWd6NX28eT7KL9Nhs3YEx/Yg/+Ii0/K/3yP0Ygthb/MjTFQvWeGAZOj2AIHEN6e4m hKPQ== 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:date :message-id:subject:from:to:cc; bh=tUSZsBfJ4YEx8+fcPwGqzoZvrO98zWhSG1Pg5FvDJEo=; b=jv1pcWYrcSQ7HlpvO9z93l+gh8bNrApC2TTG+xX9CMYxmFuo4Ko9DX81C6yxQNw9To g9alhUKoyV7C8dDlTcZA9voPfRcdSf7kwNURkBVsjKSclCAfFxlOhW9xWLLnnewfrMKJ T9Zvi16EkKz9sH9f0y4kB/+qUphkoT+f54q8RLdkHnFFebz+jkrcjrZbvSClNt2KAS8U z9FMTPny0hxz/lLoqk7WxUkEcDx2var6osWM5A5x+fiJWQZlPDsXyJZ3i7KGcWXbqI2J 4IXqhlbbJ8UPOmhvKxCkr2/QxwYFgst9iVyaKMTxihlO1CgiKkzad3Lc6V++1Et9Q+Oh +dhQ== X-Gm-Message-State: AD7BkJLIlBsnb89zQaNa3vXBro59RgGuG8uS/EMavrRTXF/e+orK5iPokk7hNL9KGUUvgjlcmVrjIL3xynmEmw== MIME-Version: 1.0 X-Received: by 10.13.226.86 with SMTP id l83mr2398812ywe.239.1456524055427; Fri, 26 Feb 2016 14:00:55 -0800 (PST) Received: by 10.13.216.138 with HTTP; Fri, 26 Feb 2016 14:00:54 -0800 (PST) Received: by 10.13.216.138 with HTTP; Fri, 26 Feb 2016 14:00:54 -0800 (PST) In-Reply-To: References: <30c15e55fd524e8bbba814f4898c3f95@ustx2ex-dag1mb1.msg.corp.akamai.com> <248E1E7C-72CB-4A20-B1E3-8CA051560FAC@azet.org> <56CE27D1.7060002@openfortress.nl> <984408eba26e6fd8474bfa45ec317ddc.squirrel@www.trepanning.net> Date: Fri, 26 Feb 2016 14:00:54 -0800 Message-ID: From: Watson Ladd To: Dan Harkins Content-Type: multipart/alternative; boundary=001a114fc152ee4882052cb36e55 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] SRP ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 22:00:58 -0000 --001a114fc152ee4882052cb36e55 Content-Type: text/plain; charset=UTF-8 On Feb 26, 2016 11:26 AM, "Dan Harkins" wrote: > > > On Thu, February 25, 2016 11:41 pm, Watson Ladd wrote: > > On Thu, Feb 25, 2016 at 11:33 PM, Dan Harkins wrote: > >> > >> Hi, > >> > >> On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote: > >>> Hi, > >>> > >>>> Although the lack of modern cipher-suites for SRP makes it not very > >>>> attractive these days. > >>>> > >>> Does anyone know if work on something like "ECSRP" is going on, > >>> anywhere? > >>> > >>> We've recently worked on getting it working with PKCS #11, > >>> > >>> https://github.com/arpa2/srp-pkcs11 > >>> https://github.com/arpa2/srp-pkcs11/blob/rfc5054_compat/doc/design/srp-pkcs11.pdf > >>> > >>> It could be interesting to see if this translates to the Elliptic Curve > >>> arena. > >>> > >>> I heard rumours of alternatives being weighed against one another, but > >>> failed to find anything concrete. Links are quite welcome! > >> > >> Well there's TLS-PWD. Works just fine with ECC. Also provides > >> for protection of the client username from passive attack. > >> > >> https://tools.ietf.org/html/draft-ietf-tls-pwd-07 > > > > As well as my SPAKE2 draft, which can fit in TLS easily. The real > > problem here is that there is no reason not to use certificates in a > > lot of cases. > > Well if you're using a browser I'd agree with you. But when TLS > is used to protect non-browser traffic there are plenty of cases > where you won't have an implicit trust anchor database or you're > going to some server administered by someone who most likely only > has a self-signed cert (Let's Encrypt makes it easy to get a cert > for a web server but, again, that's kind of browser-centric). > > I address the case for certificate-less authentication in section > 1.1 of the TLS-PWD I-D. The right solution is to make certificates easy. SSH solved this years ago. (Yes, I'm aware devices don't necessarily have a "trust anchor". Passwords assume enough input capacity to solve this probem.) > > regards, > > Dan. > > >> > >> Thanks for reminding me to update that draft :-) > >> > >> Dan. > >> > >>> -Rick > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >>> > >> > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > > > > > -- > > "Man is born free, but everywhere he is in chains". > > --Rousseau. > > > > --001a114fc152ee4882052cb36e55 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Feb 26, 2016 11:26 AM, "Dan Harkins" <dharkins@lounge.org> wrote:
>
>
> On Thu, February 25, 2016 11:41 pm, Watson Ladd wrote:
> > On Thu, Feb 25, 2016 at 11:33 PM, Dan Harkins <dharkins@lounge.org> wrote:
> >>
> >>=C2=A0 =C2=A0Hi,
> >>
> >> On Wed, February 24, 2016 1:59 pm, Rick van Rein wrote:
> >>> Hi,
> >>>
> >>>> Although the lack of modern cipher-suites for SRP mak= es it not very
> >>>> attractive these days.
> >>>>
> >>> Does anyone know if work on something like "ECSRP&qu= ot; is going on,
> >>> anywhere?
> >>>
> >>> We've recently worked on getting it working with PKCS= #11,
> >>>
> >>> https://g= ithub.com/arpa2/srp-pkcs11
> >>> https://github.com/arpa2/srp-pkcs11/bl= ob/rfc5054_compat/doc/design/srp-pkcs11.pdf
> >>>
> >>> It could be interesting to see if this translates to the = Elliptic Curve
> >>> arena.
> >>>
> >>> I heard rumours of alternatives being weighed against one= another, but
> >>> failed to find anything concrete.=C2=A0 Links are quite w= elcome!
> >>
> >>=C2=A0 =C2=A0Well there's TLS-PWD. Works just fine with EC= C. Also provides
> >> for protection of the client username from passive attack. > >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-ietf-tl= s-pwd-07
> >
> > As well as my SPAKE2 draft, which can fit in TLS easily. The real=
> > problem here is that there is no reason not to use certificates i= n a
> > lot of cases.
>
> =C2=A0 Well if you're using a browser I'd agree with you. But = when TLS
> is used to protect non-browser traffic there are plenty of cases
> where you won't have an implicit trust anchor database or you'= re
> going to some server administered by someone who most likely only
> has a self-signed cert (Let's Encrypt makes it easy to get a cert<= br> > for a web server but, again, that's kind of browser-centric).
>
> =C2=A0 I address the case for certificate-less authentication in secti= on
> 1.1 of the TLS-PWD I-D.

The right solution is to make certificates easy. SSH solved = this years ago.
(Yes, I'm aware devices don't necessarily have a "trust anchor= ". Passwords assume enough input capacity to solve this probem.)
>
> =C2=A0 regards,
>
> =C2=A0 Dan.
>
> >>
> >> Thanks for reminding me to update that draft :-)
> >>
> >>=C2=A0 =C2=A0Dan.
> >>
> >>> -Rick
> >>>
> >>> _______________________________________________
> >>> 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
> >
> >
> >
> > --
> > "Man is born free, but everywhere he is in chains".
> > --Rousseau.
> >
>
>

--001a114fc152ee4882052cb36e55-- From nobody Fri Feb 26 16:50:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAEE1B2E6E for ; Fri, 26 Feb 2016 16:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_32=0.6, SPF_PASS=-0.001] autolearn=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 gLP3RBBE016h for ; Fri, 26 Feb 2016 16:50:45 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FC531B34FA for ; Fri, 26 Feb 2016 16:41:44 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id l143so62995227lfe.2 for ; Fri, 26 Feb 2016 16:41:44 -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=LbIN/MtmbXlhyaSa2D2BzjOA5PIdaYMTa/Ogdja4S/c=; b=ei5wkM8RkULx6M+A+7Z8h/RnsJLbHjQExMIDPmzQZAefjbeUbUXFhcfSSe2esoJNjp +e56zy0wrSOUJ86kpNrbTYncotOLzUTCB8Tf0SDiOVxnZqAyJZke6C4hSFjRmYgIriIJ l/yxGHLpBLpQ3VcxwzDQB1wRtotjp2/5LDcWWEKWqheMHtZUBOHalJm9/d70ahb8vAYJ kt19zxqjKSKlD1NYTAWmqjYiCQSsPkjKgEDfcETrgyBiSKwUh26rjr5TG9ug1yhmTrID KDJMNtHrX/2TexzAPnpDXVKh1R2kbLEPPgmX+VDPjhB1DyGWV2pSF2h4QHkH5PqFyLHf f/GQ== 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=LbIN/MtmbXlhyaSa2D2BzjOA5PIdaYMTa/Ogdja4S/c=; b=afNmLyb4Kj/WA36Zq404d/ciu+HwWzQmBy9aBBCFxWtMt0NYFhjDrsyiv2Ss5b/Ham LywBkpDpgR6jMMFfGSTqVw6gxSDrve1VAgpIZv8okMTc00Tm1OuECOHSGmu+0WT5iMH+ 2VEPe0Fgiok+CQeNIV2S6ionZP7oGPsccTF1gS2d7cTcoQnNIWTte/tZOAUdRg5DoHKg YkM5wUHXNs30ySW4rPBpy9G6/eI+/tFf3QwFGHWkuOHAKF289XUB1WyuoZ0nE6rsKXSh beaEv9QrYdt8Y8TPUVS4gh+2gF0GVV5aTTL979TqnyGjIJ0dZDvmEXxh/v7uSkYv8e4p SlEQ== X-Gm-Message-State: AD7BkJIWw1mlHERGvVq73vS0i8/un2WEoQXqywiVy6OF7UffrJRDiAD7ysg62lr3/sKOkB/RbGxifcyea0Ildg== X-Received: by 10.25.39.6 with SMTP id n6mr1642606lfn.50.1456533702835; Fri, 26 Feb 2016 16:41:42 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.31.18 with HTTP; Fri, 26 Feb 2016 16:41:12 -0800 (PST) In-Reply-To: References: <35EE1C1C-132D-47A1-ADF3-5AD3C3D5EE4D@gmail.com> <20160225122954.9F45D1A43F@ld9781.wdf.sap.corp> From: Hugo Krawczyk Date: Fri, 26 Feb 2016 19:41:12 -0500 X-Google-Sender-Auth: uWCaTJ78V7ZiqkOV5kR0N9MtVbQ Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a11406fe2f60504052cb5ad30 Archived-At: Cc: Karthikeyan Bhargavan , "tls@ietf.org" Subject: Re: [TLS] 0.5 RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Feb 2016 00:50:47 -0000 --001a11406fe2f60504052cb5ad30 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 25, 2016 at 10:20 PM, Watson Ladd wrote= : > On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk > wrote: > > As I said in another email, without client authentication (which is the > > scenario in the Karthik quote), data sent by the server should be > considered > > secure only against passive adversaries. Any additional assumption on > > confidentiality (i.e., restricting the power of an active attacker) mus= t > > consider some form of client authentication, either implicit or explici= t. > > Both cases must be dealt with with care, especially the implicit ones > (e.g. > > authentication implied by application mechanisms and semantics). > > I think this is unnecessarily pessimistic/ignores the ways in which > higher-level applications may have authentication and what we need > from them. =E2=80=8BIt is not pessimistic - it says that you either assume some form o= f client authentication verified by the server, implicitly or explicitly, or otherwise the server can only treat its 0.5 data as open to active attacks. =E2=80=8B > The below should be taken as a clever guess, rather than > representative of the truth. > =E2=80=8BYou know that these intuitive argument *almost* always work. Problem is that all attacks are hiding behind the "almost" part ;-) I am not saying that something like this cannot be formalized, but it will not be easy, particularly since the ways of authentication are varied and depend on applications and semantics that are hard to reason about, let alone formalize mathematically. People can and will build on such assumptions but they should do that with a lot of care and with as much mathematical analysis behind it as possible. Hugo =E2=80=8B > > First, we know that negotiation doesn't work in 0-RTT. But that's ok: > we need to limit to only strong ciphers anyway, because negotiation > doesn't work/general depreciation. This means that clients can be > fooled by attackers into using the weakest notion they support for > continued authentication of PSKs: this applies to resumption with > tickets as well. > > We also know that each PSK is only shared between one server and one > other client from the unpredictability of the negotiated keys. And so > when when a server decrypts a ticket, it knows that whatever data it > saved in the ticket negotiated in the original negotiation applies to > whoever sent it this 0-RTT data, and it knows its response will go > only to someone who *at one point* sent this 0-RTT data. And so if > there is a cookie or url parameter authenticating the client that is > not tied to the PSK, so long as the PSK is secure there is only one > party that could have sent that cookie, and the response will go to > it. The same is true for prior client authentication, saved in the > ticket. > > Formalizing the above is likely to be a bit tricky, but I don't see > why it wouldn't be possible. > > > > > > > On Thu, Feb 25, 2016 at 7:29 AM, Martin Rex wrote: > >> > >> Karthikeyan Bhargavan wrote: > >> > > >> > Yes Hugo, you?re right that when there is no client auth, > >> > the situation is less problematic. > >> > >> I'm not so sure. > >> > >> There might be the desire of the server to keep some data confidential= , > >> and your argument is that if the data wasn't confidential to begin wit= h, > >> the server is not "breaking" confidentiality--although the server is > >> clearly doing this. > >> > >> But what about the client and the client's desire to keep confidential= , > >> which particular "public data" it is just requesting and receiving > >> from the server. > >> > >> > >> -Martin > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > --001a11406fe2f60504052cb5ad30 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Feb 25, 2016 at 10:20 PM, Watson Ladd <wa= tsonbladd@gmail.com> wrote:
On Thu, Feb 25, 2016 at 11:54 AM, Hugo Krawczyk <hugo@ee.technion.ac.il> wrote:<= br> > As I said in another email, without client authentication (which is th= e
> scenario in the Karthik quote), data sent by the server should be cons= idered
> secure only against passive adversaries. Any additional assumption on<= br> > confidentiality (i.e., restricting the power of an active attacker) mu= st
> consider some form of client authentication, either implicit or explic= it.
> Both cases must be dealt with with care, especially the implicit ones = (e.g.
> authentication implied by application mechanisms and semantics).

I think this is unnecessarily pessimistic/ignores the ways in which<= br> higher-level applications may have authentication and what we need
from them.

=E2= =80=8BIt is not pessimistic - it says that you either assume some form of c= lient authentication verified by the server, implicitly or explicitly, or o= therwise the server can only treat its 0.5 data as open to active attacks.<= /div>
=E2=80=8B
=C2=A0
The below should be taken as a clever guess, rathe= r than
representative of the truth.

=E2=80=8BYou know that these intuitive argument *almost* al= ways work.
Problem is that all at= tacks are hiding behind the "almost" part ;-)

I am = not saying that something like this cannot be formalized, but it will not b= e easy, particularly since the ways of authentication are varied and depend= on applications and semantics that are hard to reason about, let alone for= malize mathematically.

People can and will build on such as= sumptions but they should do that with a lot of care and with as much mathe= matical analysis behind it as possible.

Hugo
=
=E2=80=8B
=C2=A0

First, we know that negotiation doesn't work in 0-RTT. But that's o= k:
we need to limit to only strong ciphers anyway, because negotiation
doesn't work/general depreciation. This means that clients can be
fooled by attackers into using the weakest notion they support for
continued authentication of PSKs: this applies to resumption with
tickets as well.

We also know that each PSK is only shared between one server and one
other client from the unpredictability of the negotiated keys. And so
when when a server decrypts a ticket, it knows that whatever data it
saved in the ticket negotiated in the original negotiation applies to
whoever sent it this 0-RTT data, and it knows its response will go
only to someone who *at one point* sent this 0-RTT data. And so if
there is a cookie or url parameter authenticating the client that is
not tied to the PSK, so long as the PSK is secure there is only one
party that could have sent that cookie, and the response will go to
it. The same is true for prior client authentication, saved in the
ticket.

Formalizing the above is likely to be a bit tricky, but I don't see
why it wouldn't be possible.

>
>
> On Thu, Feb 25, 2016 at 7:29 AM, Martin Rex <mrex@sap.com> wrote:
>>
>> Karthikeyan Bhargavan wrote:
>> >
>> > Yes Hugo, you?re right that when there is no client auth,
>> > the situation is less problematic.
>>
>> I'm not so sure.
>>
>> There might be the desire of the server to keep some data confiden= tial,
>> and your argument is that if the data wasn't confidential to b= egin with,
>> the server is not "breaking" confidentiality--although t= he server is
>> clearly doing this.
>>
>> But what about the client and the client's desire to keep conf= idential,
>> which particular "public data" it is just requesting and= receiving
>> from the server.
>>
>>
>> -Martin
>
>
>
> _____________________________________= __________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



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

--001a11406fe2f60504052cb5ad30-- From nobody Sat Feb 27 09:54:06 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B56E31AD1BA for ; Sat, 27 Feb 2016 09:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] autolearn=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 fDitcjukKyI7 for ; Sat, 27 Feb 2016 09:53:57 -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 E2BAE1AD1A6 for ; Sat, 27 Feb 2016 09:53:56 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id g127so92649284ywf.2 for ; Sat, 27 Feb 2016 09:53:56 -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=TPVXiJ9kFONhzNfRJYEpnnxuSHot6vwCnRMOb3ZcnCI=; b=GdhJuxJ0NheKuTKyzXAfao9HeSg1U+WngAJW3I78EelgmBdoFmQf22dhlRQjXEjb7T DHOCGMCZypa3JIhuTtXzbwhOy97wZZV6QwCtpAptPW5aVnNpI1mjagZEsI9zksrc2oJ3 3xlJGVwdin2SuhUKrY4prU3fPiMoaXK88dKcQuS3M0s0UI/XtvxWfwNcIbREHIcWCNRz YHzUKHaXUyQF+I8n9TXeSSiulyKLgc0Rp5Z6p3MUnD6gm3v2tgZXGjmKzZOwfuM/rNy5 /wE6SV4Ms1aLNkiYa/OaLsjmdiT40qCFc8DO3NvqKDOxu6TfjB8xke+qrXj69bK8U6t/ 9IXg== 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=TPVXiJ9kFONhzNfRJYEpnnxuSHot6vwCnRMOb3ZcnCI=; b=QwZipoMq92wfaeUNOb1kkutJS+CVb/8weSeAq23pS0WiGAiBIB3DvNdiqkw4ab3L8N qVHO+Zx6/5Mxh+Z0ij3EEaKepEi3w+ExZwG4U/onL3bsNi0Fwia6tyCU9Hai5+Mxl2Dr 3vT9xtkFb1ngG2c/7GuteMO6P9DFATRvnxBkIYMjdwl/bPyn0s7xbZRV7CbqY9Rhg+WP wDAHEI1cbXZkBXrtRgTQQzWPUksHirCKwVs0CFqaBHXNQgrgDEhaiHorQsACgaylc/8z +sZsHD3Gu041jVd/SVIZAAjzfLWbABAIAdKDMtIPFHbnMR5hzD2N70xAAbX/imGwy96Z eNKQ== X-Gm-Message-State: AD7BkJJDNlB5vvhQapwiYWHziRawQbRnpUygMK19tAdTbotNbaDB4LFvtaSlTMCMnJwptVFoPwku8jRwuR6kzw== X-Received: by 10.13.221.132 with SMTP id g126mr4713181ywe.231.1456595636184; Sat, 27 Feb 2016 09:53:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.249.5 with HTTP; Sat, 27 Feb 2016 09:53:16 -0800 (PST) In-Reply-To: <20160226122425.GA32313@LK-Perkele-V2.elisa-laajakaista.fi> References: <20160226122425.GA32313@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Sat, 27 Feb 2016 09:53:16 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=94eb2c0613b87a1a26052cc41976 Archived-At: Cc: Dan Boneh , Philip Levis , Judson Wilson , Keith Winstein , Henry Corrigan-Gibbs , "Riad S. Wahby" , "tls@ietf.org" Subject: Re: [TLS] TLS 1.3 PR #426: KeyUpdate message: add receive_generation field X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 27 Feb 2016 17:53:58 -0000 --94eb2c0613b87a1a26052cc41976 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 26, 2016 at 4:24 AM, Ilari Liusvaara wrote: > On Fri, Feb 26, 2016 at 01:27:45AM -0800, Judson Wilson wrote: > > Hello folks, > > > > How this helps: In the current draft, an endpoint that sends a KeyUpdate > > message and later receives a KeyUpdate message cannot know whether the > > other side has actually updated its receive keys. The two messages may > have > > been generated independently and crossed in flight. Putting a > > receive_generation field in the KeyUpdate message lets an endpoint > confirm > > that the other side has received and acted upon an earlier KeyUpdate > > message. > > Well, the KeyUpdates are designed to be asynchronous so that the other > end does not need to know if the other has acted on KeyUpdate. That's correct. And would continue to be the case here. > One way for a client to grant delayed read-only access in TLS 1.3 is with > a > > "rotate and release." The client starts by sending a KeyUpdate. Later, > > after all traffic keys from the previous generation have been superseded > on > > both sides, the client releases the (superseded) traffic keys to the > > middlebox. The middlebox can use the keys to decrypt the previous > > generation of ciphertext, without danger of compromising the integrity of > > the session. The challenge is that an endpoint can't safely release its > old > > send keys until it knows that the other side has updated its receive > keys. > > Hence the receive_generation field. > > There are better (and less broken) ways to do this kind of thing > (involving two MACs). > I agree that there are arguably more elegant approaches if you are willing to change TLS. It seems like the argument here is that this doesn't require ay significant changes. > We think this is a pretty lightweight way to resolve the ambiguity from > > KeyUpdates crossing in flight; it doesn't add any blocking, waiting, or > > extra rounds or messages. Thanks in advance for any feedback. > > The KeyUpdate design is so that crossings don't matter. > FWIW, this seems like it would be harmless and not difficult to implement once you had KeyUpdate (since you need to keep count anyway). -Ekr > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0613b87a1a26052cc41976 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 26, 2016 at 4:24 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Fri,= Feb 26, 2016 at 01:27:45AM -0800, Judson Wilson wrote:
> Hello folks,
>
> How this helps: In the current draft, an endpoint that sends a KeyUpda= te
> message and later receives a KeyUpdate message cannot know whether the=
> other side has actually updated its receive keys. The two messages may= have
> been generated independently and crossed in flight. Putting a
> receive_generation field in the KeyUpdate message lets an endpoint con= firm
> that the other side has received and acted upon an earlier KeyUpdate > message.

Well, the KeyUpdates are designed to be asynchronous so that the oth= er
end does not need to know if the other has acted on KeyUpdate.
=

That's correct. And would continue to be the case h= ere.

=C2=A0

> One way for a client to grant delayed read-only access in TLS 1.3 is w= ith a
> "rotate and release." The client starts by sending a KeyUpda= te. Later,
> after all traffic keys from the previous generation have been supersed= ed on
> both sides, the client releases the (superseded) traffic keys to the > middlebox. The middlebox can use the keys to decrypt the previous
> generation of ciphertext, without danger of compromising the integrity= of
> the session. The challenge is that an endpoint can't safely releas= e its old
> send keys until it knows that the other side has updated its receive k= eys.
> Hence the receive_generation field.

There are better (and less broken) ways to do this kind of thing
(involving two MACs).

I agree that ther= e are arguably more elegant approaches if you are willing
to chan= ge TLS. It seems like the argument here is that this doesn't require
ay significant changes.


> We think this is a pretty lightweight way to resolve the ambiguity fro= m
> KeyUpdates crossing in flight; it doesn't add any blocking, waitin= g, or
> extra rounds or messages. Thanks in advance for any feedback.

The KeyUpdate design is so that crossings don't matter.

FWIW, this seems like it would be harmless and = not difficult to implement
once you had KeyUpdate (since you need= to keep count anyway).

-Ekr
=C2=A0

=C2=A0



-Ilari

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

--94eb2c0613b87a1a26052cc41976-- From nobody Mon Feb 29 06:45:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150111B3294 for ; Mon, 29 Feb 2016 06:45:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3xUOOVf0o_K for ; Mon, 29 Feb 2016 06:45:07 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d: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 3AC221B328E for ; Mon, 29 Feb 2016 06:45:07 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id x1so56925247qkc.1 for ; Mon, 29 Feb 2016 06:45:07 -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=PRYdOAQZIOe3ocdjor4Mp80cBWG/FUFxO1qDC+WI3/s=; b=BIaT+R2MNGbqEr75fvi/yH0vLk1IarcL4GmUn5ubgReFe+vAMeXXyPIGx5M8gvOBN2 e7gEXm2N6YpzYi1CrH8AgMyTM16vzZNIfcVMzro1RBY1Frw0etvA6eufsxZQ/hltpeyo TP1qkweC6LEY0Yf+3Kc/JdXIGUAlqrLNajHvM= 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=PRYdOAQZIOe3ocdjor4Mp80cBWG/FUFxO1qDC+WI3/s=; b=a0naXCYPzeK3QeUvRRzSrp7Vo/v/9RkCgdk3wMHmIhGTf6BqxKDwJ09cQ+BjlGWXRq 4dIezZPAf1xN71//nTdhmvQE8ieAd0ZBxmGy7ZFgJ0PUKLk/XZajvpgs4DormPPBEJO+ 7sF4aIsi1NMaVwWAkFPyUg3rTNO4CDadu6xkDj2eA1/pBnHhd6ng3dozLbW4g8lspbp6 VmimV0r/zCxTGDbOOgCSSQm8+EI5BxOu2AbhxRKwMYifJi+o2xQLcq/gML/Vvog009+H rJNUXfn5ZHUPexMU8zrDIZUNnkniSfUkYIBU4lw5syxZOXh8+vHVFiJUSHu2wJeKtbW4 zkvA== X-Gm-Message-State: AD7BkJIXQ4w+BNDOTL7ayZi6fR7mtLJVSFq+diYUICMwF3hqy+f84ydDKLn1u1SNhdj5oA== X-Received: by 10.55.78.84 with SMTP id c81mr19818010qkb.85.1456757105864; Mon, 29 Feb 2016 06:45:05 -0800 (PST) Received: from [172.16.0.112] ([96.231.217.211]) by smtp.gmail.com with ESMTPSA id j67sm11019126qgj.35.2016.02.29.06.45.05 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Feb 2016 06:45:05 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <84AEB140-D703-4AC0-91D7-02A01FD71A5A@sn3rd.com> Date: Mon, 29 Feb 2016 09:45:04 -0500 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [TLS] TLS1.3 status/expectations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 14:45:09 -0000 At the TRON workshop [0], we (Joe and Sean) were asked to provide our = views about the status and timeline for TLS 1.3; we wanted to share the = same information with the WG. Before that though, we want to thank the researchers for the time they = put into analyzing the protocol as well as the TRON Workshop sponsors. = The workshop was constructive and helpful. There are a number of groups = formally analyzing the protocol, some by hand and some with automated = tools, they=E2=80=99ve already discovered issues that we=E2=80=99ve = fixed [1]. The workshop made the following clear to us wrt TLS 1.3: o - Basically OK overall, but there was some sentiment that we should = only do 0-RTT with PSK (see recent list discussion). o - Some researchers prefer the key schedule that is currently = documented in the draft because it eases modular analysis of the = protocol. Others prefer the simplified proposals in [2,3]. We are hoping to be able to do a WGLC sometime shortly after Buenos = Aires (i.e., mid-April). Of course, this timeline is entirely dependent = on the WG reaching consensus on the remaining issues. At this point we are looking at reducing change to the protocol. We are = not looking to add any more features, removal of features and slight = changes that improve the protocol are still on the table. Obviously, if = we find any glaring issues we will fix them regardless. One thing that was reinforced at TRON and we think the TLS WG should be = aware of is that the research community needs time to do their analysis. = With that in mind, the chairs are very strongly leaning towards an = extended WGLC of 6 weeks. J&S [0] = https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or= -not-tron-workshop-programme [1] = https://mailarchive.ietf.org/arch/msg/tls/TugB5ddJu3nYg7chcyeIyUqWSbA [2] = https://mailarchive.ietf.org/arch/msg/tls/uUbeVDQwJuZO_bYhOWJRvlNlNtg [3] = https://mailarchive.ietf.org/arch/msg/tls/rgiTKwRb23T7iKjlkAQAt112ipY= From nobody Mon Feb 29 09:11:10 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066271B37F7 for ; Mon, 29 Feb 2016 09:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhkyuWuI4tkc for ; Mon, 29 Feb 2016 09:11:08 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51C0C1B37E5 for ; Mon, 29 Feb 2016 09:11:04 -0800 (PST) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 81EB42AC07; Mon, 29 Feb 2016 18:11:02 +0100 (CET) X-purgate-ID: 152705::1456765862-00003552-A056B62C/0/0 X-purgate-size: 592 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 mail05.wdf.sap.corp (Postfix) with ESMTP id 280F340F15; Mon, 29 Feb 2016 18:11:02 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1EB5C1A453; Mon, 29 Feb 2016 18:11:02 +0100 (CET) In-Reply-To: To: "Salz, Rich" Date: Mon, 29 Feb 2016 18:11:02 +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: <20160229171102.1EB5C1A453@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 29 Feb 2016 17:11:10 -0000 Salz, Rich wrote: > Absolute lifetimes seem more robust; e.g., if you find one lying around, > you don't have enough context to know if it's still good or not. > > We went from relative to absolute times in ACME for this reason. What should be memorized/stored is absolute time-of-creation. How long to consider it valid, is a local issue and not necessarily a constant validity period over time. When memorizing time-of-creation, you always know exactly how old something is, no matter whether how many times the local validity period was changed in the meantime. -Martin From nobody Mon Feb 29 09:15:25 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F5D91B37F3 for ; Mon, 29 Feb 2016 09:15:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6M1OBi5t-DrU for ; Mon, 29 Feb 2016 09:15:22 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 5306F1B37FB for ; Mon, 29 Feb 2016 09:15:20 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5791116BE3F; Mon, 29 Feb 2016 17:15:19 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 41E0616BDF7; Mon, 29 Feb 2016 17:15:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456766119; bh=cAZ2CZuuyW2o1f/9oQQfh8hv1g92+LKa6J44Eqr7jhU=; l=334; h=From:To:CC:Date:References:In-Reply-To:From; b=qx8EfgPYfPoRiKAOVhHQJgr9bQS+S4RJiFtGZTRIcbhN04Szrvd7AelZAe+9R0JF9 LgZzqcwYFvwsbPYgOXtfUSRCxgn1ioU6424P6ojg3l1QCkYzYmAc3ij+QB9aK/g14F fJ7PpwSSVWYkOw2uXotu+uBVcW5vhDBkmgdXZlGU= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 2616C98082; Mon, 29 Feb 2016 17:15:19 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Mon, 29 Feb 2016 12:15:18 -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.1130.005; Mon, 29 Feb 2016 12:15:18 -0500 From: "Salz, Rich" To: "mrex@sap.com" Thread-Topic: [TLS] Removing the "hint" from the Session Ticket Lifetime hint Thread-Index: AQHRcxQvwcrtO6b+8Em/JRVX41Ode59DQxwQ Date: Mon, 29 Feb 2016 17:15:18 +0000 Message-ID: References: <20160229171102.1EB5C1A453@ld9781.wdf.sap.corp> In-Reply-To: <20160229171102.1EB5C1A453@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.117.146] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 17:15:24 -0000 > What should be memorized/stored is absolute time-of-creation. If the structure itself includes absolute times, then the memorization is (= trivially) simpler. > How long to consider it valid, is a local issue and not necessarily a con= stant > validity period over time.=20 True. Treat it as a hint from the server.=20 From nobody Mon Feb 29 09:16:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BBE71B37D0 for ; Mon, 29 Feb 2016 09:16:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=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 o08aNhX-0zXH for ; Mon, 29 Feb 2016 09:16:55 -0800 (PST) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001: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 A8C5A1B3732 for ; Mon, 29 Feb 2016 09:16:55 -0800 (PST) Received: by mail-ig0-x236.google.com with SMTP id z8so82755220ige.0 for ; Mon, 29 Feb 2016 09:16:55 -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=bVhOrgG8PyFDTQfyhCc5c0/v10FVbN1lnO5JLFByPq0=; b=jq+H/fKJX5xuDEogqrEZgSypTZ9qOwsVBkPlhz4rw87DCf1R8a0oe6P4sC+XY2mZNw pq425tj64K2IR899p43W+EbQd30+WvjvTK4yl+dEvlew6HstGjtBxNaP6mMATF8QU9xK IJR73E0zvEu0QOuxFFYzWPMWhm6vJJP8/Jg58= 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=bVhOrgG8PyFDTQfyhCc5c0/v10FVbN1lnO5JLFByPq0=; b=ONAY0Ol1aWPK5IABaqDVIJ7Tz8ewXqfYOeuGeBdtNBVymLbWblsJTIWHB7607mdTmU 5WZdxHHcbGRGuxorE5KIQGflgpNMd0darF2cHk49cHjOXd/VgXzcQTjFKkC8ospI1IjZ Lk3PQF8Ahmt3kyBcPJXpexwt2ZH/HvLfeLC4O1s6iM1gtBM9/4apvK0r49vHMvH+6v8b HaIsNj9jjvTFsqc+e3cG4UH/uDR8Z7MR6ewJwqSA9tQ6rtDClt/r4asNUINQkedtqzNz ren2OWlV/Rynbk0RR4D815GlkAvFkgxHZwr++dbgeBwOGXKFwoCzdc1SvFXzXpmjwbFa jSIw== X-Gm-Message-State: AD7BkJJuvRB96vUVNosxFEVtnz4p0eJwvwUViEY7yE83q1aTbjX4FIsfqMtNHqdJsEXo/Xn4t7faxEK7qO9JMKAL X-Received: by 10.50.79.133 with SMTP id j5mr6523414igx.67.1456766214946; Mon, 29 Feb 2016 09:16:54 -0800 (PST) MIME-Version: 1.0 References: <201601152007.12464.davemgarrett@gmail.com> In-Reply-To: From: David Benjamin Date: Mon, 29 Feb 2016 17:16:44 +0000 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=047d7b15fae3c38996052cebd099 Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 17:16:57 -0000 --047d7b15fae3c38996052cebd099 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote: > On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin > wrote: > >> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett >> wrote: >> >>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote: >>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In >>> TLS >>> > 1.2, signature algorithms are spread across the handshake. >>> [...] >>> > I propose we fold the negotiable parameters under one name. >>> [...] >>> > 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm >>> as >>> > they are. Introduce a new SignatureAlgorithm u16 type and negotiate >>> that >>> > instead. >>> >>> I previously proposed this here: >>> https://www.ietf.org/mail-archive/web/tls/current/msg18035.html >>> >>> ekr was against it, though it hasn't been discussed that throughly. >>> https://www.ietf.org/mail-archive/web/tls/current/msg18036.html >> >> >> Ah, thanks! I must have missed this discussion. Or perhaps I saw it and >> forgot. >> >> ekr, are you still against this sort of thing? I think the new CFRG >> signature algorithms tying decisions together is a good argument for why >> we'd want this. If we believe this trend is to continue (and I hope it >> does. Ed25519 is a nice and simple interface), trying to decompose it all >> seems poor. >> > > I'm not sure. I agree that the CFRG thing seems to be a new development. > I'll > try to confirm my previous opinion or develop a new one over the weekend :) > ekr, did you have confirmed or new thoughts on this change? >From elsewhere in the thread, I put together a draft PR if you wanted something to look at in that form. https://github.com/tlswg/tls13-spec/pull/404 It incorporated some of the suggestions in the thread (not mentioning the really legacy values, pairing NIST curves with hashes, etc.), but that's not the important part. The meat of the proposal is unifying signature algorithms under one number and a shared interface, which I think is a valuable simplification. David --047d7b15fae3c38996052cebd099 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 15= , 2016 at 8:23 PM Eric Rescorla <ekr@rtfm.com> wrote:
On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin <davidben@chromium.or= g> wrote:
=
On Fri, Jan 15, 2016 at 8= :07 PM Dave Garrett <davemgarrett@gmail.com> wrote:
On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:=
> This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In T= LS
> 1.2, signature algorithms are spread across the handshake.
[...]
> I propose we fold the negotiable parameters under one name.
[...]
> 2. Remove HashAlgorithm, SignatureAlgorithm, SignatureAndHashAlgorithm= as
> they are. Introduce a new SignatureAlgorithm u16 type and negotiate th= at
> instead.

I previously proposed this here:
https://www.ietf.org/mail-archive/web= /tls/current/msg18035.html

ekr was against it, though it hasn't been discussed that throughly.
https://www.ietf.org/mail-archive/web/tls/current/msg180= 36.html

Ah, thanks! I must have missed this discussion. O= r perhaps I saw it and forgot.

ekr, are you still against this sort = of thing? I think the new CFRG signature algorithms tying decisions togethe= r is a good argument for why we'd want this. If we believe this trend i= s to continue (and I hope it does. Ed25519 is a nice and simple interface),= trying to decompose it all seems poor.

I'm not sure. I agree that the CFRG = thing seems to be a new development. I'll
try to confirm = my previous opinion or develop a new one over the weekend :)

ekr, did you have confirmed or new thoughts on this change= ?

From elsewhere in the thread, I put together a draft PR if you wan= ted something to look at in that form.
https://github.com/tlswg/tls13-sp= ec/pull/404
It incorporated some of the suggestions in th= e thread (not mentioning the really legacy values, pairing NIST curves with= hashes, etc.), but that's not the important part. The meat of the prop= osal is unifying signature algorithms under one number and a shared interfa= ce, which I think is a valuable simplification.

David
--047d7b15fae3c38996052cebd099-- From nobody Mon Feb 29 09:17:09 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 135F71B37F5 for ; Mon, 29 Feb 2016 09:17:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXDIOyhOFrDw for ; Mon, 29 Feb 2016 09:16:59 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB8E1B37F3 for ; Mon, 29 Feb 2016 09:16:59 -0800 (PST) Received: from [173.75.83.248] (helo=Williams-MacBook-Pro.local) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1aaRRA-0007Mq-Pu for tls@ietf.org; Mon, 29 Feb 2016 12:16:49 -0500 Date: Mon, 29 Feb 2016 09:16:50 -0800 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <84AEB140-D703-4AC0-91D7-02A01FD71A5A@sn3rd.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: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7996ac989a610eaa31f3d1d7395520bb09350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.248 Archived-At: Subject: Re: [TLS] TLS1.3 status/expectations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 17:17:01 -0000 On 2/29/16 at 6:45 AM, sean@sn3rd.com (Sean Turner) wrote: >One thing that was reinforced at TRON and we think the TLS WG=20 >should be aware of is that the research community needs time to=20 >do their analysis. With that in mind, the chairs are very=20 >strongly leaning towards an extended WGLC of 6 weeks. I strongly support giving the research community enough time to=20 analyze the protocol. Their methodology offers a different way=20 of looking at security issues, and has already demonstrated its=20 effectiveness at discovering protocol bugs. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345=20 Englewood Ave www.pwpconsult.com | - Jeff Frantz | Los Gatos,=20 CA 95032 From nobody Mon Feb 29 09:31:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BEAB1B384B for ; Mon, 29 Feb 2016 09:31:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1fN2ZINBdic for ; Mon, 29 Feb 2016 09:31:12 -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 20F251B384D for ; Mon, 29 Feb 2016 09:31:10 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C6F86284CDB; Mon, 29 Feb 2016 17:31:09 +0000 (UTC) Date: Mon, 29 Feb 2016 17:31:09 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160229173109.GI12869@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.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 17:31:15 -0000 On Tue, Feb 23, 2016 at 09:42:17AM -0800, Nick Sullivan wrote: > Draft 11 currently supports both ServerConfiguration and PSK + Session > Ticket for session resumption (0RTT or otherwise). Both mechanisms have the > same properties in terms of forward secrecy: a compromise of the server's > private data (whether PSK, session ticket key, or DH exponent) lets an > attacker retroactively decrypt data from all sessions established with the > PSK or Session Ticket. However, both mechanisms contain different language > around how the lifetimes of the resumption data is managed. > > After some discussion with Facebook and others, I'd like to suggest a > change in the wording of the draft to make the Session Ticket lifetime more > closely resemble the lifetime of the ServerConfiguration. IMHO the analogy between ServerConfiguration and SessionTicket is a flawed one. ServerConfiguration is created by the server unilaterally, at some time before the client connection and is not session-specific. The client has no implicit knowledge of the ServerConfiguration age. The situation is completely different with SessionTicket, which is created as a side-effect of the *current* handshake, and is always fresh when created. A SessionTicket lifetime hint that is a relative time is therefore quite sufficient and avoids clock synchronization and epoch time wrap-around problems. -- Viktor. From nobody Mon Feb 29 09:32:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7851B384B for ; Mon, 29 Feb 2016 09:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 vanmeRNTN9TM for ; Mon, 29 Feb 2016 09:32:26 -0800 (PST) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::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 057321B384A for ; Mon, 29 Feb 2016 09:32:26 -0800 (PST) Received: by mail-lb0-x22a.google.com with SMTP id x1so84221036lbj.3 for ; Mon, 29 Feb 2016 09:32:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=FsFGJlUBnvsvzXxxYE+TwvxOdfqVvV+090PV9Yl7KB8=; b=CpCrg0jK1MQaVmiqR9rcN4K8XX0GQ12j9a0repkU96SoFbLyopB2Wpm0saDjNxjfnO omXoQLn9awkti5UmU7DEDmc/nMr5Eq2X9JpNWPcg8MKAJzgynMqNXnfVjy+CsC8Vt3Sa 8yBfjzUmAr2vIHFNqTNyczR9EzfYsQ5RYqCRbswUlNhYhZqhPmkQ8hPBzJSEmW7/j1QE yd3bLp0OXnM8ptn3o5VF2vTMMjeBK5a1exNE9Q9lC3QNERK9RUxV7oBUiLVSrpC19qtB c1tNQw73mcAFGahjBnqU1CQM01mLQgnyRvU+++wnYUb9mCxSbqZfIaf09omjfzdsa/6v u5TA== 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=FsFGJlUBnvsvzXxxYE+TwvxOdfqVvV+090PV9Yl7KB8=; b=IXjvG9rArAI5zT0ePZpwPzs1eoeqCyA3Ff4JRE9vkCsW4c/T60GI3pvIQ5ASOkxCzF VhO8yzgpipYts6u4+KAEJ8UWBrm/Dt06ic8DV1mMTI/2GZrXnAOO6cVMzhoQlkeXdVWa vZ1iRj/ELT7Y/Y8idkFd5FHK/mC38wFS5EweXJmKqCJfb9Hu5GrQs1Dx7mv98qwZ7lI4 imkDQbueirnhoGEpX+4jVDiIiM+uh5ThtnjiHaTZNjCzzPSA5AG28D1ktnFTTsbe4Fju BeEZNdabkYpf3brWUWKNHoVP4URmEW9F+cWQXeTESrINfmci5ZqSc6soVLmzkaVq3STg vi8g== X-Gm-Message-State: AD7BkJIorBiQYlLxjZqN1PcXc1RY8H9xP9Ww6FurpFztNN9qB5Dd5ohZR4qYg5XPOhI39XEnsaBIalvjy3U0Jw== X-Received: by 10.112.16.168 with SMTP id h8mr5976274lbd.90.1456767144238; Mon, 29 Feb 2016 09:32:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.2.104 with HTTP; Mon, 29 Feb 2016 09:32:04 -0800 (PST) From: Joseph Salowey Date: Mon, 29 Feb 2016 09:32:04 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3acb2273458052cec080b Archived-At: Subject: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 17:32:27 -0000 --001a11c3acb2273458052cec080b Content-Type: text/plain; charset=UTF-8 We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5 in TLS 1.3. However, there is a problem that it may take some hardware implementations some time to move to RSA-PSS. After an off list discussion with a few folks here is a proposal for moving forward. We make RSA-PSS mandatory to implement (MUST implement instead of MUST offer). Clients can advertise support for PKCS-1.5 for backwards compatibility in the transition period. Please respond on the list on whether you think this is a reasonable way forward or not. Thanks, J&S --001a11c3acb2273458052cec080b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We seem to have good cons= ensus on moving to RSA-PSS and away from PKCS-1.5 in TLS 1.3.=C2=A0 However= , there is a problem that it may take some hardware implementations some ti= me to move to RSA-PSS.=C2=A0 After an off list discussion with a few folks = here is a proposal for moving forward. =C2=A0

We make RSA-PSS mandator= y to implement (MUST implement instead of MUST offer). =C2=A0 Clients can a= dvertise support for PKCS-1.5 for backwards compatibility in the transition= period. =C2=A0=C2=A0
Please respond o= n the list on whether you think this is a reasonable way forward or not. = =C2=A0

Thanks,

J&S
--001a11c3acb2273458052cec080b-- From nobody Mon Feb 29 09:35:59 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C39721A6FE0 for ; Mon, 29 Feb 2016 09:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=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 kEtDGJvZ5BkV for ; Mon, 29 Feb 2016 09:35:55 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C661A6FD9 for ; Mon, 29 Feb 2016 09:35:55 -0800 (PST) Received: from pps.filterd (m0044012.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.15.0.59/8.15.0.59) with SMTP id u1THZ7gc027135; Mon, 29 Feb 2016 09:35:54 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=facebook; bh=JvQK3/Ll8hdatEzjSPmIEH8S328KElEgwrOhJ6RIMxw=; b=OvVfGW1ehnxhuTd0BNIReHLT9Js6FiO+bopu4U/68BFrjWfqiZbyEDu45pJwDMYjUICw Tq+b2Jo60XUjtY8E5PcGYOXEsX3lAhP923iQ6h0RHoyHhzyA3GIFvd421ODXvMHirP7n mC5LDovmIlnrYLqKUYvhRTv/yJC8FOiwMCs= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 21csw6r6bt-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 29 Feb 2016 09:35:54 -0800 Received: from PRN-MBX01-4.TheFacebook.com ([169.254.3.151]) by PRN-CHUB01.TheFacebook.com ([fe80::d5cc:849:f520:db6b%12]) with mapi id 14.03.0248.002; Mon, 29 Feb 2016 09:35:53 -0800 From: Subodh Iyengar To: "Salz, Rich" , "mrex@sap.com" Thread-Topic: [TLS] Removing the "hint" from the Session Ticket Lifetime hint Thread-Index: AQHRbmGau7ZdmtJqV0qE3JnbE5+PR586lnoAgAAAjACACTqoAIAAATEA//97GaY= Date: Mon, 29 Feb 2016 17:35:52 +0000 Message-ID: <974CF78E8475CD4CA398B1FCA21C8E99564EB705@PRN-MBX01-4.TheFacebook.com> References: <20160229171102.1EB5C1A453@ld9781.wdf.sap.corp>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.52.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-02-29_06:, , signatures=0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 17:35:57 -0000 There are 2 different issues being discussed here, lifetime of tickets and = configs.=0A= =0A= It is probably better to revisit the discussion of whether or not to have S= erverConfig be relative or absolute after it is decided whether or not the = DH 0-RTT handshake will still exist.=0A= =0A= The general point I wanted to make is that relative times are practically e= nforceable by clients.=0A= For ticket_lifetime, which already is relative time, it is desirable to cha= nge them from an informative only behavior to being usable by clients, whic= h Nick's pull request does. Enforcing relative time for things like tls ti= cket validity time has better security properties for certain use cases lik= e key offloading. Nick's pull request limits the time clients can cache it = to 7 days which is reasonable middle ground and clients can decide to delet= e the ticket earlier.=0A= =0A= I +1 the pull request.=0A= =0A= Subodh Iyengar=0A= ________________________________________=0A= From: TLS [tls-bounces@ietf.org] on behalf of Salz, Rich [rsalz@akamai.com]= =0A= Sent: Monday, February 29, 2016 9:15 AM=0A= To: mrex@sap.com=0A= Cc: tls@ietf.org=0A= Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hin= t=0A= =0A= > What should be memorized/stored is absolute time-of-creation.=0A= =0A= If the structure itself includes absolute times, then the memorization is (= trivially) simpler.=0A= =0A= > How long to consider it valid, is a local issue and not necessarily a con= stant=0A= > validity period over time.=0A= =0A= True. Treat it as a hint from the server.=0A= =0A= _______________________________________________=0A= TLS mailing list=0A= TLS@ietf.org=0A= https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman= _listinfo_tls&d=3DCwICAg&c=3D5VD0RTtNlTh3ycd41b3MUw&r=3Dh3Ju9EBS7mHtwg-wAyN= 7fQ&m=3DqqjUPIB9UGopotanCAwZnp0-jzGVYglIQZJF_t3gzPA&s=3D-sv0ZsIso_1M3gqRtmL= NdhvCr50uDuFVHhzZro2d4j8&e=3D=0A= From nobody Mon Feb 29 09:39:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0538A1B386B for ; Mon, 29 Feb 2016 09:39:47 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6r1HLFnEO76J for ; Mon, 29 Feb 2016 09:39:46 -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 05CC61B386A for ; Mon, 29 Feb 2016 09:39:45 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1F22D284CDB; Mon, 29 Feb 2016 17:39:45 +0000 (UTC) Date: Mon, 29 Feb 2016 17:39:45 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160229173944.GK12869@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.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 29 Feb 2016 17:39:47 -0000 On Mon, Feb 29, 2016 at 09:32:04AM -0800, Joseph Salowey wrote: > We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5 > in TLS 1.3. However, there is a problem that it may take some hardware > implementations some time to move to RSA-PSS. After an off list discussion > with a few folks here is a proposal for moving forward. > > We make RSA-PSS mandatory to implement (MUST implement instead of MUST > offer). Clients can advertise support for PKCS-1.5 for backwards > compatibility in the transition period. > Please respond on the list on whether you think this is a reasonable way > forward or not. My instinct is to mandate PSS and let PKCS#1 rest in peace. -- Viktor. From nobody Mon Feb 29 10:00:29 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72B4A1B3924 for ; Mon, 29 Feb 2016 10:00:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.898 X-Spam-Level: * X-Spam-Status: No, score=1.898 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 A5tID4rBxXGE for ; Mon, 29 Feb 2016 10:00:25 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76F9C1B3918 for ; Mon, 29 Feb 2016 10:00:25 -0800 (PST) Received: from pc1 (0x3ec7a9e1.inet.dsl.telianet.dk [::ffff:62.199.169.225]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 29 Feb 2016 19:00:22 +0100 id 00000000000000A4.0000000056D48736.000078B8 Date: Mon, 29 Feb 2016 19:00:21 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20160229190021.59516808@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-30904-1456768822-0001-2" Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 18:00:27 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-30904-1456768822-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 29 Feb 2016 09:32:04 -0800 Joseph Salowey wrote: > We make RSA-PSS mandatory to implement (MUST implement instead of MUST > offer). Clients can advertise support for PKCS-1.5 for backwards > compatibility in the transition period. > Please respond on the list on whether you think this is a reasonable > way forward or not. I recently already saw the message here asking for PKCS #1 1.5 compatibilty and was quite angry about it, but as there wasn't much discussion I thought this issue would go away. It seems it did not. RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago. Therefore we can conclude: * Whoever created that hardware implementation either did so more than 13 years ago (probably unlikely) or deliberately created hardware crypto with sub-standard algorithm support. * This can mean a couple of things: a) The hardware vendor knew about it and expected that they could prevent a move to RSA-PSS by lobbying standardization bodies (this is what they seem to do right now). In this case they deliberately want to weaken security and that behavior should not be encouraged. b) They didn't know about RFC 3447. That probably means they shouldn't develop crypto products at all. c) Something else? whatever the reason was, I can't find any reason I would find in any way acceptable. I think the TLS working group should not encourage such vendor behavior. Instead I think the opposite should happen: A clear statement that deploying sub-standard crypto technologies isn't acceptable and whoever does it has to expect breakage in the future. TLS suffered a lot in the past from misguided attempts to provide backwards compatiblity to weak algorithms. Most of the fancy named vulns in the past years can somehow be traced back to this problem. PKCS #1 1.5 is a real problem. The last PKCS #1 1.5 signature related vuln that could've been prevented by using RSA-PSS was found 2 months ago [1]. The last one in a major implementation (BERserk) was in 2014. tl;dr: I don't think supporting PKCS #1 1.5 in TLS 1.3 is reasonable. Let's not repeat the mistakes from the past. [1] https://blog.filippo.io/bleichenbacher-06-signature-forgery-in-python-rsa/ --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-30904-1456768822-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW1Ic1AAoJEKWIAHK7tR5CWHYP/ilgQvazBbXaKc7GeUQWR2PR Te9cmO0PED43pohnpSRsvF0wJfCbie3hN303gDVrToruPkjYJbGc2Aia8RiOpBFX 5IlYHJITXYyPD8o2rVOtmf5uDbvstLscPIrYiRrXMATDv30cdmY96dgVCXWaniaG oUnuOTidd2jo2tdZk9fBYWEGBn+lBCK1dR3JBPnWo5vUkdH1I1w8nVhTzbtGqYQD w+API0BXFz9ILnVZiq9uj50oykEJIRxkt9QGSJW1n5sVV2UimR9LNSv7/2oM2Eh+ 1mVMGoB2hMyI8aS+5YociX911hzrJfQzuw53/i8FkgaggoHlxOrD1Zaft/m4i07V rG2LvQ/Wmti9K3YEvhFmtWN4iWmKV46fh+ob5doZJk4B5XfY/5D0ZgjRHO6oCTou WWBxNLNAnuKWYjq0qkU3FjKfcooChYRr4wrhTwoItM3O2EYVJ4sGmUmEqY3UiU6j q1o7ezdxKTU78MzAqBxaPvhLT/qpha83MXdmh7YZomMgcl1TAg3ufbgGQjpEoO7j 7hASDAESgZP9e0VBQzxIhKDHEWmghDhRC5AfkVfcelzlfFFrHA5pd6HmzlsI4tyH PtbQFrC2sli1Vds+3QdEfTsH8XH3CW4UcXe87xWtzCDsgLQHj9GujLGH3dHcZIlj lbUYMEwiWafN9cXWwL/k =PrkQ -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-30904-1456768822-0001-2-- From nobody Mon Feb 29 10:11:02 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19FE81B3927 for ; Mon, 29 Feb 2016 10:11:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.856 X-Spam-Level: X-Spam-Status: No, score=-4.856 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R1XHgAV9UiRB for ; Mon, 29 Feb 2016 10:10:59 -0800 (PST) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BE501B342E for ; Mon, 29 Feb 2016 10:10:59 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.22,521,1449529200"; d="scan'208";a="166378491" Received: from unknown (HELO [10.175.84.30]) ([37.163.148.253]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2016 19:10:57 +0100 References: <20160229190021.59516808@pc1> Mime-Version: 1.0 (1.0) In-Reply-To: <20160229190021.59516808@pc1> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <54D9A4D3-98A1-4C5D-A5BE-F880C4F80FD7@inria.fr> X-Mailer: iPhone Mail (13D15) From: Benjamin Beurdouche Date: Mon, 29 Feb 2016 19:10:54 +0100 To: =?utf-8?Q?Hanno_B=C3=B6ck?= Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 18:11:01 -0000 > PKCS #1 1.5 is a real problem. The last PKCS #1 1.5 signature related > vuln that could've been prevented by using RSA-PSS was found 2 months > ago [1]. The last one in a major implementation (BERserk) was in 2014. >=20 > tl;dr: I don't think supporting PKCS #1 1.5 in TLS 1.3 is reasonable. > Let's not repeat the mistakes from the past. I agree, we started 1.3 by removing old and deprecated stuff. We should not a= llow it now and risk weakening our work... B.= From nobody Mon Feb 29 10:42:48 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4771B39C7 for ; Mon, 29 Feb 2016 10:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.006] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABHggRqlvhYS for ; Mon, 29 Feb 2016 10:42:44 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id B12541B39CA for ; Mon, 29 Feb 2016 10:42:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 290935F96; Mon, 29 Feb 2016 20:42:39 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 9ssBT8Q94fZg; Mon, 29 Feb 2016 20:42:37 +0200 (EET) Received: from LK-Perkele-V2 (87-100-151-39.bb.dnainternet.fi [87.100.151.39]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id E0E772310; Mon, 29 Feb 2016 20:42:37 +0200 (EET) Date: Mon, 29 Feb 2016 20:42:32 +0200 From: Ilari Liusvaara To: David Benjamin Message-ID: <20160229184232.GA3057@LK-Perkele-V2.elisa-laajakaista.fi> References: <201601152007.12464.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Sender: ilariliusvaara@welho.com Archived-At: Cc: ekr , "tls@ietf.org" Subject: Re: [TLS] Simplifying signature algorithm negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 18:42:47 -0000 On Mon, Feb 29, 2016 at 05:16:44PM +0000, David Benjamin wrote: > On Fri, Jan 15, 2016 at 8:23 PM Eric Rescorla wrote: > > > > I'm not sure. I agree that the CFRG thing seems to be a new development. > > I'll > > try to confirm my previous opinion or develop a new one over the weekend :) > > > > ekr, did you have confirmed or new thoughts on this change? > > >From elsewhere in the thread, I put together a draft PR if you wanted > something to look at in that form. > https://github.com/tlswg/tls13-spec/pull/404 > It incorporated some of the suggestions in the thread (not mentioning the > really legacy values, pairing NIST curves with hashes, etc.), but that's > not the important part. The meat of the proposal is unifying signature > algorithms under one number and a shared interface, which I think is a > valuable simplification. I think that changing the algorithm negotiation would make it both simpler and more reliable. Current TLS signature negotiation is not able to express real-world constraints (matching of curve and hash[1]). Also, I think the ranging should be as follows: - 01xx: Avoid (would be insecure) - 02xx: Avoid (would be insecure) - 03xx: Avoid (who uses this hash?) - 04xx: Schemes that sign SHA-256 hash - 05xx: Schemes that sign SHA-384 hash - 06xx: Schemes that sign SHA-512 hash - xx00: Avoid ("Anonymous" looks like a mistake) - xx01: Avoid (RSA-PKCS1-v1.5 is obsolete) - xx02: Avoid (DSA is obsolete) - xx03: ECDSA with new hashes - Others: Other schemes Which would allocate the new things as follows (from what I understand RSA-PSS works): - 0404: RSA-PSS/SHA256 - 0504: RSA-PSS/SHA384 - 0604: RSA-PSS/SHA512 - 0004: Ed25519 - 0005: Ed448 Valid for TLS 1.2 and up. [1] This isn't about algorithm strength matching, it is about interop. -Ilari From nobody Mon Feb 29 10:50:54 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F040E1B39F7 for ; Mon, 29 Feb 2016 10:50:50 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A6Z6NKp1BcKz for ; Mon, 29 Feb 2016 10:50:49 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53C0E1B39C8 for ; Mon, 29 Feb 2016 10:50:49 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id l68so2449658wml.1 for ; Mon, 29 Feb 2016 10:50:49 -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 :content-transfer-encoding:message-id:references:to; bh=NlfAMGwrgq9oS328oHq1T65sODuEo/rsnjuNUmHzVHs=; b=hYjpGOSnXG/7tYQsNkKJKcBTklDUX1yj80XpmHaNdaJvyaAzKG1C5QYbglweFXAL+a q28z4KK8qEOBAFh86w6ss3RYlTcy9FviJ3TI2j3RXytvLLPlhcZ/CTPDUJtr/rl7lMz5 7h2hSv/GWEXKZCIxcp2ozJCHASXb2xgNBrVt7OyE0NvG8QaOs3U+q06djcL20A18e1/N Or7FIitRPzLXbLG8fbH6kmjDOG56STDNDNGxJZM8K/q9cg5LTJEXPd5BYqPsZk/T9cBS G8SL0i+A+X+S62N77Ic7xlf7Akzl4HHtKCUZjpUq1d3oFrdFpND2baVjoGwR1vk7kfGK krJQ== 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=NlfAMGwrgq9oS328oHq1T65sODuEo/rsnjuNUmHzVHs=; b=W4HTVn3sdImA+ygfsB+j2HBt3wd0en9/bbV9lH3HIDZd4RVx4EDSWzScT5bbBIk8vc EJNnVftIQLsXiBd1jP1Zk1vKGTRpYU++yb/jUrqucsOCCovAGmZK6VSQAcptoImZMeJ6 +nRlonHvmmSK6af9kxlFQN/1LVTlXtbur/drK9/6b0JCrzG9TuEnVjQ6RbJC3xSghVOe 7ZqhG2/ffUgfSmVPxaHC/iJoNM52XIC3ozFvueKOMVr6fE0Q1e06rogvkH71ahJcnoqk TabF0uye1cVC/qnoK5kmevRuqQrShUmLjxQfzFHwvQnW5Qf+QNgsDEPVpjwkf3usg0Lg 8x4g== X-Gm-Message-State: AD7BkJJ98vOA3ZDO0YwvtLzc9rIX4ETPeZEwisCnKgPFawjKnqNwWDAzt2Yh2AN7fXCJOQ== X-Received: by 10.194.60.165 with SMTP id i5mr19501483wjr.178.1456771847894; Mon, 29 Feb 2016 10:50:47 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id i1sm27077366wjs.45.2016.02.29.10.50.46 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Feb 2016 10:50:47 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <20160229173944.GK12869@mournblade.imrryr.org> Date: Mon, 29 Feb 2016 20:48:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20160229173944.GK12869@mournblade.imrryr.org> To: tls@ietf.org X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 18:50:51 -0000 > On 29 Feb 2016, at 7:39 PM, Viktor Dukhovni = wrote: >=20 > On Mon, Feb 29, 2016 at 09:32:04AM -0800, Joseph Salowey wrote: >=20 >> We seem to have good consensus on moving to RSA-PSS and away from = PKCS-1.5 >> in TLS 1.3. However, there is a problem that it may take some = hardware >> implementations some time to move to RSA-PSS. After an off list = discussion >> with a few folks here is a proposal for moving forward. >>=20 >> We make RSA-PSS mandatory to implement (MUST implement instead of = MUST >> offer). Clients can advertise support for PKCS-1.5 for backwards >> compatibility in the transition period. >> Please respond on the list on whether you think this is a reasonable = way >> forward or not. >=20 > My instinct is to mandate PSS and let PKCS#1 rest in peace. +1 As always, certificates are fine to be signed with PKCS#1, because we = are not specifying certificate signatures, but in-protocol signatures = *are* up to us.=20 Yoav From nobody Mon Feb 29 10:53:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD561B39E9 for ; Mon, 29 Feb 2016 10:53:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=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 1lVwxbQk-S99 for ; Mon, 29 Feb 2016 10:53:38 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D541B39C8 for ; Mon, 29 Feb 2016 10:53:37 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id n186so2793038wmn.1 for ; Mon, 29 Feb 2016 10:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc:message-id:references :to; bh=NPfxJsuvWO2Ua7f4+RnFLTZeLfbZbempq5JNe1292CQ=; b=qwWlq6vweKKVTZCTE78guhsOM4csdDkc8bisBgMlg9Jh5JjqQZ5Q6PkaiQd9CwGQdG 4R1mU0xc1Fqzu5EOiG9IeyAWW6AzpilMCKiSRkDNFDs8h2ttw09/R4O7DtKLxkqUMpCG zSpmSzRVGEg1lt6mH+7GlKq3bSsKhH6FZLoQChuNTJGkckygNcxMOFU3LurXuFMtRiwc pOU3XYzQjih40Og86k8YAfFHc9R65NfYz/DEzlgf94XmiAJ70UWsvyz+SvFbtKeoSLhC xzWPTjgPHCOf2HinGrerBAOdD6MBa2/OG2zmR1nlM2/cxJspBfUGpGpZ/ikejRPUrQtB CwZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :message-id:references:to; bh=NPfxJsuvWO2Ua7f4+RnFLTZeLfbZbempq5JNe1292CQ=; b=eJJrL37hYwoHofllPQFBTQq6qfs3EqVPrh6K2vkMhBKpeywqwyz3uxWUorFokG72w2 k89NMFCVafLNAESZvU0+2gzUHeckfFCj2ILtu1vfM8i8B19iVareUWIeuqNppLwpJa8/ auEVtcNHf2BRDk3aHCxbF5vDCavgYDumkTwarvaxKx2DzQsSxR/a+RG4p11f+vnG88tp M0XHkgNJv7dEABAMYP9cg1j43A9s3up9UOPgDunOpVs88L5C5F8fiOEykpqcz2LE1uLE T5mYzW7ira6thsQuTMJIwhMapfbMue8HtmQUC3RAmgiHdJUPpx6IuEnw+rfbkOtBfNE7 WvmA== X-Gm-Message-State: AD7BkJKS0vY3ELwuZA+U3XGNNzaLodrfb7yobtEV2SHLgpp4NnN0BzJYAGHsybXMjqZfrw== X-Received: by 10.194.184.234 with SMTP id ex10mr15643534wjc.8.1456772016470; Mon, 29 Feb 2016 10:53:36 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id 74sm17758519wmn.17.2016.02.29.10.53.35 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 29 Feb 2016 10:53:35 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: multipart/signed; boundary="Apple-Mail=_1698864B-30BF-4FB0-9CD0-EE54A7D68B28"; protocol="application/pgp-signature"; micalg=pgp-sha256 X-Pgp-Agent: GPGMail 2.6b2 From: Yoav Nir In-Reply-To: <20160229190021.59516808@pc1> Date: Mon, 29 Feb 2016 20:53:33 +0200 Message-Id: <88D3CE68-E034-4433-8EA2-B09AC8801E6B@gmail.com> References: <20160229190021.59516808@pc1> To: =?utf-8?Q?Hanno_B=C3=B6ck?= X-Mailer: Apple Mail (2.3112) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 18:53:39 -0000 --Apple-Mail=_1698864B-30BF-4FB0-9CD0-EE54A7D68B28 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 29 Feb 2016, at 8:00 PM, Hanno B=C3=B6ck wrote: >=20 > On Mon, 29 Feb 2016 09:32:04 -0800 > Joseph Salowey wrote: >=20 >> We make RSA-PSS mandatory to implement (MUST implement instead of = MUST >> offer). Clients can advertise support for PKCS-1.5 for backwards >> compatibility in the transition period. >> Please respond on the list on whether you think this is a reasonable >> way forward or not. >=20 > I recently already saw the message here asking for PKCS #1 1.5 > compatibilty and was quite angry about it, but as there wasn't much > discussion I thought this issue would go away. It seems it did not. >=20 > RSA-PSS was specified as RFC 3447 in 2003. That was 13 years ago. >=20 > Therefore we can conclude: > * Whoever created that hardware implementation either did so more than > 13 years ago (probably unlikely) or deliberately created hardware > crypto with sub-standard algorithm support. > * This can mean a couple of things: > a) The hardware vendor knew about it and expected that they could > prevent a move to RSA-PSS by lobbying standardization bodies (this is > what they seem to do right now). In this case they deliberately want = to > weaken security and that behavior should not be encouraged. > b) They didn't know about RFC 3447. That probably means they shouldn't > develop crypto products at all. > c) Something else? Yeah, such as all of their customers are using PKCS#1 because that is = what everybody uses in all current versions of TLS and several other = protocols? Regardless, hardware vendors should rejoice. We=E2=80=99re giving their = customers a good reason to buy new hardware. Yoav --Apple-Mail=_1698864B-30BF-4FB0-9CD0-EE54A7D68B28 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJW1JOtAAoJECXR4BOacZZUHEsIAI0RTObBu/3AOEjukq51d6Hy R1yuKnTRlcTCqAom96TXbeRDkGcvnaJ1N11QuToMcPynZBbdzdPbwMhFbjld+VN8 1NH4Sryxe9BepxBcvvrJ5CzqfrqHHcohTlmNDQ70jQauwepC+jtOvFvQiHtioppQ uDXedkWibuBXrsGlFlQu1EUF4rKjjVfCqTRoz2jAI/by7OYsEFACxrKfMi1Ndk8A ETxZPFm1qgYnz6AQ67Q3DdpdfQJR+EUIUHl9kZscL7+iGzCueTBHTB3JAriCKyPP S++G4noWRdtGvJBL2Un++f+K5BeTkB1sXoSBmRavlRTh6jgpHfJJX85sEEg2TLI= =/Gjn -----END PGP SIGNATURE----- --Apple-Mail=_1698864B-30BF-4FB0-9CD0-EE54A7D68B28-- From nobody Mon Feb 29 11:01:04 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821571B39C3 for ; Mon, 29 Feb 2016 11:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=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 CtxbN4lXQKa4 for ; Mon, 29 Feb 2016 11:01:01 -0800 (PST) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::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 59EAA1B39ED for ; Mon, 29 Feb 2016 11:00:55 -0800 (PST) Received: by mail-ob0-x234.google.com with SMTP id xx9so30709255obc.2 for ; Mon, 29 Feb 2016 11:00:55 -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:date:message-id:subject:from:to :cc; bh=FaHLXHOaPDEmnnsJOJsbPS8gU1YJkXktRZpHyUzpvbg=; b=djLERGq6CCyIFkWmXZeyQuFkWkvmb5vsQKdcwGoE2JH0FBWNLMnRbganAREISaf4qc 9OYlylzCSw/GG5JX1vAj3MUaktAoqRlPONs0uG0tTatdJPvrK+F5GvgFnvp2Uzf03FxI FgT42bWl6aIMNuX9Qv0tZWg06bZ3TG7RBlAEBVl85YeKeRCjl9sZk9gWXVs4upl3+cDk Mh77iEnndQhLuUMuREdOm2wbXt/dQnzOV8LCZg7O0ir5I/yHAkTuQecXNheHrx/Bexyx T/kyz/Rr7T6SKtWNSLL/6iJ2t7d5DNjcCPooNryQ8NV2V8cgf8lv5CYN0inwFFpLdsOZ oHdA== 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:date :message-id:subject:from:to:cc; bh=FaHLXHOaPDEmnnsJOJsbPS8gU1YJkXktRZpHyUzpvbg=; b=heE/v2aN1Y3WqgS4uo9t/DitqvmcOA1Bo/eVXtGqo7h9p5kNJGrl5fDDLH/Mi9U8qd MF+tJz9UB1fPisGU7lhJ4A1wS6TJN2xm7aij4SyCqwGgIQuVp0gp3eczD4kP84FaMP0E IroCU9kl4me36R95A5f7/t+gsGe1H3i5F24zzTSXRk+0Ncx2BGTChDTNMTeq6+T37KyO /OrYkIoFBOXY1Fdb2/WlRjTFHWs17CExRy+yhKr89EG6+yjp52IHXX0yN3zGmZvp55QI ym2eY9VIId/ZYMihQSJS+u6Dt10i4W41eIn+CyBQWKaWl828JIJ1Owl4XrBj/UnXDfFF RF2w== X-Gm-Message-State: AD7BkJLQxrmUhV8q/EWvH7QrQyNe7x/P7Ih8hH2Q8X0BuEW+kvNqtj7MS1enc5aXExZFIFATyKwqNhULQlHRHQ== MIME-Version: 1.0 X-Received: by 10.60.220.230 with SMTP id pz6mr13592165oec.49.1456772454640; Mon, 29 Feb 2016 11:00:54 -0800 (PST) Received: by 10.76.37.231 with HTTP; Mon, 29 Feb 2016 11:00:54 -0800 (PST) In-Reply-To: References: Date: Mon, 29 Feb 2016 09:00:54 -1000 Message-ID: From: Brian Smith To: Joseph Salowey Content-Type: multipart/alternative; boundary=001a11367c2ead8948052ced4409 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 19:01:03 -0000 --001a11367c2ead8948052ced4409 Content-Type: text/plain; charset=UTF-8 Joseph Salowey wrote: > We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5 > in TLS 1.3. However, there is a problem that it may take some hardware > implementations some time to move to RSA-PSS. After an off list discussion > with a few folks here is a proposal for moving forward. > > We make RSA-PSS mandatory to implement (MUST implement instead of MUST > offer). Clients can advertise support for PKCS-1.5 for backwards > compatibility in the transition period. > Please respond on the list on whether you think this is a reasonable way > forward or not. > I agree with the others that TLS should use exclusively RSA-PSS (with all the parameters fixed according to the digest function used to digest the data) when RSA is used in the protocol. Implementations that can't support PSS in hardware can either implement it in software or use ECDSA or keep on using TLS 1.2. Cheers, Brian -- https://briansmith.org/ --001a11367c2ead8948052ced4409 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Jose= ph Salowey <joe@salowey.net> wrote:
We seem to have good consensus= on moving to RSA-PSS and away from PKCS-1.5 in TLS 1.3.=C2=A0 However, the= re is a problem that it may take some hardware implementations some time to= move to RSA-PSS.=C2=A0 After an off list discussion with a few folks here = is a proposal for moving forward. =C2=A0

We make RSA-PSS mandatory to = implement (MUST implement instead of MUST offer). =C2=A0 Clients can advert= ise support for PKCS-1.5 for backwards compatibility in the transition peri= od. =C2=A0=C2=A0
Please respond on the= list on whether you think this is a reasonable way forward or not. =C2=A0<= /div>

I agree with the others that TL= S should use=C2=A0exclusively=C2=A0RSA-PSS (with all the parameters fixed a= ccording to the digest function used to digest the data) when RSA is used i= n the protocol. Implementations that can't support PSS in hardware can = either implement it in software or use ECDSA or keep on using TLS 1.2.

Cheers,
Brian
--
--001a11367c2ead8948052ced4409-- From nobody Mon Feb 29 11:04:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 666C41B3A1F for ; Mon, 29 Feb 2016 11:04:49 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THiaAxsjX22t for ; Mon, 29 Feb 2016 11:04:44 -0800 (PST) Received: from mail-pa0-x235.google.com (mail-pa0-x235.google.com [IPv6:2607:f8b0:400e:c03::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 D6D401B3A19 for ; Mon, 29 Feb 2016 11:04:43 -0800 (PST) Received: by mail-pa0-x235.google.com with SMTP id fy10so96478648pac.1 for ; Mon, 29 Feb 2016 11:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainhub-org.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=axTRso0TJPYaQxrdKLhxqchH22ZHhZX0e8cibH7v0Wg=; b=hrSVHVDSD91NC8AdrMQMd1hdovUiZsoNlX02Uz3Vt2LsIyVXH1tQyNeiaMdR/d6W8v rwFVwin60diAPRxqB/K49lOeHqTPRgS82jl/1+AshVhcSjvX/EnWT+5GJAc1QsIBfSRS POwXDrqZwBFh0J4p2gOgyOVC+GdefL6AvsXwv4Jprm/RBCK9mG6VdShkBiGyDueC2JFZ CRku5Pimv3M6p3ZqdQvxYl0kFwHMaUUHzU744Nbf5+0ah220uUIW5qkdE/Kj2+BMsjEt SXbwh4SWcOR62vLy33+ycT3vKtkLsN4z8V1sVJ9133PyftyTRdrX3MNaiBADt4cyMh6k uHWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:from:message-id :date:user-agent:mime-version:in-reply-to; bh=axTRso0TJPYaQxrdKLhxqchH22ZHhZX0e8cibH7v0Wg=; b=OJpS+VK1Upw4u60ndtgtPaMAbMnYHBkOtMlkOwiJUQwEiY6jpQaNdlDWmP7Yvs8kyw VYGk2nTr3ZT9OjijNY/UTIdDxvV3LQpFLAAQDvRKq1VWa0CpY8qsMkPuVFZ3sTpw/UXK PzmoB6D7/2cZhUYHb6MTeAkhCJeW+riiy8OYmnG4F4DpZfFpTaBFWp20nTzWuZm7OJAB vgsPxytiOg7D/6m45o5tHdLckqVPtHdvB+WhjvZ8de1t5qWHnPQCV1rcOmjtq3YEyVux 3NLpfIbta3xRn/J9TWB+Xk17hjgm3cRdv+c39DynrWX9f8RaB8d+J+A9me5qhc1PdG6t OVOQ== X-Gm-Message-State: AD7BkJIy6efEKeaVV9iPp+nri/nQiam3l/V61heAc0vtA7cRxaOclYiXMYtniqI5SLPdPQ== X-Received: by 10.66.233.131 with SMTP id tw3mr24565696pac.89.1456772683555; Mon, 29 Feb 2016 11:04:43 -0800 (PST) Received: from [10.65.229.79] ([68.177.129.79]) by smtp.googlemail.com with ESMTPSA id l24sm39815224pfb.73.2016.02.29.11.04.40 for (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 11:04:41 -0800 (PST) Sender: Andrey To: tls@ietf.org References: From: Andrey Jivsov Message-ID: <56D49646.1050806@brainhub.org> Date: Mon, 29 Feb 2016 11:04:38 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------020305020504090004050307" Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 19:04:49 -0000 This is a multi-part message in MIME format. --------------020305020504090004050307 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 02/29/2016 09:32 AM, Joseph Salowey wrote: > We seem to have good consensus on moving to RSA-PSS and away from > PKCS-1.5 in TLS 1.3. However, there is a problem that it may take > some hardware implementations some time to move to RSA-PSS. After an > off list discussion with a few folks here is a proposal for moving > forward. > > We make RSA-PSS mandatory to implement (MUST implement instead of MUST > offer). Clients can advertise support for PKCS-1.5 for backwards > compatibility in the transition period. > Please respond on the list on whether you think this is a reasonable > way forward or not. > I think that supporting PKCS1.5 fallback is the right thing to do for faster adoption of TLS 1.3, as specified above. PKCS #1.5 is allowed by https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.2.1 in X.509 certificates. X.509 certificate chain is a part of TLS handshake. The above proposal is about not restricting one type of signature, the end-entity signature, to PSS. This applies to client authentication, server authentication, or both. Without a generous advance warning about PKCS#1.5 removal by TLS 1.3, we have to deal with already deployed hardware. Had vendors and customers knew that TLS 1.3 will remove PKCS #1.5, we probably would have ended up with more PSS-friendly Internet. PKCS#1.5 is still fine for FIPS 140, Common Criteria, and in CA certificates in TLS 1.3. The WG can chose to remove PSS from one type of signature in TLS1.3. The affected implementations will need to cap negotiation at TLS 1.2. For more details: https://www.ietf.org/mail-archive/web/tls/current/msg19096.html --------------020305020504090004050307 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit
On 02/29/2016 09:32 AM, Joseph Salowey wrote:
We seem to have good consensus on moving to RSA-PSS and away from PKCS-1.5 in TLS 1.3.  However, there is a problem that it may take some hardware implementations some time to move to RSA-PSS.  After an off list discussion with a few folks here is a proposal for moving forward.  

We make RSA-PSS mandatory to implement (MUST implement instead of MUST offer).   Clients can advertise support for PKCS-1.5 for backwards compatibility in the transition period.   
Please respond on the list on whether you think this is a reasonable way forward or not.  


I think that supporting PKCS1.5 fallback is the right thing to do for faster adoption of TLS 1.3, as specified above.

PKCS #1.5 is allowed by https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.2.1 in X.509 certificates. X.509 certificate chain is a part of TLS handshake. The above proposal is about not restricting one type of signature, the end-entity signature, to PSS. This applies to client authentication, server authentication, or both.

Without a generous advance warning about PKCS#1.5 removal by TLS 1.3, we have to deal with already deployed hardware. Had vendors and customers knew that TLS 1.3 will remove PKCS #1.5, we probably would have ended up with more PSS-friendly Internet. PKCS#1.5 is still fine for FIPS 140, Common Criteria, and in CA certificates in TLS 1.3.

The WG can chose to remove PSS from one type of signature in TLS1.3. The affected implementations will need to cap negotiation at TLS 1.2.

For more details: https://www.ietf.org/mail-archive/web/tls/current/msg19096.html
--------------020305020504090004050307-- From nobody Mon Feb 29 11:15:58 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EE41B3A20 for ; Mon, 29 Feb 2016 11:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.707 X-Spam-Level: X-Spam-Status: No, score=-2.707 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cl67VDwOUdd5 for ; Mon, 29 Feb 2016 11:15:56 -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 E00BB1B3A3E for ; Mon, 29 Feb 2016 11:15:51 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BD727433454; Mon, 29 Feb 2016 19:15:50 +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 A6D3A433430; Mon, 29 Feb 2016 19:15:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1456773350; bh=dqPdJkoAHnkS1q2JeqVJ3uP1/s1Abx3djsTpDXNcVTk=; l=206; h=From:To:CC:Date:References:In-Reply-To:From; b=hEg02f6R3ZF3pG3Thmag/zNH41IyxBa3we3RZgAW96C0TlaBdmK0XV934FMnwR49O +L23qwp8i5x3U6eiS2z+Wmcs0jLu6BG8BTsaRzPW2Nczu3v+oW2Zh25VVyghDbWH9T Ji/D4/Kjv8tqCK1N5ykXFJzOFvGzjKqrbctU/dNY= 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 A37461FCA4; Mon, 29 Feb 2016 19:15:50 +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.1130.7; Mon, 29 Feb 2016 14:15:50 -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.1130.005; Mon, 29 Feb 2016 14:15:50 -0500 From: "Salz, Rich" To: Brian Smith , Joseph Salowey Thread-Topic: [TLS] RSA-PSS in TLS 1.3 Thread-Index: AQHRcxcrHtUM77+VkEWELsK/FDUZ3p9DtKoA//+wCCA= Date: Mon, 29 Feb 2016 19:15:49 +0000 Message-ID: <6dc90ded30e84b048cbbdbdb2ffb19f3@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.119.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 19:15:58 -0000 SSBvcmlnaW5hbGx5IHdhcyBva2F5IHdpdGggdGhlIHByb3Bvc2FsLCBidXQgQnJpYW4gbWFkZSBt ZSB0aGluayBhYm91dCB0aGUgdGltZWxpbmUuICBBbmQgSSBsaWtlZCBZb2F24oCZcyBzZW50aW1l bnQg4pi6DQpSU0EtUFNTIG9ubHkgZm9yIFRMUyAxLjMNCg0K From nobody Mon Feb 29 12:41:41 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FDA01B3BB2 for ; Mon, 29 Feb 2016 12:38:12 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AxyCaefyIFe9 for ; Mon, 29 Feb 2016 12:38:06 -0800 (PST) Received: from resqmta-po-04v.sys.comcast.net (resqmta-po-04v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF48F1B3BB0 for ; Mon, 29 Feb 2016 12:38:06 -0800 (PST) Received: from resomta-po-05v.sys.comcast.net ([96.114.154.229]) by resqmta-po-04v.sys.comcast.net with comcast id QLd81s0024xDoy801Le64x; Mon, 29 Feb 2016 20:38:06 +0000 Received: from [10.65.229.79] ([68.177.129.79]) by resomta-po-05v.sys.comcast.net with comcast id QLbx1s00D1ivTfo01Lbz9V; Mon, 29 Feb 2016 20:36:04 +0000 To: tls@ietf.org References: From: Andrey Jivsov Message-ID: <56D4ABAD.90902@brainhub.org> Date: Mon, 29 Feb 2016 12:35:57 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456778286; bh=jqtsPAR5LVX5k4OJtk0abTceIa9i1Gqn1yvas51xINA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ahk94PSxKVb2MYL7CPOPsgYXrSFw5hLMraQ1/zag+YVf5bB+2SvfhQuMeEdoxP3Qk Bcqme4jIE109R2Y0HVpr9xBzz5ehSmYanXl0JGbn6kUjFA1+BVO+UtLBtLsg3N6og+ 9+svDoAPyad6fp7EfCWoQpb38RB0RRIamSc0MTE2Q2AcppX/6LDcx7y9l0alUQxLOm TbuRktg+bEkGxxJzADCDSx3x1crTnNBgIdCH/nZ+KgThrP1NmlkgsunlmMsKQQLQus PCOawieImmsTSffcfIxSFsTd+yHOdQj+gTcPgjPRKOCcJjTazEA1+9VLcXssD7tWYj zInNmvvJ6bBHg== Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 20:38:12 -0000 On 02/29/2016 09:32 AM, Joseph Salowey wrote: > We seem to have good consensus on moving to RSA-PSS and away from > PKCS-1.5 in TLS 1.3. However, there is a problem that it may take some > hardware implementations some time to move to RSA-PSS. After an off > list discussion with a few folks here is a proposal for moving forward. > > We make RSA-PSS mandatory to implement (MUST implement instead of MUST > offer). Clients can advertise support for PKCS-1.5 for backwards > compatibility in the transition period. > Please respond on the list on whether you think this is a reasonable way > forward or not. I think that supporting PKCS1.5 fallback is the right thing to do for wider adoption of TLS 1.3, as specified above. PKCS #1.5 is allowed by https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-6.3.2.1 in X.509 certificates. X.509 certificate chain is a part of TLS handshake. The above proposal is about not restricting one type of signature, the end-entity signature, to PSS. This applies to client authentication, server authentication, or both. Without a generous advance warning about PKCS#1.5 removal by TLS 1.3, we have to deal with already deployed hardware. Had vendors and customers knew that TLS 1.3 will remove PKCS #1.5, we probably would have ended up with more PSS-friendly Internet. Even now PKCS#1.5 is allowed by FIPS 140, Common Criteria, and in CA certificates in TLS 1.3, and earlier TLS. The WG can chose to remove PSS from one type of signature in TLS1.3. This will result in affected implementations capping negotiation at TLS 1.2. There is no other fix in some cases. For more details: https://www.ietf.org/mail-archive/web/tls/current/msg19096.html (I posted earlier, but don't see the message. Sending this one more time, slightly edited) From nobody Mon Feb 29 14:28:13 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1A4E1B3E14 for ; Mon, 29 Feb 2016 14:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFhRPjv3dvt7 for ; Mon, 29 Feb 2016 14:28:09 -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 9CC311B3E12 for ; Mon, 29 Feb 2016 14:28:09 -0800 (PST) Received: by mail-yw0-x22c.google.com with SMTP id h129so134030885ywb.1 for ; Mon, 29 Feb 2016 14:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=DwKfBV9h6qkPXdlKcDpdGDKFwiAFoMZffCkJ/9Y3WQk=; b=ePsWvWD2gWuYQSQ2fFOscdk9+CSJ9X10isto67C6TFJdsMXraz3Czu/YdxJue8+Ype YD+CpPtZ711BFIdZkccr/2/r9b0CxHBTwZE/oNk3oEbhi65nJxyRpWIqLP6XrIhrUc7y 7zJZzYswmxGFept3VYYiGOaw6BEg0wqSP9DZnd/KqEJoowocC7Bm37VWGkI3dMwszlF3 mib3Zt3VGilBZEc+LWEJi/Pvou2fhOtg6mqIJq8nrQrvpOTArSFPdJ0bQ5CihdBgP5v+ ChFhodt36gBI6epXkrsO7RB11YVHvWYcpfP0nffDWKT+szop8UFf36OOKvSZIfWR93kP gaOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=DwKfBV9h6qkPXdlKcDpdGDKFwiAFoMZffCkJ/9Y3WQk=; b=dr2m0wI61GJ6zy/RxC8jCFxeMxLmTsMH/0YD8gTv4MNHemdJvJY9A4zE4FlV9R9TUp dBK68pDBtGxGH6naIiC6TASI2F6N6UZksWkozs0/LNJ7nhazIRQgdVR5ZOPMAV2HnY2f z/SYYq7jf9QP3+CdrEOsd2o/Cc823zgM2SivamSwvT3eoydcR2rq64Qu9igddq7FJYMa Ata8LFUL53sPOQ5REeQB9t4qq7ihKw9JZmfKu8PMQ4STyH7k0owEMAfOLqhVzXeI5/Ww OKPvLBIC/+NBzri+Ly91yFN6ZhFCDVZqM0APym7x8BX5F0YRJ9z/e/n3hZv0j27WXdMi AFWw== X-Gm-Message-State: AD7BkJJ8brL9UNQLbqzhSEz9JeIM2w7sMWO0/Bss7tCu92c0D8W8O5FKVcQVnwPtlAjwqg== X-Received: by 10.129.51.136 with SMTP id z130mr10089785ywz.327.1456784888945; Mon, 29 Feb 2016 14:28:08 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-20-227.phlapa.fios.verizon.net. [71.175.20.227]) by smtp.gmail.com with ESMTPSA id n82sm22280376ywd.53.2016.02.29.14.28.08 (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 29 Feb 2016 14:28:08 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Mon, 29 Feb 2016 17:28:06 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <56D4ABAD.90902@brainhub.org> In-Reply-To: <56D4ABAD.90902@brainhub.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201602291728.07214.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 22:28:11 -0000 On Monday, February 29, 2016 03:35:57 pm Andrey Jivsov wrote: > I think that supporting PKCS1.5 fallback is the right thing to do for > wider adoption of TLS 1.3, as specified above. I think it's long past the time where everyone has to acknowledge that within protocols, there's no such thing as a "fallback" specified as an option. There's simply allowed and not allowed, with the former having no incentive to go away. Arguing to keep it now is equivalent to arguing to keep it forever. Dave From nobody Mon Feb 29 14:36:23 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 159C51A8A44 for ; Mon, 29 Feb 2016 14:36:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MANGLED_BACK=2.3, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=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 lRmQiaf_NvuQ for ; Mon, 29 Feb 2016 14:36:20 -0800 (PST) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 237131B3E3D for ; Mon, 29 Feb 2016 14:36:19 -0800 (PST) Received: from pc1 (0x3ec7a9e1.inet.dsl.telianet.dk [::ffff:62.199.169.225]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 128bits, ECDHE-RSA-AES128-GCM-SHA256) by zucker.schokokeks.org with ESMTPSA; Mon, 29 Feb 2016 23:36:18 +0100 id 0000000000000039.0000000056D4C7E2.0000283B Date: Mon, 29 Feb 2016 23:36:17 +0100 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20160229233617.5466ebd3@pc1> In-Reply-To: <56D4ABAD.90902@brainhub.org> References: <56D4ABAD.90902@brainhub.org> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.29; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="=_zucker.schokokeks.org-10299-1456785378-0001-2" Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 29 Feb 2016 22:36:22 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_zucker.schokokeks.org-10299-1456785378-0001-2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 29 Feb 2016 12:35:57 -0800 Andrey Jivsov wrote: > Without a generous advance warning about PKCS#1.5 removal by TLS 1.3, > we have to deal with already deployed hardware. Had vendors and > customers knew that TLS 1.3 will remove PKCS #1.5, we probably would > have ended up with more PSS-friendly Internet. Ok, look, I really would like to understand what you're trying to say here. What would such a warning look like? We have an RFC for PSS since 2003. We had several attacks showing the weakness of PKCS #1 1.5. Wasn't that warning enough? If not, how would such a warning look like? I'd really like to know, because we will have similar situations in the future and I'd like to avoid people lobbying in the background to continue supporting weak crypto. There will be some new TLS version some day and we will try to get better algorithms into it. So how do we warn you next time? --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: BBB51E42 --=_zucker.schokokeks.org-10299-1456785378-0001-2 Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJW1MfhAAoJEKWIAHK7tR5COLoP/ivBHtJKcB722scZZWPiAh8P xHR0sLdxzTTOfTm2cdUDH1ryW81CJxzya3VitN3+yA07dWiXE8aDc6nxD/JbfXaA YhjCl3f7W+PTeoefVGd87AbAiheMgA4ICiPIPMV5lZRm54KuuCHSrVmnIEC5gjVP u5g6wtsGxwm45/sGUXqz6rA0zOPOWz94NKptxl4YjZr8KcUjAC0s/pS7nzu+8UHu EBi9P7d7hnZtYaI04wBToyXiFIrMSk5KdgnvkuX2Rcqb7gFK4d3+SF88322ATiKe k3fXhywZR95mNXy91q+Jir7dsdvZoBtz/Xz8Jhs9cM07JeqJkF/VUh/hrs0hjstP w0mY3tnBQb9fci1wujHA5bn1j+8j2j3TRbw36Rq/q6GerVNCQ7Vai8SBtHzw50aH A5ngSOqQ2KXlocxI7LZDRltimAHI8MB1dm9TWLuvJU35UiqF3GAcsPohvZ0M+g0S OT5K9YZsqdszk8NUFvqu0svf3TvsiWTVdi6YeYAQFq61dQrigK10KCY8GiP8qSmj kytlF6HlRBfpkLwT+PKSEMhG2dexHeD6QRl+HKCh4MSshk1hRnGHaw5H+I6S2ou9 a7OCiBTQbF0DTf/u4ZIz57XVwvmh6Dc40YDi1NO+eKtiZLMYoWFS3PufNTJ2oXWU TnKK/hOrnkaZzxyuaBA/ =D1Dk -----END PGP SIGNATURE----- --=_zucker.schokokeks.org-10299-1456785378-0001-2-- From nobody Mon Feb 29 20:52:16 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFC581ACD03 for ; Mon, 29 Feb 2016 20:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvQU4nWRPGho for ; Mon, 29 Feb 2016 20:52:14 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BA9E1ACD01 for ; Mon, 29 Feb 2016 20:52:13 -0800 (PST) Received: from resomta-po-11v.sys.comcast.net ([96.114.154.235]) by resqmta-po-12v.sys.comcast.net with comcast id QUsD1s00354zqzk01UsDfH; Tue, 01 Mar 2016 04:52:13 +0000 Received: from [192.168.0.10] ([76.103.100.237]) by resomta-po-11v.sys.comcast.net with comcast id QUsC1s00157Jnqc01UsCuQ; Tue, 01 Mar 2016 04:52:13 +0000 Message-ID: <56D51FFB.9050909@brainhub.org> Date: Mon, 29 Feb 2016 20:52:11 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tls@ietf.org References: <56D4ABAD.90902@brainhub.org> <20160229233617.5466ebd3@pc1> In-Reply-To: <20160229233617.5466ebd3@pc1> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1456807933; bh=tV8qaBjqVJSdBz9TIG8W3HSI3XYmVgQ/XWayrEfkFtc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=SIGhEBbsXp6luTC3dcQ7H3xLx5SCbBVMcAP72VWdumjAM34SrvhXbl1U7I6Ij84P2 oRmuzJyRCLBRTYJEw0y3KiQ4wrXV5+ej1X01YCCNloFXA73XxMUZ3QVYGJDsn65K08 fccvzMqILFqliiY+z5iPsztt9AOWAL/3Ws9hTL4Ol+/6x0FJgdqe7OFynqR4Bu1dc9 kXNVghomF1ZdINwCxYjkJwZbl7AkdLmbb6XWzsss6bEaZ5aM6kOQwBOZxGe01csUUQ se7JF41POS9cWJJ6NGXWqjn2LD1uQ7Fu7VjCY2sKBszOYPr5FYgQssWBqDiQF6SgTq ZZays1s8AqUew== Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 04:52:16 -0000 On 02/29/2016 02:36 PM, Hanno Böck wrote: > We have an RFC for PSS since 2003. > We had several attacks showing the weakness of PKCS #1 1.5. In the face of such danger, what's your opinion on PKCS #1.5 signatures being perfectly fine in TLS 1.3 ? I refer to signatures in X.509 certs in the latest https://tools.ietf.org/html/draft-ietf-tls-tls13-11. Why not ban PKCS #1.5 altogether from TLS 1.3? It will not only make TLS 1.3 more secure, but code simpler and footprint smaller. Besides, it's reasonable: TLS 1.2 already allows PSS in X.509 certs. You are arguing for the benefit of suddenly mandating a steel door on a grass hut. Joseph Salowey's proposal gives an option for the door, consistent with how TLS 1.2 does this for X.509 certs. From nobody Mon Feb 29 20:56:56 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 569321ACD35 for ; Mon, 29 Feb 2016 20:56:55 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRrNw2cajS4c for ; Mon, 29 Feb 2016 20:56:54 -0800 (PST) Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 344381ACD2E for ; Mon, 29 Feb 2016 20:56:54 -0800 (PST) Received: by mail-io0-x231.google.com with SMTP id g203so210905358iof.2 for ; Mon, 29 Feb 2016 20:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=u4UrA1xB1NjQWZ0ZQti0w8JtfqsUV9B/o486GKt2Q0w=; b=rHHMp1tASDjjxgDoKNuibIFihyEwSszh03WpdqvkwV66eOxvdPkh0EfaU2bDCXUbd+ HgiD+HuJrYp39Z+FuY2qGdDuJ0jgCBdeJOaYXpBf6zVOQvP7uJnms+hx0vY0LvWbXsWC EllHy5/Eob/aoYvbXdaWvWLvgQxM1ul9wxAK9I9qC1f+0oUVmEbcdxT8BRFj1tspqBLw 0sow68bYVujrD9T7agYym9D79b+xZ56kU8Ioait2We671pKeyYaFywrvV5Ubd3jGoCrW eUk507VD6ej5MPMEgseZqN1NDnBU8p+OBdIYa0osvy72l2Ncs5Qw9CUKcMkrX68W7wMZ cWqw== 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:date :message-id:subject:from:to:cc; bh=u4UrA1xB1NjQWZ0ZQti0w8JtfqsUV9B/o486GKt2Q0w=; b=Q5RBLkgufV2CFXC0KzsG9DZapg8LbLbiNAZ6RiO5XzelpEuS9Cb63CJhyuC+4eoham HdZUsQuJDItfBrSgSY/YOA1xC8p6J4mMUaYX6+fOZV7PZQo/cZqxvU4kvq0hR4Hb7HPl Wi8oDxjdDVIIeW6aApmVq6+lxRXup4EgGxBI7er/bhJPQ3lvSN1o0yrY8lD1zBqA2dfn 3u6IfW4Nk76msrQ9g1DRQVFzX+R58Ll7aK1YcQAqQbELKITa6f7ZdUxfrDwxXe7Ibnva JcEkcQk+Ccnn1gGtBhws78zNJX44Wsxcd8oSIXs8F9rmcCcRWVdyculDSgCXdHIqNYHY slFA== X-Gm-Message-State: AG10YORcQoqPJ0Jh5ZSF771xd85xLD95IbtEALWaClRwVYE72FlC2YhOPSUDtVRgSJi2+ZTGfwU1tOq+0aaByg== MIME-Version: 1.0 X-Received: by 10.107.131.27 with SMTP id f27mr24252945iod.190.1456808213623; Mon, 29 Feb 2016 20:56:53 -0800 (PST) Received: by 10.36.53.79 with HTTP; Mon, 29 Feb 2016 20:56:53 -0800 (PST) In-Reply-To: References: Date: Tue, 1 Mar 2016 15:56:53 +1100 Message-ID: From: Martin Thomson To: Joseph Salowey Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list 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, 01 Mar 2016 04:56:55 -0000 On 1 March 2016 at 04:32, Joseph Salowey wrote: > We make RSA-PSS mandatory to implement (MUST implement instead of MUST > offer). Clients can advertise support for PKCS-1.5 for backwards > compatibility in the transition period. >From my perspective, this is fine. I would like to say that we won't ever support PKCS#1.5 for TLS 1.3, but I think that I would rather have users on 1.3 with PKCS#1.5 than have them stuck on 1.2. It seems like others are taking the position that we should say "MUST NOT use PKCS#1.5". I would love for that to be the case, but I want to separate decision path for that, preferably one that is somewhat under my control. Once we have information about usage for each signature scheme, I'll be happy to arrange for another "break the web" day. From nobody Mon Feb 29 20:59:51 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 659CD1ACD45 for ; Mon, 29 Feb 2016 20:59:51 -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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTS-Q2wJTJTR for ; Mon, 29 Feb 2016 20:59:49 -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 098EE1ACD3D for ; Mon, 29 Feb 2016 20:59:48 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 061C5284AED; Tue, 1 Mar 2016 04:59:48 +0000 (UTC) Date: Tue, 1 Mar 2016 04:59:47 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160301045947.GV12869@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.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Mar 2016 04:59:51 -0000 On Tue, Mar 01, 2016 at 03:56:53PM +1100, Martin Thomson wrote: > It seems like others are taking the position that we should say "MUST > NOT use PKCS#1.5". I would love for that to be the case, but I want > to separate decision path for that, preferably one that is somewhat > under my control. Once we have information about usage for each > signature scheme, I'll be happy to arrange for another "break the web" > day. It is much easier to mandate PSS in TLS 1.3 now, than to remove it later. Servers that can't do PSS will use TLS 1.2. This avoids a break-the-web day. -- Viktor. From nobody Mon Feb 29 21:06:50 2016 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E0BC1ACD78 for ; Mon, 29 Feb 2016 21:06: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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mLYFCbh5K_EV for ; Mon, 29 Feb 2016 21:06:49 -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 07D6E1A0A6A for ; Mon, 29 Feb 2016 21:06:48 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EFB37284AED; Tue, 1 Mar 2016 05:06:47 +0000 (UTC) Date: Tue, 1 Mar 2016 05:06:47 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20160301050647.GW12869@mournblade.imrryr.org> References: <20160301045947.GV12869@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160301045947.GV12869@mournblade.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] RSA-PSS in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Tue, 01 Mar 2016 05:06:50 -0000 On Tue, Mar 01, 2016 at 04:59:47AM +0000, Viktor Dukhovni wrote: > It is much easier to mandate PSS in TLS 1.3 now, than to remove it > later. Servers that can't do PSS will use TLS 1.2. This avoids > a break-the-web day. Sorry, ... than to remove *PKCS#1.5* later ... -- Viktor.