From nobody Mon Jul 2 06:46:08 2018 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 1469C130E64; Mon, 2 Jul 2018 06:46:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053916603.16100.9419679623487134394@ietfa.amsl.com> Date: Mon, 02 Jul 2018 06:46:06 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-27.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is the mailing list 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, 02 Jul 2018 13:46:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename : draft-ietf-tls-dtls13-27.txt Pages : 45 Date : 2018-07-02 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls13-27 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-27 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-27 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 Jul 2 06:52:15 2018 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 F213B130E79; Mon, 2 Jul 2018 06:52:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153053952894.16179.4916849736973561120@ietfa.amsl.com> Date: Mon, 02 Jul 2018 06:52:08 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls13-28.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is the mailing list 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, 02 Jul 2018 13:52:09 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Protocol Version 1.3 Authors : Eric Rescorla Hannes Tschofenig Nagendra Modadugu Filename : draft-ietf-tls-dtls13-28.txt Pages : 45 Date : 2018-07-02 Abstract: This document specifies Version 1.3 of the Datagram Transport Layer Security (DTLS) protocol. DTLS 1.3 allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls13-28 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls13-28 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls13-28 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 Jul 2 07:07:55 2018 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 E5BF9130E01; Mon, 2 Jul 2018 07:07:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153054047389.16504.10726742181370236068@ietfa.amsl.com> Date: Mon, 02 Jul 2018 07:07:53 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dtls-connection-id-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is the mailing list 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, 02 Jul 2018 14:07:54 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : The Datagram Transport Layer Security (DTLS) Connection Identifier Authors : Eric Rescorla Hannes Tschofenig Thomas Fossati Tobias Gondrom Filename : draft-ietf-tls-dtls-connection-id-01.txt Pages : 11 Date : 2018-07-02 Abstract: This document specifies the Connection ID construct for the Datagram Transport Layer Security (DTLS) protocol. A Connection ID is an identifier carried in the record layer header that gives the recipient additional information for selecting the appropriate security association. In "classical" DTLS, selecting a security association of an incoming DTLS record is accomplished with the help of the 5-tuple. If the source IP address and/or source port changes during the lifetime of an ongoing DTLS session then the receiver will be unable to locate the correct security context. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dtls-connection-id-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dtls-connection-id-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 14:17:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1890E131372 for ; Mon, 2 Jul 2018 14:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9j3pwWs0OIl for ; Mon, 2 Jul 2018 14:17:21 -0700 (PDT) Received: from elasmtp-galgo.atl.sa.earthlink.net (elasmtp-galgo.atl.sa.earthlink.net [209.86.89.61]) (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 EDD0A131369 for ; Mon, 2 Jul 2018 14:17:20 -0700 (PDT) Received: from [47.143.125.3] (helo=Williams-MacBook-Pro.local) by elasmtp-galgo.atl.sa.earthlink.net with esmtpa (Exim 4) (envelope-from ) id 1fa6FI-0003dd-RX; Mon, 02 Jul 2018 17:20:29 -0400 Date: Mon, 2 Jul 2018 14:17:17 -0700 From: Bill Frantz To: Joseph Salowey cc: Paul Wouters , "" , Benjamin Kaduk X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4.3 (480) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7932a390ecf431d571ac95634dff1a823d350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.3 Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2018 21:17:30 -0000 On 6/25/18 at 9:20 PM, joe@salowey.net (Joseph Salowey) wrote: >Hi Folks, > >There has been some discussion with a small group of folks on github - >https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to make >sure there is consensus in the working group to take on the pinning work >and see if there is consensus for modifications in the revision. Please >respond to the following questions on the list by July 10, 2018. > >1. Do you support the working group taking on future work on a pinning >mechanism (based on the modifications or another approach)? I would like to see a pinning mechanism, and think this Working=20 Group is the right place to move the idea forward. >2. Do you support the reserved bytes in the revision for a future pinning >mechanism? Yes. >3. Do you support the proof of denial of existence text in the revision? I had difficulty reading the GitHub thread. >4. Do you support the new and improved security considerations? ditto 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 Jul 2 15:56:53 2018 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 703D1130E82; Mon, 2 Jul 2018 15:56:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153057220442.16153.8969945998343270317@ietfa.amsl.com> Date: Mon, 02 Jul 2018 15:56:44 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-subcerts-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is the mailing list 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, 02 Jul 2018 22:56:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Delegated Credentials for TLS Authors : Richard Barnes Subodh Iyengar Nick Sullivan Eric Rescorla Filename : draft-ietf-tls-subcerts-01.txt Pages : 11 Date : 2018-07-02 Abstract: The organizational separation between the operator of a TLS server and the certificate authority that provides it credentials can cause problems, for example when it comes to reducing the lifetime of certificates or supporting new cryptographic algorithms. This document describes a mechanism to allow TLS server operators to create their own credential delegations without breaking compatibility with clients that do not support this specification. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-subcerts/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-subcerts-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-subcerts-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-subcerts-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 2 16:02:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C8D13143F for ; Mon, 2 Jul 2018 16:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id znpbzKL2LfEN for ; Mon, 2 Jul 2018 16:02:23 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 259BA131239 for ; Mon, 2 Jul 2018 16:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2644; q=dns/txt; s=iport; t=1530572535; x=1531782135; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=M3w5wLq7qyyBubVJBAsEY+uwvU9nABBWraES3Q7F1C8=; b=LO8plCsoZqqJZTOM6HFNWlnhxmqKgleSh3SSQqbTH2pGFyIsObR7eaDz LF/CmzRcGLuu5PXpHGeLv270Ihhe0IfrZYIptkl9eJ1LRblNe6s+8aGUC oTph/NlETQS9PdcfveNIl/9dO+Hz9L25elqSNUMjYwTHMQHeut/WE8ueC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DoAQBnrjpb/5BdJa1cGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNJYn8oCoNvlEWCB4MqkXqBegsjhEkCF4MdITUXAQIBAQI?= =?us-ascii?q?BAQJtHAyFNgEBAQEDIxFDDgQCAQgRBAEBAwIUEgICAjAVBgEBBQMCBBMIgxm?= =?us-ascii?q?Bfw+oWoIciFSBNoELh2KBVj+BD4MPghGBBwEBAgEBFoIVgjKCVQKMTox4CQK?= =?us-ascii?q?GBIkPgUhDg0mICYozhy0CERMBgSQeATaBUnAVGoMKCYsLhT5vAY5cgQqBGgE?= =?us-ascii?q?B?= X-IronPort-AV: E=Sophos;i="5.51,300,1526342400"; d="scan'208";a="418377574" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Jul 2018 23:02:14 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w62N2EgU004056 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Jul 2018 23:02:14 GMT Received: from xch-rcd-012.cisco.com (173.37.102.22) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 2 Jul 2018 18:02:13 -0500 Received: from xch-rcd-012.cisco.com ([173.37.102.22]) by XCH-RCD-012.cisco.com ([173.37.102.22]) with mapi id 15.00.1320.000; Mon, 2 Jul 2018 18:02:13 -0500 From: "Owen Friel (ofriel)" To: "" Thread-Topic: New Version Notification for draft-barnes-tls-pake-02.txt Thread-Index: AQHUD88weSChlCs1SU+QW4DEnmKyh6R8j88A Date: Mon, 2 Jul 2018 23:02:13 +0000 Message-ID: <51f5f1b274ba497db757c10bf2753a8d@XCH-RCD-012.cisco.com> References: <153029356140.30373.16326842633570359550.idtracker@ietfa.amsl.com> In-Reply-To: <153029356140.30373.16326842633570359550.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.8.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [TLS] FW: New Version Notification for draft-barnes-tls-pake-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2018 23:02:32 -0000 SGV5IGFsbCwNCkZvbGxvd2luZyB1cCBmcm9tIHRoZSB0aHJlYWRzIGluIEFwcmlsLCBhIG5ldyB2 ZXJzaW9uIGhhcyBiZWVuIHBvc3RlZCB0aGF0IGFkZHJlc3NlcyBzb21lIG9mIHRob3NlIGNvbW1l bnRzLCBhbmQgbWFrZXMgdGhlIFRMUyBleHRlbnNpb25zIGdlbmVyaWMgZW5vdWdoIHRvIHRyYW5z cG9ydCBhbnkgUEFLRSwgd2l0aCBzb21lIG9wZW4gcXVlc3Rpb25zIG9uIFBBS0UgYWxnb3JpdGht IGFnaWxpdHkuIEFsbCBmZWVkYmFjayBvbiBtYWtpbmcgdGhlIGV4dGVuc2lvbiBnZW5lcmljIGZv ciB0cmFuc3BvcnRpbmcgYW55IFBBS0UgcGFyYW1zLCBhbmQgdGhlIG9wZW4gaXRlbSBzdWdnZXN0 aW9uIHRvIGZvbGxvdyBUTFMxLjMga2V5X3NoYXJlIGV4dGVuc2lvbiBwYXR0ZXJuIGZvciBhbGdv cml0aG0gbmVnb3RpYXRpb24gd291bGQgYmUgZ3JlYXQuDQpDaGVlcnMsDQpPd2VuDQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gDQpTZW50OiBGcmlkYXkgMjkgSnVuZSAyMDE4IDE4OjMz DQpUbzogUmljaGFyZCBCYXJuZXMgPHJsYkBpcHYuc3g+OyBPd2VuIEZyaWVsIChvZnJpZWwpIDxv ZnJpZWxAY2lzY28uY29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1iYXJuZXMtdGxzLXBha2UtMDIudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRy YWZ0LWJhcm5lcy10bHMtcGFrZS0wMi50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRl ZCBieSBPd2VuIEZyaWVsIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFt ZToJCWRyYWZ0LWJhcm5lcy10bHMtcGFrZQ0KUmV2aXNpb246CTAyDQpUaXRsZToJCVVzYWdlIG9m IFNQQUtFIHdpdGggVExTIDEuMw0KRG9jdW1lbnQgZGF0ZToJMjAxOC0wNi0yOQ0KR3JvdXA6CQlJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMTENClVSTDogICAgICAgICAgICBodHRwczov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYmFybmVzLXRscy1wYWtlLTAyLnR4 dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWJhcm5lcy10bHMtcGFrZS8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtYmFybmVzLXRscy1wYWtlLTAyDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1iYXJuZXMtdGxzLXBha2UNCkRpZmY6 ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtYmFybmVz LXRscy1wYWtlLTAyDQoNCkFic3RyYWN0Og0KICAgVGhlIHByZS1zaGFyZWQga2V5IG1lY2hhbmlz bSBhdmFpbGFibGUgaW4gVExTIDEuMyBpcyBub3Qgc3VpdGFibGUgZm9yDQogICB1c2FnZSB3aXRo IGxvdy1lbnRyb3B5IGtleXMsIHN1Y2ggYXMgcGFzc3dvcmRzIGVudGVyZWQgYnkgdXNlcnMuDQog ICBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhbiBleHRlbnNpb24gdGhhdCBlbmFibGVzIHRoZSB1 c2Ugb2YNCiAgIHBhc3N3b3JkLWF1dGhlbnRpY2F0ZWQga2V5IGV4Y2hhbmdlIHByb3RvY29scyB3 aXRoIFRMUyAxLjMuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90 ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBz dWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFi bGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Mon Jul 2 16:40:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81CBA13148A for ; Mon, 2 Jul 2018 16:40:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id na0n_RfuSgOy for ; Mon, 2 Jul 2018 16:40:35 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F49E131231 for ; Mon, 2 Jul 2018 16:39:56 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id g123-v6so36601ywf.13 for ; Mon, 02 Jul 2018 16:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=0VZXMfKZhTTFeISUrlIQa8LGEgSPtgj67IqVzrr5H54=; b=q19/ipqLBe4DY+eWpiBz7ffeMKz8IbcvXWhH/TrenU6h/VE3Eyl2wti0vqUTYWqL5T bwkCeAAZ2W2yVoDlkFF0OhQ/lFMQp3LmxQZFOHXRM8Wy6R+/vzmceXALPka8qILeSCH1 WL1e0GJZtRRZCKxShaaui8ourCkcKpYQTj8QBvjb8qRtseJid/Ep5HLmHidYwnndMkYL Cef9/1UQLO35Fl9gXXMf39WImMePcezhVPhE7bXRV/dHCTWeINqJcBPzIaZI+x4+zGpW ZoSxNkP0Gy+wYYsRuOYD1CipbOWyiz4C38/hNJAlq9VMnC16KgVfKI0xtkCcVYWMze4N fApw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0VZXMfKZhTTFeISUrlIQa8LGEgSPtgj67IqVzrr5H54=; b=Tz42KrQiIAlBUvbtJzlDal5a7WhT3MW8QCJVAC8+iZ1Jn4rjJONhU3iKfkZAjBsR6X yQxeBKIZ7xio6WWgD3y7cjom/D20eF1SpaTXFvNUcMIvqPDdzBgZQBECw8m3EcgBYx5q HXaJxXIfQS7J4DTXokRcaRjjWg9RX6j9Dw1B/DNCD+xnGJCBGP/GPH3+JsnewSN/V/5Y ATsufn5evazjXOEA6Sz3K1Ns+XD0mdVLmbX5p7vV7ZX+2Y5ePxp1/EeUJxUKTO+H5xhr AcEMcbi/w0SrSvFRgJKaQ/3IwiMkF1DE3/DNkyPqw4LwllgkvRK+CdmiDDT28POzK6TL 1Isw== X-Gm-Message-State: APt69E2mOcf+DsOP/HB0ScMuZ9YMnRBspdPtXkPfrv3cr4SUwk1/dMH8 sGCL2u76USzbA724E68Ft/SqkyJX5UgkuuPXYCNEhmCYVAg= X-Google-Smtp-Source: AAOMgpeME9F97wNYZg26xlK/lEVrsGOuzeNWh4BgUYAt0brIpPqUYZf7GkQtpKuj1RJGevfenMBTyHf8/4BNcSwI21Y= X-Received: by 2002:a0d:f286:: with SMTP id b128-v6mr13349777ywf.489.1530574795480; Mon, 02 Jul 2018 16:39:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 16:39:14 -0700 (PDT) From: Eric Rescorla Date: Mon, 2 Jul 2018 16:39:14 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000fcbc6905700cb652" Archived-At: Subject: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 02 Jul 2018 23:40:46 -0000 --000000000000fcbc6905700cb652 Content-Type: text/plain; charset="UTF-8" Hi folks, I just submitted: https://tools.ietf.org/html/draft-rescorla-tls-esni-00 This draft describes a DNS-based approach to doing encrypted SNI. Previously, we had thought this wouldn't work because only sites that were particularly vulnerable would do it, and so the use of ESNI marks you out. The idea behind this draft is that there are a lot of sites which are hosted by -- and whose DNS is run by -- a large provider, and that provider can shift many if not all of its sites to ESNI at once, thus removing the "standing out" issue and making a DNS-based approach practical. I am working on an implementation for NSS/Firefox and I know some others are working on their own implementations, so hopefully we can do some interop in Montreal. This is at a pretty early stage, so comments, questions, defect reports welcome. -Ekr --000000000000fcbc6905700cb652 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

I just submitted:

=C2=A0 https://tools.i= etf.org/html/draft-rescorla-tls-esni-00

This draft describes a D= NS-based approach to doing encrypted SNI.

Previously, we had thought= this wouldn't work because only sites that
were particularly vulner= able would do it, and so the use of ESNI marks
you out. The idea behind = this draft is that there are a lot of sites
which are hosted by -- and w= hose DNS is run by -- a large provider,
and that provider can shift many= if not all of its sites to ESNI at
once, thus removing the "standi= ng out" issue and making a DNS-based
approach practical.

I a= m working on an implementation for NSS/Firefox and I know some
others ar= e working on their own implementations, so hopefully we can
do some inte= rop in Montreal.

This is at a pretty early stage, so comments, quest= ions, defect
reports welcome.

-Ekr






--000000000000fcbc6905700cb652-- From nobody Mon Jul 2 20:53:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF870130F03 for ; Mon, 2 Jul 2018 20:53:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBa3gkw_pCO7 for ; Mon, 2 Jul 2018 20:53:28 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8BA9130EED for ; Mon, 2 Jul 2018 20:53:27 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41KVb943Lgz1yF for ; Tue, 3 Jul 2018 05:53:25 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530590005; bh=O/giRBZ4+PcS2O2sYR0Q9iaRRILhJ51ago+63eL1flU=; h=Date:From:To:Subject:In-Reply-To:References; b=YD8yNbUjI/AefG6u3ndNdXlarVK//50F8cioLJpqluiNrzkM3eqBfGejxAvBykxVX dE/OhuqepG4xwtfE7FQS20lntWXnUG3YVB4Vcw5Gui6KNSZOMK3nYOIXsGWh+dPnfc aW+XI11MhgLFMEATCAiI/it5Ff28J9e20bq0KFOs= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id p7MsXklBal2W for ; Tue, 3 Jul 2018 05:53:21 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 3 Jul 2018 05:53:20 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7EAB562A2EF; Mon, 2 Jul 2018 23:53:19 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7EAB562A2EF Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 74B8445755C2 for ; Mon, 2 Jul 2018 23:53:19 -0400 (EDT) Date: Mon, 2 Jul 2018 23:53:19 -0400 (EDT) From: Paul Wouters To: tls@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 03:53:31 -0000 On Mon, 2 Jul 2018, Eric Rescorla wrote: >   https://tools.ietf.org/html/draft-rescorla-tls-esni-00 > This is at a pretty early stage, so comments, questions, defect > reports welcome. This structure is placed in the RRData section of a TXT record as a base64-encoded string. If this encoding exceeds the 255 octet limit of TXT strings, it must be split across multiple concatenated strings as per Section 3.1.3 of [RFC4408]. It is strongly recommended not to use TXT records. Why not use a new RRTYPE? Everything these days knows how to serve unknown record types (see RFC 3597). The only possibly exception is provisioning tools of small players, but this document starts of saying you basically need to be on a bulk hosting provider anyway. They can properly provision. I need to think more about the document to see if there is really not something simpler or better possible. Paul From nobody Mon Jul 2 20:58:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 009EE130F0D for ; Mon, 2 Jul 2018 20:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtIT8bxAQLWv for ; Mon, 2 Jul 2018 20:58:40 -0700 (PDT) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23273130EED for ; Mon, 2 Jul 2018 20:58:40 -0700 (PDT) Received: by mail-yb0-x22f.google.com with SMTP id r3-v6so207631ybo.4 for ; Mon, 02 Jul 2018 20:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UCP3x7X6x4bCXvlh4YNSfVfThTVFWhg9Nkj0ZqT5bxE=; b=NNxjyF1Hq1348v39AhcSCteICckH13W8LVtO6H33LwVdlj/oYelFkH3P9gELZVOcck grmP/wIVNBWdXH+NUCnEWiZMCT3tz+CZPmYpA/Y5m8ZIXK5KcDJZVWuoD7yq25/SNJiY mXWbYYMHLVY3OcTpqpwL5dDkktAW9uy5SkAKmlEFKWXf7lT4T3S7lYZO7O/P/0xoL/EQ j5NLeABlPTn71hIHkqdCGluupwzxw+7WHGtPjNw7KBwtTEYAtgNmJhqc+QKQaJT3s4K6 fE/SaIh9i29DUAG9tdQLn1s1GnCWuuIqVBFJ4FsLVr4Rr7bS9UCSmVtqXrVvwwkG8zhR eAdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UCP3x7X6x4bCXvlh4YNSfVfThTVFWhg9Nkj0ZqT5bxE=; b=h8Z4b7MKhbcdUo63qBKDLJgLBnkD3LaJuqyybTRmupFm7sUSUfD+tlIMeUZgNkzrtQ axdsGmeqvPkzvUVK/+V+tm86LnHnI5G262huaOPFFrSAC3pb80pMtRMPvLVj1EF0auUC tT9ub0EmbElbUn8OKG1QyKrms6fyUQwvbhyuBP/zEsB6QocaKT66frAO8i4FO1iX2JEN a7ZER7q8e8B9Twx/bxEeTV7vh3oqpjHrwn29TWQedSn6iwD2Vl+d+SYzTfTmpoVpyO1s E7NPMfrXd0Cj/QZORm2kYatJDkNTfCoPGA38Yd6DnHY9OKaWcTJTh3pvtMIQKdTWvayu cK0g== X-Gm-Message-State: APt69E30i+j0yXKHsRozbN93iGdmNHpgGwNUbNGYk4tLfXEUpQ1xUCHN 9o1mlUhaL+TmunL1kyDV0WRf9/jXf6DxpjlMRZ1anE/IuGw= X-Google-Smtp-Source: AAOMgpdRIMNRRCZM3yWbfDHiR+ubRC7F1Urxk4AAv/UVop0jTxVVdvBZWKKnd0PiRJJD7aCe4pgTD5s+bDUv5l8KAPI= X-Received: by 2002:a25:adcb:: with SMTP id d11-v6mr4333572ybe.73.1530590319225; Mon, 02 Jul 2018 20:58:39 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Mon, 2 Jul 2018 20:57:58 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 2 Jul 2018 20:57:58 -0700 Message-ID: To: Paul Wouters Cc: "" Content-Type: multipart/alternative; boundary="00000000000046414d0570105494" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 03:58:45 -0000 --00000000000046414d0570105494 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 2, 2018 at 8:53 PM, Paul Wouters wrote: > On Mon, 2 Jul 2018, Eric Rescorla wrote: > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 >> > > This is at a pretty early stage, so comments, questions, defect >> reports welcome. >> > > > This structure is placed in the RRData section of a TXT record as a > base64-encoded string. If this encoding exceeds the 255 octet > limit > of TXT strings, it must be split across multiple concatenated > strings > as per Section 3.1.3 of [RFC4408]. > > It is strongly recommended not to use TXT records. Why not use a new > RRTYPE? Everything these days knows how to serve unknown record types > (see RFC 3597). The only possibly exception is provisioning tools of > small players, but this document starts of saying you basically need > to be on a bulk hosting provider anyway. They can properly provision. > See: https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906 -Ekr --00000000000046414d0570105494 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 2, 2018 at 8:53 PM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 2 Ju= l 2018, Eric Rescorla wrote:

=C2=A0 https://tools.ietf.org/html/draft-= rescorla-tls-esni-00

This is at a pretty early stage, so comments, questions, defect
reports welcome.


 =C2=A0 =C2=A0 =C2=A0 =C2=A0 This structure is placed in the RRData section = of a TXT record as a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 base64-encoded string.=C2=A0 If this encoding e= xceeds the 255 octet limit
=C2=A0 =C2=A0 =C2=A0 =C2=A0 of TXT strings, it must be split across multipl= e concatenated strings
=C2=A0 =C2=A0 =C2=A0 =C2=A0 as per Section 3.1.3 of [RFC4408].

It is strongly recommended not to use TXT records. Why not use a new
RRTYPE? Everything these days knows how to serve unknown record types
(see RFC 3597). The only possibly exception is provisioning tools of
small players, but this document starts of saying you basically need
to be on a bulk hosting provider anyway. They can properly provision.

See:
--00000000000046414d0570105494-- From nobody Tue Jul 3 07:26:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD090130E04 for ; Tue, 3 Jul 2018 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tF-N9wAMG2Ls for ; Tue, 3 Jul 2018 07:26:13 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE04E130DE6 for ; Tue, 3 Jul 2018 07:26:13 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w63EMHel026643; Tue, 3 Jul 2018 15:26:13 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=fcBNIAqHYuzrq34ypkn1Qplpb4jc7lmfuGuK1q5fzUo=; b=h1x8Y5530fthXRQ7Zayfm738KAtUjDlZqJpim3KLe9eXwbasGMfMUNGOTEbWGYEpElX6 k1IQTJoDEtyRpuX/cMrP2UWso6i6jYPluV1dvYnUnkwvM25MVXgQw9E0o//1/dZtqOXu hZDdmwQ9HHLs98qvxIJ/2NLB50E3pupdgjMSzTKIdGpGZEHw/qyQHr9dvT205d1HBkv5 frECecf0L5P/ZmftcDJK6st3peoHcgGCuENM4lW/eHwCwNRnRZxWOX4/W9z+8XI4XMC5 oyJ/Zr/Apd9mbjf+6FC1YFUQrQfKqSM9E5ktBk1TY6Dsd2r+143jHSsGox40mXJpuhsY pw== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2jx1ju9033-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jul 2018 15:26:13 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w63EJeGa001489; Tue, 3 Jul 2018 10:26:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jx57ba5wh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 03 Jul 2018 10:26:11 -0400 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 3 Jul 2018 09:26:10 -0500 Received: from ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) by ustx2ex-dag1mb6.msg.corp.akamai.com ([172.27.27.107]) with mapi id 15.00.1365.000; Tue, 3 Jul 2018 07:26:10 -0700 From: "Sniffen, Brian" To: Eric Rescorla CC: "" Thread-Topic: [TLS] DNS-based Encrypted SNI Thread-Index: AQHUEl5BGfRrHHIWEE6kZ2BXRr3upKR9jtZq Date: Tue, 3 Jul 2018 14:26:10 +0000 Message-ID: <0AE65C49-5D09-44A0-BD30-4016AC39E293@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 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-03_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030165 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-03_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030166 Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 14:26:17 -0000 TG9va3MgbmVhdC4gDQoNCjEpIFRGTyBET1MgdmVjdG9yOiBpcyB0aGUgaWRlYSBzZXJ2ZXJzIHdp bGwgZGlzYWJsZSBURk8gdW5kZXIgc3RyYWluIGJ1dCBub3QgYmUgYWJsZSB0byBkaXNhYmxlIEVT Tkk/DQoNCjIpIOKAnGNsaWVudHMgbWlnaHQgb3B0IHRvIGF0dGVtcHQgY2FwdGl2ZSBwb3J0YWwg ZGV0ZWN0aW9uIHRvIHNlZSBpZiB0aGV5IGFyZSBpbiB0aGUgcHJlc2VuY2Ugb2YgYSBNSVRNIHBy b3h5LCBhbmQgaWYgc28gZGlzYWJsZSBFU05JLuKAnQ0KDQpJZiBJ4oCZbSBvcGVyYXRpbmcgYSBn cmVhdCBmaXJld2FsbCwgSSBjYW4gdXNlIHRoaXMgdG8gZGlzY292ZXIgZGlzc2lkZW50cywgcmln aHQ/ICBFaXRoZXIgdGhleSBzZW5kIG1lIGRhbmdlcm91cyBTTkkgdmFsdWVzIG9yIHRoZXkgYXJl IGNvbmZpZ3VyZWQgdG8gbm90IGRpc2FibGUgRVNOSSwgYW5kIHRha2luZyB0aGUgZmlmdGggaXMg ZmF0YWwuIFRvIHByb3RlY3QgdGhlbSwgSSB0aGluayBub2JvZHkgY2FuIGhhdmUgdGhpcyBtb2Rl LiANCg0KMykgSG93IG1hbnkgYml0cyBkb2VzIHRoaXMgb2ZmZXI/IEhpZGluZyBpbiBhIHNldCBv ZiBhIG1pbGxpb24gdW5pZm9ybSBob3N0cyBpcyAyMCBiaXRzLCBhbmQgdGhlIG5vbnVuaWZvcm1p dHkgd2lsbCBhY2NydWUgdG8gdGhlIGFkdmVyc2FyeeKAmXMgYmVuZWZpdC4gQWN0aXZlIHByb2Jp bmcgd2lsbCB1bm1hc2sgdmlzaXRvcnMgdG8gZGlzc2lkZW50IHNpdGVzLg0KDQpJIHdvcnJ5IHRo YXQgdGhpcyB0b29sIGlzIHNvIHdlYWsgYWdhaW5zdCBhIEdGVy1zdHlsZSBhZHZlcnNhcnkgZm9y IHRoZSBwdXJwb3NlIG9mIGFsbG93aW5nIGRpc3NpZGVudCBhY2Nlc3MgdG8gcmVzdHJpY3RlZCB3 ZWIgc2l0ZXMgdGhhdCBpdCB3aWxsIGJlIGRhbmdlcm91cyBpZiByZWxlYXNlZC4gQnV0IG1heWJl IEkgbWlzdW5kZXJzdGFuZCB0aGUgcHVycG9zZS4gSWYgdGhpcyBpcyBqdXN0IHRvIGtlZXAgV2Vz dGVybiBJU1BzIGZyb20gbW9ua2V5aW5nIHdpdGggdHJhZmZpYywgc3VyZSwgc2hpcCBpdC4gIExh YmVsbGluZyB0aGUgZW5jcnlwdGlvbiB3aXRoIGl0cyBzdHJlbmd0aCBhcyBhcHBsaWVkLCBvciBz aG93aW5nIENETnMgYW5kIElTUHMgaG93IHRvIHdvcmsgb3V0IHNvbWUgYm91bmRzLCBzZWVtcyBv bmUgd2F5IHRvIGhlbHAgdXNlcnMgdW5kZXJzdGFuZCB3aGV0aGVyIHRoaXMgY2FuIGhlbHAgdGhl bSBvciBwdXQgdGhlbSBtb3JlIGF0IHJpc2suIA0KDQotLSANCkJyaWFuIFNuaWZmZW4NCg0K From nobody Tue Jul 3 07:41:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A3239130E77 for ; Tue, 3 Jul 2018 07:41:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TALQTsPiidd4 for ; Tue, 3 Jul 2018 07:41:20 -0700 (PDT) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C7E2130E59 for ; Tue, 3 Jul 2018 07:41:19 -0700 (PDT) Received: by mail-pg0-x242.google.com with SMTP id m19-v6so1085281pgv.3 for ; Tue, 03 Jul 2018 07:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=i4QqzVfYjB0Y2lo240LBJ6NiCT+qTI3C8yRXy5IOQPY=; b=doBgce+OeGYNvYvxQx7brHKvXdhzPb9WfwHxoxvHMVyBPkFzQB69FlXQJ2Lh24IqRT zp23XHLm2YT4q27zoPBRpkUnNyoNyI2ohfOMvqs0e/2aRSZ5PSFE9WxdcBgHwBVTPeH4 Us/WOpWVrqMYqlE4BdW6NwMI1/9Gz4yap4E6x500sbC8AA8NA4oH3tqo/WUCKD4622zP 0AS86X5csZfgia+mpYgfg8pKrAJ1/Ihi/GnSTaM6DgFXM1/8u4D/R9B2BZBbiZLXKCZF fMVTwpvVNNgiyyHebHURScfuua4lDDyViEEJz7ZCx4YWHqYTYCzgfUzKJVXRfMyXRrBL du2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=i4QqzVfYjB0Y2lo240LBJ6NiCT+qTI3C8yRXy5IOQPY=; b=b9WrYSWSA/zcvdM6LzgQKrx1z/lOHNEmXivpXr2Po8Y95rzANHfnU+fGllLFxGWncF 6YCgI4z06JaoYDD1/ToHd0YnoN54laZuvmFCEyo/042Ob4vOrF5fHpeK8f7LYhu6DLgg OYxaoI1utvmRyWsynWwgkxClLhEV9ZZv5m4FY1KeHuO2Fs06t8rBc3HavtX5NdavH2Oe 343lcq8lOUrA6LItuLQy0Gii1x2EDHO4vZfZdUwFbdGNHlxKbFcaCFJdrRO0QS+wwcvg kgBVLO8M8Gyq4C2Sej5kbGNxQ5Nj8hN1SkO2kGxwmdJWLZu475ITrxgwoP4brEWbbSxl J2Wg== X-Gm-Message-State: APt69E3GNBc0P+FoF6f0NM8qbBABJTHmkgPzD8f/JXF5uEe1njTb6RbI I8t9HcrTRKRks507ObPy5e64edjL40fZgwucmN0= X-Google-Smtp-Source: AAOMgpe74y+UqtP9697IBKkZLVjh/kFaN1GLbZIQeAk4qfztRT2g7fx0NkKJw6lLJC/5pJbOOAZG7PYDs5FJSya+aFM= X-Received: by 2002:a62:4b48:: with SMTP id y69-v6mr18800793pfa.93.1530628879353; Tue, 03 Jul 2018 07:41:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a17:90a:ac18:0:0:0:0 with HTTP; Tue, 3 Jul 2018 07:41:18 -0700 (PDT) From: Allison Mankin Date: Tue, 3 Jul 2018 10:41:18 -0400 Message-ID: To: Joseph Salowey Cc: Paul Wouters , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000a30b1b0570194e10" Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 14:41:24 -0000 --000000000000a30b1b0570194e10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I haven't chimed in on the mailing list on this draft, but I'm one of the people who had discussions with browserfolk in hallways, in the corners of interim meetings for HTTP2, and other such places, in order to see what it would take to get a start on TLSA use by browsers. Due to the floods of traffic that occurred in this and other chains, I almost missed Joe's call for answers to consensus questions, but I've responded inline. Looking forward to discussion in Montreal. On 26 June 2018 at 00:20, Joseph Salowey wrote: > Hi Folks, > > There has been some discussion with a small group of folks on github - > https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to make > sure there is consensus in the working group to take on the pinning work > and see if there is consensus for modifications in the revision. Please > respond to the following questions on the list by July 10, 2018. > > 1. Do you support the working group taking on future work on a pinning > mechanism (based on the modifications or another approach)? > =E2=80=8BI support future work if there is extensive engagement and involve= ment by members of the browser community who have expressed concerns about pinning. > > 2. Do you support the reserved bytes in the revision for a future pinnin= g > mechanism? > =E2=80=8BReserving the bytes without a mechanism is not a good idea, so no.= I think the method for modifications or another approach is something to be worked on in future too. > 3. Do you support the proof of denial of existence text in the revision? > =E2=80=8BYes, this text is good.=E2=80=8B > > 4. Do you support the new and improved security considerations? > =E2=80=8BThis text is a good addition - but there are a few things that mig= ht be discussed. Generally support them. > Thanks, > > Joe > > > > On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters wrote: > >> On Mon, 4 Jun 2018, Benjamin Kaduk wrote: >> >> Hi Ben, >> >> I've taken a stab at putting together some security considerations text >>> for >>> draft-ietf-tls-dnssec-chain-extension that reflects my understanding of >>> the >>> current state of affairs. It's in a pull request at >>> https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with >>> Viktor's >>> commit to update the text about the actual DNS records involved (which = as >>> far as I can tell seems to improve the technical accuracy of the text), >>> and >>> also inserting a variable-length array that's reserved for future >>> attempts >>> to mitigate the (now-)documented security considerations. >>> >> >> Thanks for writing the proposed text. The new opaque Reserved field >> along with the denial of existence changes you propose addresses all >> my concerns. >> >> One corner case that might be worth mentioning with the proposed DoE tex= t >> is the odd corner case of hitting a server with a Host header for which >> it is not configured. You will hit the "default vhost" but you have no >> appropriate extension data to populate for that hostname. So either the >> server will return the (cached) TLSA/DoA data of the 'wrong' hostname, >> or it could just omit the extension. I'd mostly like to say something to >> prevent an implementation of forgetting this corner case and causing >> some vulnerability in their code later on by pointing to bogus memory or >> crashing on dereferencing a NULL. >> >> Some nits: >> >> If the server supports this extension it performs the appropriat= e >> DNS queries, >> >> In my PR I had changed this into "obtains the appropriate DNS RRsets", >> because I envision that TLS servers might not do DNS lookups themselves, >> but just read this via a file or other method. Eg a cron job that >> regenerates these hourly for all the hosted domains. It also reduces >> some fear that all TLS servers suddenly could need to link against >> a DNSSEC library. They don't if they can just reload a blob from disk >> regularly to serve up. >> >> Similarly: >> >> it will need to rebuild >> >> is better written as "it will need rebuilt data" >> >> >> "authenticates the chain" >> >> That should probably be "validate the chain", but the document has more >> mixups of validate vs authenticate. In my PR request I had not corrected >> them in an effort to keep the diff as small as possible. >> >> I had modified the examples slightly, so the NSEC example would show a >> simpler NSEC chain (from www to zzz) instead of the one wrapping around >> from www to the zone apex. The example quoted is the wrong NSEC record >> (the one from apex to www.example.com does not show that the >> _443._tcp.www.example.com does not exist, you need the one from >> www..example.com to the apex at the end of the >> zone) >> >> >> I'm not sure what you mean with: >> >> validated negative TTL >> >> I guess you mean to say the shortest TTL of any data in the chain? But >> sometimes the negative cache time is larger then the TTL (eg if TTL =3D = 0) >> Since this is just generic DNS handling, I would probably just write >> something like "up to the appropriate lifetime" and leave it out of >> this document. >> >> denial of existence RRset >> >> Technically that should be "RRsets" since you usually will need more the= n >> one RRset to prove this (to disprove existence of the wildcard record) >> >> - DNSSEC authentication chain extension from a server, >> SHOULD use this >> + DNSSEC authentication chain extension from a server, uses >> this >> >> I'm not sure why the SHOULD was removed here? Since it is describing TLS >> client behaviour the "uses this" confuses me as I dont know if that >> means MAY, SHOULD or MUST. >> >> + Specifically, the relevant DANE records are included >> + in the TLS handshake transcript hash, so both sides >> + possess identical records; >> >> I'm not sure why you suggest to add this text. A TLS client might still >> have cached a valid TLSA records from a previous connection 1 second >> ago and might decide to not use this information at all. Also, it seems >> to suggest that the transscript hash protects this data, but it is >> "protection" using the webpki or proof of lack of MITM, but the data >> does not need this protecting as it is protected by DNSSEC signatures. >> >> + the client remains responsible >> + for actually performing the domain name validation of >> + the DANE records. >> >> Well, if it just fired up a previous TLS connection, perhaps it will be >> content with the same pubkey used and skip re-validating this data? I >> guess we sort of say the same thing due to the lack of a MUST ? >> >> + The Reserved field is reserved for future updates to this >> + document; in particular it is hoped that the issues discussed >> + in can be addressed. >> + Implementations of this specification MUST send a zero-length >> vector >> >> Perhaps that last line can be clarified a bit: >> >> Implementation not implementing any updates to this document >> MUST send a zero-length vector >> >> This sentence does not parse: >> >> "whether or not to the exclusion" >> >> This text is a little confusing to me: >> >> + certified by the DNS key hierarchy, that the >> + server does not support DANE authentication >> >> The TLS server itself might support "DANE authentication", but there is >> simply no data. Perhaps say that the server's configured hostname does >> not support DANE authentication? >> >> Thanks again for the write up! >> >> Paul >> >> >> _______________________________________________ >> 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 > > --000000000000a30b1b0570194e10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I haven't chimed in on the mailing list on this dra= ft, but I'm one of the people who had discussions with browserfolk in h= allways, in the corners of interim meetings for HTTP2, and other such place= s, in order to see what it would take to get a start on TLSA use by browser= s.=C2=A0 Due to the floods of traffic that occurred in this and other chain= s, I almost missed Joe's call for answers to consensus questions, but I= 've responded inline.

Looking forward to discussio= n in Montreal.

On 26 June 2018 at 00:20, Joseph Salowey <joe@salowey.net> wrote:
Hi Folks,

There has been some discussion with a small group of folk= s on github -=C2=A0https://github= .com/tlswg/dnssec-chain-extension/pull/19.=C2=A0 =C2=A0I want to m= ake sure there is consensus in the working group to take on the pinning wor= k and see if there is consensus for modifications in the revision.=C2=A0 Pl= ease respond to the following questions on the list by July 10, 2018.=C2=A0=

1.=C2=A0 Do you support t= he working group taking on future work on a pinning mechanism (based on the= modifications or another approach)?
=E2=80=8BI support future work if there is extensive engagement an= d involvement by members of the browser community who have expressed concer= ns about pinning.
=C2=A0

2.=C2=A0= Do you support the reserved bytes in the revision for a future pinning mec= hanism?
=E2=80=8BReserving t= he bytes without a mechanism is not a good idea, so no.=C2=A0 I think the m= ethod for modifications or another approach is something to be worked on in= future too.

<= div dir=3D"ltr">

3.=C2=A0 Do you= support the proof of denial of existence text in the revision?
=
=E2=80=8BYes, this text is good.=E2=80= =8B
=C2=A0

4.=C2=A0 Do you support the new and i= mproved security considerations?=C2=A0
=E2=80= =8BThis text is a good addition - but there are a few things that might be = discussed.
Generally support them.


Thanks,

Joe
<= div class=3D"m_-6417127586548372813gmail-yj6qo m_-6417127586548372813gmail-= ajU" style=3D"outline:none;padding:10px 0px;width:22px;margin:2px 0px 0px;f= ont-size:12.8px;text-decoration-style:initial;text-decoration-color:initial= ">


<= div class=3D"h5">On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters <paul@nohats.ca= > wrote:
<= div class=3D"h5">On Mon, 4 Jun 2018, Benjamin Kaduk wrote:

Hi Ben,

I've taken a stab at putting together some security considerations text= for
draft-ietf-tls-dnssec-chain-extension that reflects my understanding o= f the
current state of affairs.=C2=A0 It's in a pull request at
https://github.com/tlswg/dnssec-chain-ex= tension/pull/19 , along with Viktor's
commit to update the text about the actual DNS records involved (which as far as I can tell seems to improve the technical accuracy of the text), and=
also inserting a variable-length array that's reserved for future attem= pts
to mitigate the (now-)documented security considerations.

 Thanks for writing the proposed text. The new opaque Reserved field
along with the denial of existence changes you propose addresses all
my concerns.

One corner case that might be worth mentioning with the proposed DoE text is the odd corner case of hitting a server with a Host header for which
it is not configured. You will hit the "default vhost" but you ha= ve no
appropriate extension data to populate for that hostname. So either the
server will return the (cached) TLSA/DoA data of the 'wrong' hostna= me,
or it could just omit the extension. I'd mostly like to say something t= o
prevent an implementation of forgetting this corner case and causing
some vulnerability in their code later on by pointing to bogus memory or crashing on dereferencing a NULL.

Some nits:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the server supports this extension it perfor= ms the appropriate DNS queries,

In my PR I had changed this into "obtains the appropriate DNS RRsets&q= uot;,
because I envision that TLS servers might not do DNS lookups themselves, but just read this via a file or other method. Eg a cron job that
regenerates these hourly for all the hosted domains. It also reduces
some fear that all TLS servers suddenly could need to link against
a DNSSEC library. They don't if they can just reload a blob from disk regularly to serve up.

Similarly:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 it will need to rebuild

is better written as "it will need rebuilt data"


=C2=A0 =C2=A0 =C2=A0 =C2=A0 "authenticates the chain"

That should probably be "validate the chain", but the document ha= s more
mixups of validate vs authenticate. In my PR request I had not corrected them in an effort to keep the diff as small as possible.

I had modified the examples slightly, so the NSEC example would show a
simpler NSEC chain (from www to zzz) instead of the one wrapping around
from www to the zone apex. The example quoted is the wrong NSEC record
(the one from apex to www.example.com does not show that the
_443._tcp.www.example.com does not exist, you need the one from
www..example.com to the apex at the end of the zone)


I'm not sure what you mean with:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 validated negative TTL

I guess you mean to say the shortest TTL of any data in the chain? But
sometimes the negative cache time is larger then the TTL (eg if TTL =3D 0)<= br> Since this is just generic DNS handling, I would probably just write
something like "up to the appropriate lifetime" and leave it out = of
this document.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 denial of existence RRset

Technically that should be "RRsets" since you usually will need m= ore then
one RRset to prove this (to disprove existence of the wildcard record)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0 =C2=A0 DNSSEC authentication cha= in extension from a server, SHOULD use this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 DNSSEC authentication cha= in extension from a server, uses this

I'm not sure why the SHOULD was removed here? Since it is describing TL= S
client behaviour the "uses this" confuses me as I dont know if th= at
means MAY, SHOULD or MUST.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + Specifically, the relevant DANE records are i= ncluded
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + in the TLS handshake transcript hash, so both= sides
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + possess identical records;

I'm not sure why you suggest to add this text. A TLS client might still=
have cached a valid TLSA records from a previous connection 1 second
ago and might decide to not use this information at all. Also, it seems
to suggest that the transscript hash protects this data, but it is
"protection" using the webpki or proof of lack of MITM, but the d= ata
does not need this protecting as it is protected by DNSSEC signatures.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + the client remains responsible
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + for actually performing the domain name valid= ation of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + the DANE records.

Well, if it just fired up a previous TLS connection, perhaps it will be
content with the same pubkey used and skip re-validating this data? I
guess we sort of say the same thing due to the lack of a MUST ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + The Reserved field is reserved for future upd= ates to this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + document; in particular it is hoped that the = issues discussed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + in <xref target=3D"increasing-trust&q= uot; /> can be addressed.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + Implementations of this specification MUST se= nd a zero-length vector

Perhaps that last line can be clarified a bit:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Implementation not implementing any updates to = this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST send a zero-length vector

This sentence does not parse:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "whether or not to the exclusion"

This text is a little confusing to me:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + certified by the DNS key hierarchy, that the<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 + server does not support DANE authentication
The TLS server itself might support "DANE authentication", but th= ere is
simply no data.=C2=A0 Perhaps say that the server's configured hostname= does
not support DANE authentication?

Thanks again for the write up!=

Paul


_______________________________________________
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


--000000000000a30b1b0570194e10-- From nobody Tue Jul 3 08:21:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360F7130E50 for ; Tue, 3 Jul 2018 08:21:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.51 X-Spam-Level: X-Spam-Status: No, score=-17.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyLTudw21Ixj for ; Tue, 3 Jul 2018 08:21:03 -0700 (PDT) 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 05DFC130E6D for ; Tue, 3 Jul 2018 08:20:36 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id t135-v6so2057538iof.7 for ; Tue, 03 Jul 2018 08:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OCwaTDHW3hQDiNCcGNiml7/pZQi2jvxfVZRUb9RB8A8=; b=XibhJCIANy49GcvLNpLs5jY5RzD2kktN6JkoE4v6gCJT0cir+4XWUoo+S4TveYozlX QE4H0Iqkuvx6jtqet+A9a1/e4PWRmBCK/5wZY2FZqOrU1ViSKsKXe06R9VM6mp9548HE ycpvm5Y2bqYdaWoQMDqSa/a90UC7Er6DibgPig5tJVSwnsIaFQzKgqiK/wv0rHC/X97c mAKb+eoVexD9wgda1Iarw0N5qviedD7zvXJwk6Iz7Glnef4oUhwVpFuHnuFEaE7OzOP9 5L03hC3+ywCcdOgJMEmlf6/WZ7vwzfGYBb9kGeor22l4Bhwwkj7V+/dbhU/8AZQ6Nqp8 jRoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OCwaTDHW3hQDiNCcGNiml7/pZQi2jvxfVZRUb9RB8A8=; b=XrGqp48uhowDMC2hQL3tr9ftmRSqMT9tK8wpbj820uPt7npBxzBDkxEWUp3XUXJcsd n7j6IoX6LTtcPQX28zx11ytjeA2shYE94wdvVYZdjgJikSvdlJgt8EOPubEOZTqADctP 8w/6FJjjU+dXftBrGHQyoSFvARwSEuwQN+2ptlpxlIZiCoMDyuXJWwkCAUZK70Jgftbr RCRIG6KBOrCOqjZgniRlEX/F67T4LQfOat7dQZwsuDkG1zQeO/cj3cVD1SMhwggLN6sr EAXCklh7r8SNQ8e7R10kRIRYLnpNjMAgL11ooT4TKNuIObgjIY/FHjUm736cBZibSOHM RqCQ== X-Gm-Message-State: APt69E1583kE8xPU1CPjHsjsLRYTD5wPV9z2Ekopw5RUOCT44qTI+XnV pQysR2MO4IoHswXvVs8VVWrUCZQU1TNTpsZF0W8f2Q== X-Google-Smtp-Source: AAOMgpeq6eJgLLFBZ42NaxJPZ8ewCV/zVE2tceIGk1ml9T7+oDBfuVHThWcGOU50BOiXPYclL+T4XWQCHVu9JMNm4So= X-Received: by 2002:a6b:f812:: with SMTP id o18-v6mr23636860ioh.235.1530631234713; Tue, 03 Jul 2018 08:20:34 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ben Schwartz Date: Tue, 3 Jul 2018 11:20:22 -0400 Message-ID: To: Eric Rescorla Cc: "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000129580057019dbb5" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 15:21:11 -0000 --000000000000129580057019dbb5 Content-Type: multipart/alternative; boundary="00000000000007a999057019dbdb" --00000000000007a999057019dbdb Content-Type: text/plain; charset="UTF-8" On Mon, Jul 2, 2018 at 7:41 PM Eric Rescorla wrote: > Hi folks, > > I just submitted: > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 > > This draft describes a DNS-based approach to doing encrypted SNI. > Thanks for this proposal, Eric. I fully support this line of work. This proposal obviously bears some relevance to the SNI Alt-Svc + DNS ALTSVC drafts in HTTPBIS [1][2]. That's OK; we'll sort it out eventually. I hope people interested in this draft will also check out those. In my view, ESNI and those drafts are two complementary approaches to this problem. I can see reasons to pick one, or both, or a combination. [1] https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02 [2] https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02 On Mon, Jul 2, 2018 at 11:59 PM Eric Rescorla wrote: > On Mon, Jul 2, 2018 at 8:53 PM, Paul Wouters wrote: > ... > It is strongly recommended not to use TXT records. Why not use a new >> RRTYPE? Everything these days knows how to serve unknown record types >> (see RFC 3597). The only possibly exception is provisioning tools of >> small players, but this document starts of saying you basically need >> to be on a bulk hosting provider anyway. They can properly provision. >> > > See: > > https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906 > > That logic (CNAME compatibility) requires not placing this information at the apex, i.e. using a prefix, as you've done. It doesn't preclude using a new record type. The DNS ALTSVC draft, for example, does both. Some other thoughts: I expect much nitpicking of the exact DNS syntax. You may end up wanting to describe that separately, especially since these "introduction tokens" may well be useful to acquire over non-DNS channels (e.g. Alt-Svc) and may be useful for non-SNI purposes (like 0-RTT, as you've noted). I wonder how well this scales to a "large key" future (e.g. post-quantum). As described, this approach seems hard to use with a domain load-balanced across two CDNs. (I don't know how important that use case is.) One concern I've heard many times is that we can't add non-A/AAAA queries to a browser's critical path because there are middleboxes and buggy recursives that will just drop them, leading to a DNS timeout delay on every new socket. However, for encrypted SNI I think we can ignore this by focusing on clients with DPRIVE or DOH enabled, which should avoid these kinds of problems. --00000000000007a999057019dbdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 2,= 2018 at 7:41 PM Eric Rescorla <ekr@rtfm= .com> wrote:
Hi folks,

I just submitted:

=C2=A0 https://tools.ietf.org/html/draft-rescorla-tls-esni-00

This= draft describes a DNS-based approach to doing encrypted SNI.

Thanks for this proposal, Eric.=C2=A0 I fully = support this line of work.

This proposal obviously= bears some relevance to the SNI Alt-Svc=C2=A0+ DNS ALTSVC drafts in HTTPBI= S [1][2].=C2=A0 That's OK; we'll sort it out eventually.=C2=A0 I ho= pe people interested in this draft will also check out those.=C2=A0 In my v= iew, ESNI and those drafts are two complementary approaches to this problem= .=C2=A0 I can see reasons to pick one, or both, or a combination.


On Mon, Jul 2, 2018 at 11:59 PM Eric Rescorla= <ekr@rtfm.com> wrote:
On Mon, Jul 2, = 2018 at 8:53 PM, Paul Wouters=C2=A0<paul@nohats.ca>=C2=A0wrote:
=
...=C2=A0
It= is strongly recommended not to use TXT records. Why not use a new
RRTYP= E? Everything these days knows how to serve unknown record types
(see RF= C 3597). The only possibly exception is provisioning tools of
small play= ers, but this document starts of saying you basically need
to be on a bu= lk hosting provider anyway. They can properly provision.

See:

That logic (CNAME compatibility) requires not placing this= information at the apex, i.e. using a prefix, as you've done.=C2=A0 It= doesn't preclude using a new record type.=C2=A0 The DNS ALTSVC draft, = for example, does both.

Some other thoughts:=

I expect much nitpicking of the exact DNS syntax.= =C2=A0 You may end up wanting to describe that separately, especially since= these "introduction tokens" may well be useful to acquire over n= on-DNS channels (e.g. Alt-Svc) and may be useful for non-SNI purposes (like= 0-RTT, as you've noted).

I wonder how well th= is scales to a "large key" future (e.g. post-quantum).
=
As described, this approach seems hard to use with a domain = load-balanced across two CDNs.=C2=A0 (I don't know how important that u= se case is.)

One concern I've heard many times= is that we can't add non-A/AAAA queries to a browser's critical pa= th because there are middleboxes and buggy recursives that will just drop t= hem, leading to a DNS timeout delay on every new socket.=C2=A0 However, for= encrypted SNI I think we can ignore this by focusing on clients with DPRIV= E or DOH enabled, which should avoid these kinds of problems.
--00000000000007a999057019dbdb-- --000000000000129580057019dbb5 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDCkYXL9gkVLR2ttij+/YC4 gd+j7Ry/nP3O/UXK11rbATAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA3MDMxNTIwMzVaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEApN07o8Db9DJclcVrn2+lxMnVyOqxLPgwD1p2k+C9 1iC/6uq1wWshLTURmOHBJVRop8l17Y/8tWyUPcbxf/+Y/Z1vRqklsvmIZunkDUuW/6qpz1s/aJbn 4Y+In4yuQPUfOwY8GYTOrl4c4MNt3bJL5w6fHOwWId5o1TAGrMKtTb+1eZWQsKWur9cddOTxvjKn LOcua7rzel2vZ5+4qRMSfz9aqtHH1vSXXPSwfccTcPJCFCNF/i4CBfVGuE5CfYrUm/YXQomhLB54 FaLqJZ+MszVozLFxcIdPAnS6iEu7ohN41a/GHCEFm17ZYel+l6ectiBzRWlJeM6ajOT8XWrjOg== --000000000000129580057019dbb5-- From nobody Tue Jul 3 08:26:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 401D8130EA8 for ; Tue, 3 Jul 2018 08:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNroRWNs5wNu for ; Tue, 3 Jul 2018 08:26:52 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id D8D50130E52 for ; Tue, 3 Jul 2018 08:26:52 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by linode64.ducksong.com (Postfix) with ESMTPSA id 86F263A05E for ; Tue, 3 Jul 2018 11:26:52 -0400 (EDT) Received: by mail-oi0-f44.google.com with SMTP id r16-v6so4616345oie.3 for ; Tue, 03 Jul 2018 08:26:52 -0700 (PDT) X-Gm-Message-State: APt69E3FXVfv6R63WWdYhO+xeAKehYsw3tmVYGsf47X8f6G+v2sivmxt pWBMoeuUaV8aXdC9UhMA+QQn7vTM/Mnh+cERwXU= X-Google-Smtp-Source: AAOMgpfAR6VYJ0+4/nd8U9P90v03l8KnCwzSYiqeFFD+ltRQs0LiuoddYWa4XPrhX8srF9btH+VCSH+NqJ3gXGtdMT8= X-Received: by 2002:aca:e7c8:: with SMTP id e191-v6mr19769086oih.132.1530631612244; Tue, 03 Jul 2018 08:26:52 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 08:26:51 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Tue, 3 Jul 2018 11:26:51 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ben Schwartz Cc: Eric Rescorla , "" Content-Type: multipart/alternative; boundary="00000000000087b732057019f15f" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 15:26:55 -0000 --00000000000087b732057019f15f Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 11:20 AM, Ben Schwartz < bemasc=40google.com@dmarc.ietf.org> wrote: > > One concern I've heard many times is that we can't add non-A/AAAA queries > to a browser's critical path because there are middleboxes and buggy > recursives that will just drop them, leading to a DNS timeout delay on > every new socket. However, for encrypted SNI I think we can ignore this by > focusing on clients with DPRIVE or DOH enabled, which should avoid these > kinds of problems. > > yes, and of course encrypting sni is a lot more valuable when the dns query is also encrypted. --00000000000087b732057019f15f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018 at 11:20 AM, Ben Schwartz <bema= sc=3D40google.com@dmarc.ietf.org> wrote:

One concern I've heard many times is that we can't add non-A/AAA= A queries to a browser's critical path because there are middleboxes an= d buggy recursives that will just drop them, leading to a DNS timeout delay= on every new socket.=C2=A0 However, for encrypted SNI I think we can ignor= e this by focusing on clients with DPRIVE or DOH enabled, which should avoi= d these kinds of problems.


yes, and of course encrypting sni is a= lot more valuable when the dns query is also encrypted.

=
=C2=A0
--00000000000087b732057019f15f-- From nobody Tue Jul 3 08:41:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E72FD130FB7 for ; Tue, 3 Jul 2018 08:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogsZmKo55qbp for ; Tue, 3 Jul 2018 08:41:03 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7583F130F75 for ; Tue, 3 Jul 2018 08:41:03 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41KpHd3wrlzCqj; Tue, 3 Jul 2018 17:41:01 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530632461; bh=1gZwU97IHQ/lb5a953PrCGgSYlnOeTnQ/a9dAcWcN0E=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=gjNH9oGycnEDf6HlV7zOXuo+5KA7kauoBBR3aYGl4moEVP9pCXYf+4EdlLXTQZ9rJ o6ubJ6n/vpB1mFjbNdtqRZV5DamfJrSm/sRFZt9mljB3iJ4MnIoNTWsn1uLmflq2e3 ueMfczlAJsruEVhaDvczJhrCpaH29Nm3WdnGh/RE= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LVNEQ4y-MBm2; Tue, 3 Jul 2018 17:41:00 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 3 Jul 2018 17:40:59 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7EE2A3A3EC1; Tue, 3 Jul 2018 11:40:58 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 7EE2A3A3EC1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7686645755C2; Tue, 3 Jul 2018 11:40:58 -0400 (EDT) Date: Tue, 3 Jul 2018 11:40:58 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: "" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 15:41:13 -0000 On Mon, 2 Jul 2018, Eric Rescorla wrote: > It is strongly recommended not to use TXT records. Why not use a new > RRTYPE? Everything these days knows how to serve unknown record types > (see RFC 3597). The only possibly exception is provisioning tools of > small players, but this document starts of saying you basically need > to be on a bulk hosting provider anyway. They can properly provision. > > See: > https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906 [Can we keep the discussion within the IETF and the Note Well please. We also don't know what happens in 10 years with these links.] quoting from that link: These facts lead to the conclusion that if we choose RRtype as the method, there would often be cases where the DNS record of the ESNIKey and the TLS server would be required to be operated by different entities. That seems to have confused two things with each other. I did not say anything about the location of the DNS record, only of the RRTYPE. Clearly, with the same location, it would be under control of the same entity, so I don't understand why you bring this up as a reason against using a dedicated RRTYPE. Here is another argument against it, besides the generic IETF policy of trying to not overload things or create kitchen sinks. If you used, or were forced to use, a DNS under control of someone who can block things, they might be instructed to block anything related to encrypted SNI, and they might decide to just block all TXT records, even unrelated ones, resulting in collateral damage. Paul From nobody Tue Jul 3 08:56:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0B0130E66 for ; Tue, 3 Jul 2018 08:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dx4atgdq2KjG for ; Tue, 3 Jul 2018 08:56:16 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C714130EAC for ; Tue, 3 Jul 2018 08:56:10 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41Kpd422R1zCqj; Tue, 3 Jul 2018 17:56:08 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530633368; bh=Gunc9kZZIsxIz5exwq65EeO2N+tGbyGEqc6n6K311fo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=MqqLnIv/D/fqER46hOD0+cytrVIWhRw4gu6F63/mfN7qBBT5ZV3xl06tSN3QmURfy NdfixoH3atzXGddYLSvkP3nbFqvIgMx+RjcPOAa+0O9QYGnuInHlG9UPu1g9bhbxIh /KlNw4u2UyD/8KjtsryhNKiITe2cnm/Nk7HeACt8= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id SMSC3Shx0RnE; Tue, 3 Jul 2018 17:56:06 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 3 Jul 2018 17:56:05 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 0B3D43A3EC1; Tue, 3 Jul 2018 11:56:04 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 0B3D43A3EC1 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id F346A45755C1; Tue, 3 Jul 2018 11:56:04 -0400 (EDT) Date: Tue, 3 Jul 2018 11:56:04 -0400 (EDT) From: Paul Wouters To: Allison Mankin cc: Joseph Salowey , "" , Benjamin Kaduk In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 15:56:19 -0000 On Tue, 3 Jul 2018, Allison Mankin wrote: > 2.  Do you support the reserved bytes in the revision for a future pinning mechanism? > > ​Reserving the bytes without a mechanism is not a good idea, so no.  I think the method for modifications or another approach is > something to be worked on in future too. Reserved bytes are always under specified, that is why they are reserved. For instance, yesterdy ekr filed a draft for encrypted SNI with this: struct { uint8 checksum[4]; KeyShareEntry keys<4..2^16-1>; CipherSuite cipher_suites<2..2^16-2>; uint16 padded_length; uint64 not_before; uint64 not_after; Extension extensions<0..2^16-1>; } ESNIKeys; extensions A list of extensions that the client can take into consideration when generating a Client Hello message. The format is defined in [I-D.ietf-tls-tls13]; Section 4.2. The purpose of the field is to provide room for additional features in the future; this document does not define any extension. So there is a whole extension block with no specification and no idea even if it would ever be needed. That is much weaker then the need for TLS extension pinning. Additionally, let me remind you of the direction that the solution would take if this is punted completely to a new document: https://tools.ietf.org/html/draft-asmithee-tls-dnssec-downprot-00 The smithee draft is a terrible idea. We can do better. Paul From nobody Tue Jul 3 08:56:35 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 694B9130EE5 for ; Tue, 3 Jul 2018 08:56:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id blWmqQy9_26x for ; Tue, 3 Jul 2018 08:56:18 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B8B8130EDC for ; Tue, 3 Jul 2018 08:56:11 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id w76-v6so865624ywg.4 for ; Tue, 03 Jul 2018 08:56:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IFSdvseXODobNHtw0MfsJ2BfcRC0KHpJ0tMGmsUQxEU=; b=d+ed12hXs2hCXN5b80rk+yCWD7B90YoEAQegxGRy+OKeVxKbOk6Ya+qrldjxhgrAk7 M84OdtQPcjeyvj6i3VKHmCjSbFntiXygxEYxPdaxz79sNQEpjVbpg/FCgkzwFawp4jiB zsLA79qhNh+i0toCJbV2hMu2NJnaorsPh6Uub9lu/Ks9IIrlTbA+u6q+AE/D4cMNm6Zy FiYMxLRI8KxUPP3JyR1GOnBU4TkoBoPHWW+539X68bATRDJJ5UriGnNoEH+Xet/KB+Ma oPAYELtXaA98RzflF6/Fd4ZFlr80cVHZNkwX4tLZqUSdnlbHXICEYshIVM2Teo7d+Tfo Knjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IFSdvseXODobNHtw0MfsJ2BfcRC0KHpJ0tMGmsUQxEU=; b=rzhOc1/UomLsfpyCaMLj2CgUX/9K0PHzW6pPz/WTOAh6Dzg4VFFrsZFvFXZi9XoJax D/BFb3JK2jducR4EBFd7hQWIalJ6UXdGIqWknrcpmmTyC5kEgO2m7eTmiK/RiM1jl0Y2 PQx8qJ9GEX0b5V6K7a1pT9RWzo2wpv34o1VFhBOzFnIU8yebljaWN5/NfwhwVwzSs6Zd cuHrp6yViu7S3GQuwqZGkFkS6cAtmrfmKoH3q8mRQVzinnjt7d/x08ePWprjWP5rc9o3 /3/PwcnuDPj/wIbQCwhHR4UvBztzFLOfHjLOFNkOrgSTZuxVZc2e6zO92yn0ajfkiNg+ y0bg== X-Gm-Message-State: APt69E3vuIUjX1h+DBMbgzZlWky4iNEzpgNLBx5ivzB5ur+fpRISyk3H Ob8EQKKB2WnAX599iWEkebb0hBfl+Bu8t2cw32fbOw== X-Google-Smtp-Source: AAOMgpeuJ7iCzTQzhrAcg1IeP27R5xNfMigouCa2+FI/slk8HfAWYXlNm8szUcK5iUP6uMEws8mAb5bV937eeQXriW8= X-Received: by 2002:a81:2ec8:: with SMTP id u191-v6mr14728632ywu.430.1530633370265; Tue, 03 Jul 2018 08:56:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 08:55:29 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 3 Jul 2018 08:55:29 -0700 Message-ID: To: Paul Wouters Cc: "" Content-Type: multipart/alternative; boundary="00000000000050ffdd05701a5a18" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 15:56:31 -0000 --00000000000050ffdd05701a5a18 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 8:40 AM, Paul Wouters wrote: > On Mon, 2 Jul 2018, Eric Rescorla wrote: > > It is strongly recommended not to use TXT records. Why not use a new >> RRTYPE? Everything these days knows how to serve unknown record >> types >> (see RFC 3597). The only possibly exception is provisioning tools of >> small players, but this document starts of saying you basically need >> to be on a bulk hosting provider anyway. They can properly >> provision. >> >> See: >> https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issu >> ecomment-388531906 >> > > [Can we keep the discussion within the IETF and the Note Well please. We > also don't know what happens in 10 years with these links.] > If you look carefully, you'll see that this discussion happened weeks ago. I was just pointing you at it because you asked why we did it the way we did. With that said,IETF policy does not prohibit having discussions on Github. We do it regularly in TLS and it's the standard policy in QUIC. > quoting from that link: > > These facts lead to the conclusion that if we choose RRtype as the > method, there would often be cases where the DNS record of the > ESNIKey > and the TLS server would be required to be operated by different > entities. > > That seems to have confused two things with each other. I did not say > anything about the location of the DNS record, only of the RRTYPE. > Clearly, with the same location, it would be under control of the same > entity, so I don't understand why you bring this up as a reason against > using a dedicated RRTYPE. > I'm just quoting Kazuho here, so I'll let him respond to himself. -Ekr --00000000000050ffdd05701a5a18 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018 at 8:40 AM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 2 Jul = 2018, Eric Rescorla wrote:

=C2=A0 =C2=A0 =C2=A0 It is strongly recommended not to use TXT records. Why= not use a new
=C2=A0 =C2=A0 =C2=A0 RRTYPE? Everything these days knows how to serve unkno= wn record types
=C2=A0 =C2=A0 =C2=A0 (see RFC 3597). The only possibly exception is provisi= oning tools of
=C2=A0 =C2=A0 =C2=A0 small players, but this document starts of saying you = basically need
=C2=A0 =C2=A0 =C2=A0 to be on a bulk hosting provider anyway. They can prop= erly provision.

See:
https://github.com/ekr= /draft-rescorla-tls-esni/issues/7#issuecomment-388531906

 [Can we keep the discussion within the IETF and the Note Well please. We =C2=A0also don't know what happens in 10 years with these links.]

If you look carefully, you'll see that t= his discussion happened weeks ago. I was
just pointing you at it = because you asked why we did it the way we did.

With that said,IETF policy does not prohibit having discussions on Github= . We do it
regularly in TLS and it's the standard policy in = QUIC.

=C2=A0
quoting from that link:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 These facts lead to the conclusion that if we c= hoose RRtype as the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 method, there would often be cases where the DN= S record of the ESNIKey
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and the TLS server would be required to be oper= ated by different
=C2=A0 =C2=A0 =C2=A0 =C2=A0 entities.

That seems to have confused two things with each other. I did not say
anything about the location of the DNS record, only of the RRTYPE.
Clearly, with the same location, it would be under control of the same
entity, so I don't understand why you bring this up as a reason against=
using a dedicated RRTYPE.

I'm just quoting Kazuho= here, so I'll let him respond to himself.

-Ekr


--00000000000050ffdd05701a5a18-- From nobody Tue Jul 3 09:05:56 2018 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 37A8E130FE8; Tue, 3 Jul 2018 09:00:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: tls@ietf.org, kaduk@mit.edu X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063362422.4893.713341966814367762.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:24 -0700 Archived-At: Subject: [TLS] tls - Requested sessions have been scheduled for IETF 102 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 List-Id: "This is the mailing list 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, 03 Jul 2018 16:00:34 -0000 Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:00 requested) Monday, 16 July 2018, Afternoon Session I 1330-1530 Room Name: Place du Canada size: 300 --------------------------------------------- tls Session 2 (1:00 requested) Thursday, 19 July 2018, Afternoon Session III 1810-1910 Room Name: Laurier size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/tls.ics Request Information: --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Sean Turner Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 120 Conflicts to Avoid: First Priority: acme cfrg curdle dispatch httpbis mls perc quic rtcweb stir saag secdispatch suit teep tokbind uta Second Priority: dprive ace Third Priority: tcpinc lamps sidr sidrops People who must be present: Eric Rescorla Rich Salz Sean Turner Joseph A. Salowey Hannes Tschofenig Yoav Nir Martin Thomson Daniel Kahn Gillmor Benjamin Kaduk Nick Sullivan Subodh Iyengar David Benjamin Kyle Nekritz Resources Requested: Special Requests: --------------------------------------------------------- From nobody Tue Jul 3 10:08:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82FF812F1A6 for ; Tue, 3 Jul 2018 10:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DLCOWJqpStik for ; Tue, 3 Jul 2018 10:08:35 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 ED7D212D949 for ; Tue, 3 Jul 2018 10:08:34 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id p17-v6so4188615itc.2 for ; Tue, 03 Jul 2018 10:08:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=Xf1cE8KMIKhoDensj4uEYNSjvp2GLvzjYtwpFMZn/Tw=; b=FBvfMiu1mteujMwckH4Xy08UjvRzTEvOXgyB0/XXr900ydwe8HCPw5X6FLfSE5GSCB Yr+x9ssOnJmvy4SXodyBoGuhe2Jh5nfssM+EZOOibjKJruoFiANn6uo87JBqd1HORUmg JpjhMIiKmAASsLg3xIeChLc21y+dRCB5VrcDKowuQhIe2jBZZ59CZz0bBPHeia9N4zax EluaboAzbZCarpwhZh4WpfNAmtmyW3uD9SaQkvGWg+ZRZxwehVoZYan5jHhrv0zZYpqV 6LePlv/w4PwLo06kfhhdhhLRcVgelUqYaRIuk/HkAgEPvHl0s0RqQSDqN9g+WM1fFB6B eI0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=Xf1cE8KMIKhoDensj4uEYNSjvp2GLvzjYtwpFMZn/Tw=; b=Mt+ZHvtxOsFyKCEw10/2iWB0xiXPVa8/0a2aHGCcyf3bvJ4GTxpm77MP/8ylNZwL5g WAEDq2aFR60vw5Nlo0iQr/vhjYHYuuFwtu4RY3ZxnzLtE2kS6OUn6BjsZzw9E5IBUeF1 QopJzbsYSr5OjQerpHLTozv+gjjXojNeTv5BoVy1p5Ns0/AFEDQUs/RwaGcYyx/BPWsk 0hg67/wUz0Efre9mb3g5oMiX0byOk+MrZ/YE68eSY4B80vBBC+I5UU/Yj8UgYFwpo6/W chiHJUdHhDe2X5P1e6PHATxIXh4QmII1YVcCVno3rXNFsx43dMwsOar+mV9XEzKcBGGI Y49w== X-Gm-Message-State: APt69E1Y5z01d5n8JvDF8xcwGGrmqTlYmKPeH6B3qDcJzGirQ5JanX7W RZNXRBHaMRkQIP87cm0vs7j2Ots1 X-Google-Smtp-Source: AAOMgpdlQmHj7aJQK6HwPEX9DGAvDEexYfGM1QWZbZB/2kHjn7rQD6350KQGA8htJUW7l68QsezUpg== X-Received: by 2002:a24:6ed0:: with SMTP id w199-v6mr10221074itc.65.1530637713719; Tue, 03 Jul 2018 10:08:33 -0700 (PDT) Received: from [10.249.203.139] (67-128-146-21.dia.static.qwest.net. [67.128.146.21]) by smtp.gmail.com with ESMTPSA id m186-v6sm730911ita.11.2018.07.03.10.08.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 03 Jul 2018 10:08:32 -0700 (PDT) From: Bret Jordan Content-Type: multipart/alternative; boundary="Apple-Mail=_94932F3E-CC2B-42AE-B931-A55DCA16EC68" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: Date: Tue, 3 Jul 2018 11:08:21 -0600 To: tls@ietf.org X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 17:08:39 -0000 --Apple-Mail=_94932F3E-CC2B-42AE-B931-A55DCA16EC68 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =46rom a discussion on the PATIENT list found here: = https://www.ietf.org/mail-archive/web/patient/current/msg00078.html = =46rom my personal perspective, we need to be careful with all of these = efforts. It feels like the pendulum has swung so far to one side, the = side of privacy-at-any-cost, that we are unknowingly increasing the risk = to individuals and organizations by enabling threat actors and = intrusions sets to attack networks and clients without any level of = protection from the network.=20 It also feels like a lot of these initiatives are being done without = adequately involving and ensuring that enterprise networks and critical = infrastructure can work with these changes. Question, do we know how = these ideas and changes are going to impact an organizations ability to = fulfill their requirements for regulatory compliance?=20 If we continue down these paths, then I fear networks will be required = to wrap all traffic in some other less secure protocol, outright deny = some of these protocols, or be forced to fully proxy all traffic or take = an approach that Google has done with their BeyondCorp design. =20 The IETF work needs to do more outreach with enterprise networks and = critical infrastructure and be fundamentally more inclusive. = Privacy-at-any-cost is not a holistic design.=20 Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." ### Copied content from the PATIENT discussion #### On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty = > wrote: On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla > wrote: > > > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski > wrote: >> >> Your point is one that deserves further discussion, Eric - which = seems >> likely to scale rapidly going forward. It is key. >> >> So how does draft-ietf-tls-sni-encryption it into the argument? > > > As you suggest, SNI encryption is intended to conceal the SNI, which = of > course would make SNI inspection difficult. > > My evaluation of the current state of SNI encryption is that given the > current technical state, it will not see particularly wide deployment, = with > the primary scenario being "at-risk" sites who are subject to = censorship who > either hide behind or co-tenant with sites which are not subject to > censorship. That probably isn't going to be incredibly common right = now. Of > course, this is regrettable from the perspective of people designing = these > protocols, but I think that's the situation. EKR posted a draft to encrypt SNI, see: https://www.ietf.org/mail-archive/web/tls/current/msg26468.html = It targets the CDNs who host most of the web traffic in the US at least. The right place to comment on this would be the TLS list of course, but since proposals are being posted, this is a reality and needs to be discussed. Those using SNI need to make sure their use cases are clear and understood and argue the pros and cons. Kathleen, Thanks for pointing out this draft. As they say, predictions are hard, especially about the future. In = March, the ESNI problem looked pretty intractable and then subsequently = we had this idea about why it might be workable. -Ekr Best regards, Kathleen > > -Ekr > >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote: >> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > >> wrote: >>> >>> Hi Diego, >>> >>> It is also worth referencing a relatively recent Lawfare article on = the >>> scaling litigation in the U.S. against those supporting e2e = encryption >>> services or capabilities. >>> >>> = https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits= -supporting-isis = >>> >>> This litigation trend is also likely to increase the insurance costs = of >>> providers. Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, = may not >>> even be able to get insurance. It may be fun and games to play = crypto rebel >>> in venues like the IETF where the risk exposure is minimal, but when = it >>> comes to real world consequences and costs, the equations for = providers are >>> rather different. >> >> >> I think this rather overestimates the degree to which both TLS 1.3 = and >> QUIC change the equation about what a provider is able to determine = from >> traffic inspection. As a practical matter, the primary change from = TLS 1.2 >> is that the provider does not get to see the server's certificate, = but it >> does see the SNI. Given that the SNI contains the identity of the = server >> that the client is connected to and that the other identities in the >> certificate are often whatever the provider decided to co-locate on = the same >> machine, I'm not sure how much information you are really losing. >> >> -Ekr >> >>> >>> >>> >>> --tony >>> >>> >>> _______________________________________________ >>> PATIENT mailing list >>> PATIENT at ietf.org >>> https://www.ietf.org/mailman/listinfo/patient = >> >> >> >> >> _______________________________________________ >> PATIENT mailing list >> PATIENT at ietf.org >> https://www.ietf.org/mailman/listinfo/patient = >> >> > > > _______________________________________________ > PATIENT mailing list > PATIENT at ietf.org > https://www.ietf.org/mailman/listinfo/patient = > --=20 Best regards, Kathleen --Apple-Mail=_94932F3E-CC2B-42AE-B931-A55DCA16EC68 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
=46rom a discussion on the PATIENT list found here: https://www.ietf.org/mail-archive/web/patient/current/msg00078.= html


=46rom my personal perspective, we need = to be careful with all of these efforts. It feels like the pendulum has = swung so far to one side, the side of privacy-at-any-cost, that we = are unknowingly increasing the risk to individuals and organizations = by enabling threat actors and intrusions sets to attack networks = and clients without any level of protection from the network. 

It also feels like a lot of these initiatives = are being done without adequately involving and ensuring that enterprise = networks and critical infrastructure can work with these changes. = Question, do we know how these ideas and changes are going to impact = an organizations ability to fulfill their requirements for = regulatory compliance? 

If we continue = down these paths, then I fear networks will be required to wrap all = traffic in some other less secure protocol, outright deny some of = these protocols, or be forced to fully proxy all traffic or take an = approach that Google has done with their BeyondCorp = design.  

The IETF work needs to = do more outreach with enterprise networks and critical infrastructure = and be fundamentally more inclusive. Privacy-at-any-cost is not a = holistic design. 

Thanks,
Bret
PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 = 0050
"Without = cryptography vihv vivc ce xhrnrw, however, the only thing that can not = be unscrambled is an = egg."



### Copied content from the PATIENT = discussion ####


On Tue, Jul 3, 2018 at 8:09 = AM, Kathleen Moriarty <kathleen.moriarty.ietf at gmail.com> wrote:
On Sun, Mar = 18, 2018 at 9:06 AM, Eric Rescorla <ekr at rtfm.com> = wrote:
>
>
> On Sun, = Mar 18, 2018 at 12:54 PM, Tony Rutkowski <tony at yaanatech.co..uk>
> wrote:
>>
>> Your point is one that deserves further discussion, = Eric - which seems
>> likely to scale rapidly going = forward.  It is key.
>>
>> = So how does draft-ietf-tls-sni-encryption it into the argument?
>
>
> As you suggest, = SNI encryption is intended to conceal the SNI, which of
>= course would make SNI inspection difficult.
>
> My evaluation of the current state of SNI encryption is = that given the
> current technical state, it will not = see particularly wide deployment, with
> the primary = scenario being "at-risk" sites who are subject to censorship who
> either hide behind or co-tenant with sites which are not = subject to
> censorship. That probably isn't going to = be incredibly common right now. Of
> course, this is = regrettable from the perspective of people designing these
> protocols, but I think that's the situation.

EKR posted a draft to encrypt SNI, = see:
https://www.ietf.org/mail-archive/web/tls/current/msg26468.html

It targets the CDNs who host most of the web = traffic in the US at
least.  The right place to = comment on this would be the TLS list of
course, but since = proposals are being posted, this is a reality and
needs to = be discussed.  Those using SNI need to make sure their use
cases are clear and understood and argue the pros and = cons.

Kathleen,

Thanks for pointing out this draft.

As they say, predictions are = hard, especially about the future. In March, the ESNI problem looked = pretty intractable and then subsequently we had this idea about why it = might be workable.

-Ekr

Best regards,
Kathleen

>
> -Ekr
>
>> On 18-Mar-18 8:45 AM, Eric = Rescorla wrote:
>>
>> On Sun, = Mar 18, 2018 at 12:30 PM, Tony Rutkowski <tony at = yaanatech.co.uk>
>> wrote:
>>>
>>> Hi Diego,
>>>
>>> It is also worth = referencing a relatively recent Lawfare article on the
>>> scaling litigation in the U.S. against those = supporting e2e encryption
>>> services or = capabilities.
>>>
>>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis
>>>
>>> This litigation trend = is also likely to increase the insurance costs of
>>> providers.  Indeed, a provider that = supports TLS1.3, QUIC, SNI, etc, may not
>>> even = be able to get insurance.  It may be fun and games to play crypto = rebel
>>> in venues like the IETF where the risk = exposure is minimal, but when it
>>> comes to = real world consequences and costs, the equations for providers are
>>> rather different.
>>
>>
>> I think this rather = overestimates the degree to which both TLS 1.3 and
>> = QUIC change the equation about what a provider is able to determine = from
>> traffic inspection. As a practical matter, = the primary change from TLS 1.2
>> is that the = provider does not get to see the server's certificate, but it
>> does see the SNI. Given that the SNI contains the = identity of the server
>> that the client is = connected to and that the other identities in the
>> = certificate are often whatever the provider decided to co-locate on the = same
>> machine, I'm not sure how much information = you are really losing.
>>
>> = -Ekr
>>
>>>
>>>
>>>
>>> --tony
>>>
>>>
>>> = _______________________________________________
>>> PATIENT mailing list
>>> PATIENT at = ietf.org
>>> https://www.ietf.org/mailman/listinfo/patient
>>
>>
>>
>>
>> _______________________________________________
>> PATIENT mailing = list
>> PATIENT at = ietf.org
>> https://www.ietf.org/mailman/listinfo/patient
>>
>>
>
>
> _______________________________________________
> PATIENT mailing list
> PATIENT at = ietf.org
> https://www.ietf.org/mailman/listinfo/patient
>



-- 

Best regards,
Kathleen

= --Apple-Mail=_94932F3E-CC2B-42AE-B931-A55DCA16EC68-- From nobody Tue Jul 3 10:12:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6E8130E07 for ; Tue, 3 Jul 2018 10:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.09 X-Spam-Level: X-Spam-Status: No, score=-4.09 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=bcbsm.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TQk72hp7DNB6 for ; Tue, 3 Jul 2018 10:12:29 -0700 (PDT) Received: from mx.z120.zixworks.com (bcbsm.zixworks.com [199.30.235.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575D8130F50 for ; Tue, 3 Jul 2018 10:12:28 -0700 (PDT) Received: from 127.0.0.1 (ZixVPM [127.0.0.1]) by Outbound.z120.zixworks.com (Proprietary) with SMTP id ABEBE1C1097 for ; Tue, 3 Jul 2018 12:12:27 -0500 (CDT) Received: from imsva1.bcbsm.com (inetmta03.bcbsm.com [12.107.172.80]) by mx.z120.zixworks.com (Proprietary) with SMTP id E2D6F1C108C; Tue, 3 Jul 2018 12:12:26 -0500 (CDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id B100292065; Tue, 3 Jul 2018 13:12:26 -0400 (EDT) Received: from imsva1.bcbsm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5992792053; Tue, 3 Jul 2018 13:12:26 -0400 (EDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (unknown [216.32.181.243]) by imsva1.bcbsm.com (Postfix) with ESMTPS; Tue, 3 Jul 2018 13:12:26 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bcbsm.onmicrosoft.com; s=selector1-bcbsm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GkXoUVjv9FX7hYPLNvQYICsNmbKIN5K9tJL7WsSlmB0=; b=AF04O7oYt7PAZgy0UY1ignwYCCAh0LL+dbyTkHyfZZ1Diw8PK7C51DPmoRERFH9ZPOcoGi6Q/eIJtJ84k01xozNLjE+w2o5NihtUMXm/7pi8DWTYOhNjXom0hFYSHnvB/mk6jxtRT65pSbnV59Vu88M8wIHfmHOeLQ5TGjoIMGk= Received: from CY1PR14MB0842.namprd14.prod.outlook.com (10.169.21.22) by CY1PR14MB0013.namprd14.prod.outlook.com (10.162.46.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.18; Tue, 3 Jul 2018 17:12:23 +0000 Received: from CY1PR14MB0842.namprd14.prod.outlook.com ([fe80::3cbb:6eeb:6151:ca25]) by CY1PR14MB0842.namprd14.prod.outlook.com ([fe80::3cbb:6eeb:6151:ca25%2]) with mapi id 15.20.0930.016; Tue, 3 Jul 2018 17:12:23 +0000 From: "Ackermann, Michael" To: Bret Jordan , "tls@ietf.org" Thread-Topic: [TLS] Encrypted SNI Thread-Index: AQHUEvCJXFbBAoXmbECeECowNVpCMqR9vBsA Date: Tue, 3 Jul 2018 17:12:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=MAckermann@bcbsm.com; x-originating-ip: [165.225.39.55] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY1PR14MB0013; 7:kZAfBCPu5I2m09+NEGMu2BYphOm2FVx8cWcRQNPcdbmd7HEzMRP65DVybyUjI8ClUKQLTb+bygRLHWgph0pvefJ4mCxOEd5sPbSlyQo2Z+uGcwEGn1ZU/T1sVIzON5a6DvWJJW+XmK5lHS//kqXy/isy/PDTrQAWQvn+MIki0U7so0ly6taB40Ws4Asqdue5FoH6BBMKadD6Q0g1GGDm02j/fP+eYBIBI7kegIl2ST+jNwP7Xqr/zJVuI7E9u4mB; 20:rS72qz+fGxOVkdeIMIxL4cTd0wz/ruk+AmCVL4ZxEeg/ITTual1lbFiRwto93ywJBSCSOVNItaC2LrXG2FYNSpTbSNTeFrF7sjwGKb2ONZVrsZtLSuObqv2eR6SJMMG2TvRrx2f3OEwfDxzb7g57BQNT8uAeWShJJw5XADXYFlY= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: b89ceba0-be75-4fe5-4dd3-08d5e10824f1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7167020)(7153060)(7193020); SRVR:CY1PR14MB0013; x-ms-traffictypediagnostic: CY1PR14MB0013: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(85827821059158)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:CY1PR14MB0013; BCL:0; PCL:0; RULEID:; SRVR:CY1PR14MB0013; x-forefront-prvs: 0722981D2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(376002)(346002)(396003)(39860400002)(366004)(189003)(199004)(51444003)(6246003)(2501003)(25786009)(110136005)(53386004)(80792005)(186003)(6306002)(54896002)(8936002)(55016002)(9686003)(5250100002)(8676002)(81156014)(81166006)(2900100001)(6506007)(102836004)(55236004)(14454004)(97736004)(316002)(86362001)(26005)(76176011)(7696005)(39060400002)(14444005)(256004)(53936002)(53546011)(106356001)(606006)(6116002)(790700001)(3846002)(6436002)(99286004)(19609705001)(72206003)(476003)(5660300001)(478600001)(105586002)(966005)(11346002)(446003)(486006)(2906002)(66066001)(33656002)(21615005)(74316002)(1680700002)(229853002)(7736002)(68736007)(236005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR14MB0013; H:CY1PR14MB0842.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bcbsm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: NEyn/3pO1XcqV3JY0D07DzvwL5Z1x+XIudZ8B79SLGJx4/kN5pxziCDseyvPwKqxX/1lbuGZcBf/ufRwDNc5omakjxgfu0k1L8f39ReICwEwWHhF1G54pWj+uHNzhHx9a/QMCkdqdoBARoEJUjaklhVtdAlOOLZANPjSuPJ10vRaDpd0nATzmpTcyMqgQOdNcP2kgl4E5siEK6C4RAFauDXEdIQDeawVL/4b5AoBqXZrghMwgqIlSmFw7bvp7/Tap7ZPJv9m9KiWTHJy6tHD1nn5Ty4FuyWApxE4Z3k6HbVjNrz7Yzcb8xgV2AbrAsXei40fjgytS32uImZbJRW97F/1iPKSj7TML1IM06Im50E= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR14MB08420EFE5A2119EF57E0448FD7420CY1PR14MB0842namp_" MIME-Version: 1.0 X-OriginatorOrg: bcbsm.com X-MS-Exchange-CrossTenant-Network-Message-Id: b89ceba0-be75-4fe5-4dd3-08d5e10824f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2018 17:12:23.7524 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 6f56d3fa-5682-4261-b169-bc0d615da17c X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR14MB0013 X-TM-AS-GCONF: 00 X-VPM-HOST: vmvpm01.z120.zixworks.com X-VPM-GROUP-ID: 79e7a6f4-1882-4704-a684-edd1f13706c9 X-VPM-MSG-ID: 76521237-0ad1-4abb-8764-53479293759b X-VPM-ENC-REGIME: Plaintext X-VPM-IS-HYBRID: 0 Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 17:12:45 -0000 --_000_CY1PR14MB08420EFE5A2119EF57E0448FD7420CY1PR14MB0842namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 From: TLS =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Bret Jordan Sent: Tuesday, July 3, 2018 1:08 PM To: tls=40ietf.org Subject: =5BTLS=5D Encrypted SNI From=20a discussion on the PATIENT list found here: = https://www.ietf.org/mail-archive/web/patient/current/msg00078.html From=20my personal perspective, we need to be careful with all of these = efforts. It feels like the pendulum has swung so far to one side, the side = of privacy-at-any-cost, that we are unknowingly increasing the risk to = individuals and organizations by enabling threat actors and intrusions = sets to attack networks and clients without any level of protection from = the network. It also feels like a lot of these initiatives are being done without = adequately involving and ensuring that enterprise networks and critical = infrastructure can work with these changes. Question, do we know how these = ideas and changes are going to impact an organizations ability to fulfill = their requirements for regulatory compliance? If we continue down these paths, then I fear networks will be required to = wrap all traffic in some other less secure protocol, outright deny some of = these protocols, or be forced to fully proxy all traffic or take an = approach that Google has done with their BeyondCorp design. The IETF work needs to do more outreach with enterprise networks and = critical infrastructure and be fundamentally more inclusive. = Privacy-at-any-cost is not a holistic design. Thanks, Bret PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 =22Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg.=22 =23=23=23 Copied content from the PATIENT discussion =23=23=23=23 On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty > wrote: On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla > wrote: > > > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski ..uk> > wrote: >> >> Your point is one that deserves further discussion, Eric - which seems >> likely to scale rapidly going forward. It is key. >> >> So how does draft-ietf-tls-sni-encryption it into the argument? > > > As you suggest, SNI encryption is intended to conceal the SNI, which of > course would make SNI inspection difficult. > > My evaluation of the current state of SNI encryption is that given the > current technical state, it will not see particularly wide deployment, = with > the primary scenario being =22at-risk=22 sites who are subject to = censorship who > either hide behind or co-tenant with sites which are not subject to > censorship. That probably isn't going to be incredibly common right now. = Of > course, this is regrettable from the perspective of people designing these > protocols, but I think that's the situation. EKR posted a draft to encrypt SNI, see: https://www.ietf.org/mail-archive/web/tls/current/msg26468.html It targets the CDNs who host most of the web traffic in the US at least. The right place to comment on this would be the TLS list of course, but since proposals are being posted, this is a reality and needs to be discussed. Those using SNI need to make sure their use cases are clear and understood and argue the pros and cons. Kathleen, Thanks for pointing out this draft. As they say, predictions are hard, especially about the future. In March, = the ESNI problem looked pretty intractable and then subsequently we had = this idea about why it might be workable. -Ekr Best regards, Kathleen > > -Ekr > >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote: >> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > >> wrote: >>> >>> Hi Diego, >>> >>> It is also worth referencing a relatively recent Lawfare article on the >>> scaling litigation in the U.S. against those supporting e2e encryption >>> services or capabilities. >>> >>> = https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-= supporting-isis >>> >>> This litigation trend is also likely to increase the insurance costs of >>> providers. Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, = may not >>> even be able to get insurance. It may be fun and games to play crypto = rebel >>> in venues like the IETF where the risk exposure is minimal, but when it >>> comes to real world consequences and costs, the equations for = providers are >>> rather different. >> >> >> I think this rather overestimates the degree to which both TLS 1.3 and >> QUIC change the equation about what a provider is able to determine from >> traffic inspection. As a practical matter, the primary change from TLS = 1.2 >> is that the provider does not get to see the server's certificate, but it >> does see the SNI. Given that the SNI contains the identity of the server >> that the client is connected to and that the other identities in the >> certificate are often whatever the provider decided to co-locate on the = same >> machine, I'm not sure how much information you are really losing. >> >> -Ekr >> >>> >>> >>> >>> --tony >>> >>> >>> _______________________________________________ >>> PATIENT mailing list >>> PATIENT at ietf.org >>> https://www.ietf.org/mailman/listinfo/patient >> >> >> >> >> _______________________________________________ >> PATIENT mailing list >> PATIENT at ietf.org >> https://www.ietf.org/mailman/listinfo/patient >> >> > > > _______________________________________________ > PATIENT mailing list > PATIENT at ietf.org > https://www.ietf.org/mailman/listinfo/patient > -- Best regards, Kathleen The information contained in this communication is highly confidential and = is intended solely for the use of the individual(s) to whom this = communication is directed. If you are not the intended recipient, you are = hereby notified that any viewing, copying, disclosure or distribution of = this information is prohibited. Please notify the sender, by electronic = mail or telephone, of any unintended receipt and delete the original = message without making any copies. =20 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are = nonprofit corporations and independent licensees of the Blue Cross and = Blue Shield Association. --_000_CY1PR14MB08420EFE5A2119EF57E0448FD7420CY1PR14MB0842namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D--><=21--=5Bif gte mso 9=5D> <=21=5Bendif=5D-->

&=2343;1

 

From: TLS = =5Bmailto:tls-bounces=40ietf.org=5D On Behalf Of Bret Jordan
Sent: Tuesday, July 3, 2018 1:08 PM
To: tls=40ietf.org
Subject: =5BTLS=5D Encrypted SNI

 

From a discussion on the PATIENT list found = here: https://www.ietf.org/mail-archive/web/patient/current/msg00078.html

 

 

From my personal perspective, we need to be = careful with all of these efforts. It feels like the pendulum has swung so = far to one side, the side of privacy-at-any-cost, that we are = unknowingly increasing the risk to individuals and organizations by enabling threat actors and intrusions sets to attack networks and = clients without any level of protection from the network. 

It also feels like a lot of these initiatives are being done without = adequately involving and ensuring that enterprise networks = and critical infrastructure can work with these changes. Question, do = we know how these ideas and changes are going to impact = an organizations ability to fulfill their requirements for regulatory compliance? 

If we continue down these paths, then I fear networks will be required to = wrap all traffic in some other less secure protocol, outright deny = some of these protocols, or be forced to fully proxy all traffic or take = an approach that Google has done with their BeyondCorp design.  

The IETF work needs to do more outreach with enterprise networks and = critical infrastructure and be fundamentally more inclusive. = Privacy-at-any-cost is not a holistic design. 

 

Thanks,

Bret

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 = 74F8 ACAE 7415 0050

"Without cryptography vihv vivc ce xhrnrw, however, the = only thing that can not be unscrambled is an egg."

 

 

 

=23=23=23 Copied content from the PATIENT = discussion =23=23=23=23

 

 

On Tue, = Jul 3, 2018 at 8:09 AM, Kathleen Moriarty <kathleen.moriarty.ietf at = gmail.com> wrote:

On Sun, = Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr at rtfm.com> wrote:
>
>
> On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski <tony at yaanatech.co..uk>
> wrote:
>>
>> Your point is one that deserves further discussion, Eric - which = seems
>> likely to scale rapidly going forward.  It is key.
>>
>> So how does draft-ietf-tls-sni-encryption it into the argument?
>
>
> As you suggest, SNI encryption is intended to conceal the SNI, which = of
> course would make SNI inspection difficult.
>
> My evaluation of the current state of SNI encryption is that given = the
> current technical state, it will not see particularly wide = deployment, with
> the primary scenario being "at-risk" sites who are subject = to censorship who
> either hide behind or co-tenant with sites which are not subject to
> censorship. That probably isn't going to be incredibly common right = now. Of
> course, this is regrettable from the perspective of people designing = these
> protocols, but I think that's the situation.

EKR posted a draft to encrypt SNI, see:
https://www.ietf.org/mail-archive/web/tls/current/msg= 26468.html

It targets the CDNs who host most of the web traffic in the US at
least.  The right place to comment on this would be the TLS list of
course, but since proposals are being posted, this is a reality and
needs to be discussed.  Those using SNI need to make sure their use
cases are clear and understood and argue the pros and = cons.

&nb= sp;

Kathleen= ,

&nb= sp;

Thanks = for pointing out this draft.

&nb= sp;

As they = say, predictions are hard, especially about the future. In March, the ESNI = problem looked pretty intractable and then subsequently we had this idea = about why it might be workable.

&nb= sp;

-Ekr

&nb= sp;

Best = regards,
Kathleen


>
> -Ekr
>
>> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>>
>> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <tony at = yaanatech.co.uk>
>> wrote:
>>>
>>> Hi Diego,
>>>
>>> It is also worth referencing a relatively recent Lawfare = article on the
>>> scaling litigation in the U.S. against those supporting e2e = encryption
>>> services or capabilities.
>>>
>>> https://www.lawfareblog.com/did-congress-immunize-twi= tter-against-lawsuits-supporting-isis
>>>
>>> This litigation trend is also likely to increase the = insurance costs of
>>> providers.  Indeed, a provider that supports TLS1.3, = QUIC, SNI, etc, may not
>>> even be able to get insurance.  It may be fun and games = to play crypto rebel
>>> in venues like the IETF where the risk exposure is minimal, = but when it
>>> comes to real world consequences and costs, the equations for = providers are
>>> rather different.
>>
>>
>> I think this rather overestimates the degree to which both TLS = 1.3 and
>> QUIC change the equation about what a provider is able to = determine from
>> traffic inspection. As a practical matter, the primary change = from TLS 1.2
>> is that the provider does not get to see the server's = certificate, but it
>> does see the SNI. Given that the SNI contains the identity of the = server
>> that the client is connected to and that the other identities in = the
>> certificate are often whatever the provider decided to co-locate = on the same
>> machine, I'm not sure how much information you are really = losing.
>>
>> -Ekr
>>
>>>
>>>
>>>
>>> --tony
>>>
>>>
>>> _______________________________________________
>>> PATIENT mailing list
>>> PATIENT = at ietf.org
>>> https://www.ietf.org/mailman/listinfo/patient
>>
>>
>>
>>
>> _______________________________________________
>> PATIENT mailing list
>> PATIENT at = ietf.org
>> https://www.ietf.org/mailman/listinfo/patient
>>
>>
>
>
> _______________________________________________
> PATIENT mailing list
> PATIENT at = ietf.org
> https://www.ietf.org/mailman/listinfo/patient
>


-- 

Best regards,
Kathleen

 


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

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

--_000_CY1PR14MB08420EFE5A2119EF57E0448FD7420CY1PR14MB0842namp_-- From nobody Tue Jul 3 12:49:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5F31130E08 for ; Tue, 3 Jul 2018 12:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yoeCfEr-NAW7 for ; Tue, 3 Jul 2018 12:49:08 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91D3130DFB for ; Tue, 3 Jul 2018 12:49:08 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w63Jkim9005216; Tue, 3 Jul 2018 20:49:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=lWUB3457aM1RjuBWOTXxogzgUNtOSTpHc5PZT1wJk4E=; b=WYUxhKKbUz4Dr8Ku2eK2rbGVMZjw+wDEm+F0e5vdyR4zNltqQxkAma8dKsLyMANthzmI E0LM0GoJyoWAfNfO7zXhGIvsvlJb36s/pI2vsf7mCgN4xlbIjvixlRbvsJmjMOa18oez JK8oCXrQ6rc3M72Zv8gwfh8mCBAG2DW4JbeE5/mASH6JQ/WSMhHLXZwQ68xRLyq2vKzm Llkb8wyS9feRobIT0SBkPuyw9HMgY+MBPBXkl7TXsRFmZMNwSo5kma15ndKUr6siUT17 /mkRE8bUV1AHTcMvtnkScCou7/LJosjfJWVL38sBki1gp8MOSUxygg6WUWUeYsDUuOT9 Aw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2jx1ju9ufw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jul 2018 20:49:06 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w63JYuXw025688; Tue, 3 Jul 2018 15:49:04 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2jx56v1q9f-1; Tue, 03 Jul 2018 15:49:04 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 801C32293E; Tue, 3 Jul 2018 19:49:04 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1faRIN-0003GJ-TD; Tue, 03 Jul 2018 14:49:03 -0500 Date: Tue, 3 Jul 2018 14:49:03 -0500 From: Benjamin Kaduk To: Bret Jordan Cc: tls@ietf.org Message-ID: <20180703194903.GA14551@akamai.com> 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) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-03_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=8 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030222 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-03_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=8 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030224 Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 19:49:14 -0000 On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan wrote: > From a discussion on the PATIENT list found here: https://www.ietf.org/mail-archive/web/patient/current/msg00078.html > > > From my personal perspective, we need to be careful with all of these efforts. It feels like the pendulum has swung so far to one side, the side of privacy-at-any-cost, that we are unknowingly increasing the risk to individuals and organizations by enabling threat actors and intrusions sets to attack networks and clients without any level of protection from the network. BCP 61 leads us to not expect any protection from the network, does it not? > It also feels like a lot of these initiatives are being done without adequately involving and ensuring that enterprise networks and critical infrastructure can work with these changes. Question, do we know how these ideas and changes are going to impact an organizations ability to fulfill their requirements for regulatory compliance? > > If we continue down these paths, then I fear networks will be required to wrap all traffic in some other less secure protocol, outright deny some of these protocols, or be forced to fully proxy all traffic or take an approach that Google has done with their BeyondCorp design. I suspect you will find that many proponents of the proposals you find worrisome would also be enthusiastic proponents of "an approach similar to what Google has done with BeyondCorp". Such a discussion would be off-topic for the TLS list, but you would probably be well-served to have some supporting text for why this sort of approach should be considered bad, if you want to gain sympathy for your perspective. -Ben > The IETF work needs to do more outreach with enterprise networks and critical infrastructure and be fundamentally more inclusive. Privacy-at-any-cost is not a holistic design. > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can not be unscrambled is an egg." > > > > ### Copied content from the PATIENT discussion #### > > > On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty > wrote: > On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla > wrote: > > > > > > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski > > wrote: > >> > >> Your point is one that deserves further discussion, Eric - which seems > >> likely to scale rapidly going forward. It is key. > >> > >> So how does draft-ietf-tls-sni-encryption it into the argument? > > > > > > As you suggest, SNI encryption is intended to conceal the SNI, which of > > course would make SNI inspection difficult. > > > > My evaluation of the current state of SNI encryption is that given the > > current technical state, it will not see particularly wide deployment, with > > the primary scenario being "at-risk" sites who are subject to censorship who > > either hide behind or co-tenant with sites which are not subject to > > censorship. That probably isn't going to be incredibly common right now. Of > > course, this is regrettable from the perspective of people designing these > > protocols, but I think that's the situation. > > EKR posted a draft to encrypt SNI, see: > https://www.ietf.org/mail-archive/web/tls/current/msg26468.html > > It targets the CDNs who host most of the web traffic in the US at > least. The right place to comment on this would be the TLS list of > course, but since proposals are being posted, this is a reality and > needs to be discussed. Those using SNI need to make sure their use > cases are clear and understood and argue the pros and cons. > > Kathleen, > > Thanks for pointing out this draft. > > As they say, predictions are hard, especially about the future. In March, the ESNI problem looked pretty intractable and then subsequently we had this idea about why it might be workable. > > -Ekr > > Best regards, > Kathleen > > > > > -Ekr > > > >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote: > >> > >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > > >> wrote: > >>> > >>> Hi Diego, > >>> > >>> It is also worth referencing a relatively recent Lawfare article on the > >>> scaling litigation in the U.S. against those supporting e2e encryption > >>> services or capabilities. > >>> > >>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis > >>> > >>> This litigation trend is also likely to increase the insurance costs of > >>> providers. Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, may not > >>> even be able to get insurance. It may be fun and games to play crypto rebel > >>> in venues like the IETF where the risk exposure is minimal, but when it > >>> comes to real world consequences and costs, the equations for providers are > >>> rather different. > >> > >> > >> I think this rather overestimates the degree to which both TLS 1.3 and > >> QUIC change the equation about what a provider is able to determine from > >> traffic inspection. As a practical matter, the primary change from TLS 1.2 > >> is that the provider does not get to see the server's certificate, but it > >> does see the SNI. Given that the SNI contains the identity of the server > >> that the client is connected to and that the other identities in the > >> certificate are often whatever the provider decided to co-locate on the same > >> machine, I'm not sure how much information you are really losing. > >> > >> -Ekr > >> > >>> > >>> > >>> > >>> --tony > >>> > >>> > >>> _______________________________________________ > >>> PATIENT mailing list > >>> PATIENT at ietf.org > >>> https://www.ietf.org/mailman/listinfo/patient > >> > >> > >> > >> > >> _______________________________________________ > >> PATIENT mailing list > >> PATIENT at ietf.org > >> https://www.ietf.org/mailman/listinfo/patient > >> > >> > > > > > > _______________________________________________ > > PATIENT mailing list > > PATIENT at ietf.org > > https://www.ietf.org/mailman/listinfo/patient > > > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 3 12:50:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D0F6130DFB for ; Tue, 3 Jul 2018 12:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qucegHRPJIBO for ; Tue, 3 Jul 2018 12:50:04 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.114]) (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 8CE4A130DF6 for ; Tue, 3 Jul 2018 12:50:04 -0700 (PDT) Received: from [67.219.250.196] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-b.us-west-2.aws.symcld.net id 05/8C-01618-B63DB3B5; Tue, 03 Jul 2018 19:50:03 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1VSa0hTYRjuO+dsO5WL09T2NiprFNHiDKdROu0 eUT+CCgnsQp21k1ttU3YmrizQQAkvXcwVW2lGq9CK8pZSGGF3Na1FTiwRtaJEu5dFdjlnn92+ X8/3PM/7Pu/38dKkqleuoXm3i3c6OJtWPobqmFp7id3+KGFDdNf1GXFvOgNE3Pu2PLSIWOH3f yVWDJUSq4n1MqvDlOreIrM8/XaWSjuzxN174DSVhaoX5qExNMUUkJAzXCaXLipmPwHnKmtJfH mKoPDuS1keGk3LmWhob7hDSDiCWQQ3gmUhPpzRwbWCYzLMz4b2q6UKjI3wuWVALmGKmQ7VeRd CHiWzEcr7vBQOyEHQ8f0TKQmjxaaD76pDxYiZAENN50NhJKOGzmcnQhiYCOh52CzHOBJe9f2Q Yf9GKPnQOMJroeVJFoXxZAicyEdSGDA1BNR6PiqwwMJbj4fEeBUcrmtSYFMngufZJSNpOug7H Rgp2AG3smvENFrERtjvWY7pKVBR2EPh2gYSTu0dlGFhEgwfySWwMCCD7C5vqJGKMUNxRaMcCw dICN58ojiIdL5/nopxGQLvJZsv9Gfj4Z73GYV5Hfj3/lRgHAV1g8dJH1KIOBFqzJidBsX5PSO OuZDb+k5ehugKFGdyWlMsLjtntbGG6GjWYIhhDbGxrGFOvJ7bxZr06QKbwQsuNkbPZQh6Yad9 q82sd/CuKiRu2ijx1KMvL82NaCJNaCOVUZUJG1TjTKnmnRZOsGx2ptt4oRFNomktKJ0BURvv5 FN49zarTVzX3zLQYdoI5XJJVgppnF2wpmCpCcXSr8uLikh6+I2niFRRjlQHr1Erx0pWRrJa0h 1/Gv1e/QCarAlXInE0VVga77RbXf/r/UhNI2240iR1CbM6XH/y+sVRCHGUgsvx0igu7q+kyUJ HvMuWDmR+WzvXMK8iJmnc0dYvzWvSys1rugqT1Fdm+Sa0XXxcuNj/oMnfkPm1uHr1hZmJUzWf c1ydVVEvds+vTG7rrn/tS9Cqb982Bs96MnKb44ciEqft6l9pvL8lOdZZ1Z28oCVpnXFf0L4ps vVQZok76lr+/K37Tj43RFYFH+8xtmkpwcIZdKRT4H4B8UF3tvUDAAA= X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-34.tower-344.messagelabs.com!1530647401!758586!1 X-Originating-IP: [216.32.181.176] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 30697 invoked from network); 3 Jul 2018 19:50:02 -0000 Received: from mail-by2nam01lp0176.outbound.protection.outlook.com (HELO NAM01-BY2-obe.outbound.protection.outlook.com) (216.32.181.176) by server-34.tower-344.messagelabs.com with AES256-SHA256 encrypted SMTP; 3 Jul 2018 19:50:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=z/V87qq+FiWz00+UqMj15GMZEXGNKJ9NPSsuEajN18A=; b=D7Emj6BXDBHlXSQ/03ul6uFbyTlUQEoVuyg+23UBZ4mSBuguuim1pQXkGxa8PLRh07n2KkEDtQ5d/SSKPrxGgjsfwjZy3pTkpXyBBuhtpuQUejFa/BaLRDhYXna4QT1otUFd6vK2qXEvtW8iU3GJFJsLJ/ICHROASwRHJqhDtZs= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1202.namprd14.prod.outlook.com (10.173.162.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.906.24; Tue, 3 Jul 2018 19:50:00 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::b914:e52:554d:c7bb%9]) with mapi id 15.20.0906.026; Tue, 3 Jul 2018 19:50:00 +0000 From: Tim Hollebeek To: Paul Wouters , "tls@ietf.org" Thread-Topic: [TLS] DNS-based Encrypted SNI Thread-Index: AQHUEl5DQHvGBn+nBkqNOZQLHEqyD6R83gWAgAEK4rA= Date: Tue, 3 Jul 2018 19:50:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [173.71.184.143] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1202; 7:DSlhlTh4GvPDTofbflAvy6WveZfNOgwu2GM3l/7jLrsHys+FvbsbuAZ0zfA1TtomW4HHuLZpkAMoU1lZAQjSX4RQ2NMmEjP+r4M+T+6ZYMWKYGuEW5TD2pps646iKN8HMfe/WpdEuqYNcCFtmk20ij6kZOhgIzdeYqgmVX/oeRGS8f61+V02Vag7y5l8Y0fzC4SCB3mYz4w7N/R8Bvd6yWYFDs95kkpVO0nPVfmCChxsi7SggOXVxiNKyHBNgcw+ x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 2992acd7-5aa9-4bf6-7816-08d5e11e299a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1202; x-ms-traffictypediagnostic: BN6PR14MB1202: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(20558992708506); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(10201501046)(3231254)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1202; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1202; x-forefront-prvs: 0722981D2A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(396003)(39860400002)(376002)(346002)(199004)(189003)(13464003)(102836004)(9686003)(14444005)(5250100002)(74316002)(256004)(110136005)(8936002)(25786009)(478600001)(6436002)(11346002)(81156014)(81166006)(86362001)(2501003)(26005)(55016002)(105586002)(2906002)(8676002)(186003)(476003)(6306002)(229853002)(305945005)(97736004)(7736002)(53546011)(446003)(106356001)(3846002)(6116002)(316002)(33656002)(76176011)(68736007)(66066001)(6506007)(5660300001)(486006)(99936001)(966005)(99286004)(44832011)(53936002)(2900100001)(14454004)(7696005)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1202; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: T//W6AFT00SQWdeirZKCfdynx9M3NlQndEWN9Kb/ZH1bHRl9yVvHQoltr0a3a7W1XEZ8C7zQAjx1M8IZK7hvDMAyveDLLqr+hIdiljMvtrUFZLKgQfaeWqENGPXZ5gdhryBxzyTN37AcUmJkSmDmKQdWRvRYxcAXyUAiJH0URXOfrvlHMoMGIhaLGM1lkc313sEoGClFTJ7Rhh72B/mnNIBOj6xsmj31zY1LdzIJUPUGOXePMYxhrDvQ5LgpVgBmAvk6np91c3MXyZVAQRfRsZpZUyjLz20gFUsm2OsXskMxch2PX6KvDpVhfPA27/iyMAKDKOQeRnsV2/IIH0ZN/mcmEWEXuGyL4sITE4baD6Y= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_023B_01D412E5.7D52B4D0" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2992acd7-5aa9-4bf6-7816-08d5e11e299a X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2018 19:50:00.4499 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1202 Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 19:50:07 -0000 ------=_NextPart_000_023B_01D412E5.7D52B4D0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit One of the things we found out with CAA is that this extremely optimistic view of the support for unknown RR types by large hosting providers is not accurate. -Tim > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Paul Wouters > Sent: Monday, July 2, 2018 11:53 PM > To: tls@ietf.org > Subject: Re: [TLS] DNS-based Encrypted SNI > > On Mon, 2 Jul 2018, Eric Rescorla wrote: > > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 > > > This is at a pretty early stage, so comments, questions, defect > > reports welcome. > > > This structure is placed in the RRData section of a TXT record as a > base64-encoded string. If this encoding exceeds the 255 octet limit > of TXT strings, it must be split across multiple concatenated strings > as per Section 3.1.3 of [RFC4408]. > > It is strongly recommended not to use TXT records. Why not use a new > RRTYPE? Everything these days knows how to serve unknown record types (see > RFC 3597). The only possibly exception is provisioning tools of small > players, > but this document starts of saying you basically need to be on a bulk > hosting > provider anyway. They can properly provision. > > I need to think more about the document to see if there is really not > something > simpler or better possible. > > Paul > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ------=_NextPart_000_023B_01D412E5.7D52B4D0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNzAzMTk0OTU1WjAvBgkqhkiG9w0BCQQxIgQgWn6/CP6oYOwPUtmr2FGYQ+5xmFkh ivhXbcPKlAIaVkcwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBAKNjVmlCXX6chepyrRm0Vg1Nb6CVe2eMoit1rf0pzfhtMXEahxzOJ5kHo2HJuKhCq3oUWuE3 hdkX3FaG+b/Zm002byeHJpMQWs4GK5IR01hbzF3ze6i4zbHSdlqm/KlLcGmETwaEKtK8SM9Xfq/+ NYMmlxMc0DYrt5o21N7akbFDEypdcSpD9tP2OwFw+kk9qsdGiaK9J0ZCuYRMej7YrrRxBMkJUm8s vSs5XS+FrQPf4ZzZpfRCUynn2xIeWlc0L3r9jHVyZ9VECRz1p3pw0CWbq7UFq2qLgkRJiX5lp1KU wqdzzZWAVsBJ7NbOzcZ0MKs9Zk3gFEVoO6JeXEAZs90AAAAAAAA= ------=_NextPart_000_023B_01D412E5.7D52B4D0-- From nobody Tue Jul 3 13:09:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF242130FC8 for ; Tue, 3 Jul 2018 13:09:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0VzAe7ZsfsW for ; Tue, 3 Jul 2018 13:09:32 -0700 (PDT) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE98130DFB for ; Tue, 3 Jul 2018 13:09:32 -0700 (PDT) Received: by mail-qt0-x243.google.com with SMTP id y31-v6so2721570qty.9 for ; Tue, 03 Jul 2018 13:09:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DJeSrOmCxGVxAvULeUDOihWlAmrXeF588Y15FSfbnL8=; b=mT8IyT511J4tBkQA6JgHzpIQj9r1Vv7ACT+blLnTLxDUMaZUgGMkR03a6soaroZuOU GbwZxtzSqxkvRvDLeHn8XIxDxbqE4jDew1Eb3a9jFNQfav+zq+qrzlLbhqopQggPSMGW hrJctMmLa715wDwOl844ZHTJmghCms0cwHvEh76KWtpC6KbiEgNjvbK5OVXaNbOuvjBx ZXitGCfAnnBXWsU91WDn/CH5YPCuZlXRJlevpISpJTyVk/NAU6KLRhHUruoswJbs2bon Wf+lvgBnBMPNjUQ2jxYdXd52DNdTiKb54jZsZmV7xYBZ9bAq5ACbFYnPMdQdALYtvvvA diEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DJeSrOmCxGVxAvULeUDOihWlAmrXeF588Y15FSfbnL8=; b=kKVrIgXOACdA34A+4vpdKq3ZQTM2RCS56JcKyMBqcN+4Ojq56w0xb1zBMdTlDdpemX UjLUSY/4s/FLcxJenp/9TV4zyHSLovs8NDEGVWsknz/0X4LTUBXK5uutgeKmWyfPqGNZ CwSHyja/rHEbnKQ2jAdEPs8GePEqiVQTlv1/m0kjxMYgOFfboHzi6MyM4IDZYMtFYEuM nvPEAcLuIz1rwA7roDMJNnHNiqa0FZQmKTKQhPEAJrja5PPnGn/kDbBqhlM1U/PwiK2d SMqxhs1UYhgiz+bQoxoTXJhGaylhuVzVqXDm4wAXjzDSLAmuHeo2SXNKRK1g4HDPZyYe c9rQ== X-Gm-Message-State: APt69E3t0Mur7nuHP7W/KoOLM9BhqmUUsH65QGvKqjDh1MOqbrj36ZPf UIHw3L7n54L0jh0I0i0VQVBiAC87X+3Ssa5uZMU= X-Google-Smtp-Source: AAOMgpd7ZC3HSUPt8I68+CB77G+xG039fL9Vv3kgcoMlSvDewHs6+RwKjNZXG/JyCJ51s1WCi+cuyKa+scU3nQO+/qU= X-Received: by 2002:a0c:9208:: with SMTP id a8-v6mr27419888qva.47.1530648571467; Tue, 03 Jul 2018 13:09:31 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Darin Pettis Date: Tue, 3 Jul 2018 15:09:20 -0500 Message-ID: To: Bret Jordan Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="00000000000060dc6a05701de42b" Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 20:09:42 -0000 --00000000000060dc6a05701de42b Content-Type: text/plain; charset="UTF-8" +1 On Tue, Jul 3, 2018 at 12:08 PM Bret Jordan wrote: > From a discussion on the PATIENT list found here: > https://www.ietf.org/mail-archive/web/patient/current/msg00078.html > > > From my personal perspective, we need to be careful with all of these > efforts. It feels like the pendulum has swung so far to one side, the side > of privacy-at-any-cost, that we are unknowingly increasing the risk to > individuals and organizations by enabling threat actors and intrusions sets > to attack networks and clients without any level of protection from the > network. > > It also feels like a lot of these initiatives are being done without > adequately involving and ensuring that enterprise networks and critical > infrastructure can work with these changes. Question, do we know how these > ideas and changes are going to impact an organizations ability to fulfill > their requirements for regulatory compliance? > > If we continue down these paths, then I fear networks will be required to > wrap all traffic in some other less secure protocol, outright deny some of > these protocols, or be forced to fully proxy all traffic or take an > approach that Google has done with their BeyondCorp design. > > The IETF work needs to do more outreach with enterprise networks and > critical infrastructure and be fundamentally more inclusive. > Privacy-at-any-cost is not a holistic design. > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > > > ### Copied content from the PATIENT discussion #### > > > On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty at gmail.com> wrote: > >> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla wrote: >> > >> > >> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski > ..uk> >> > wrote: >> >> >> >> Your point is one that deserves further discussion, Eric - which seems >> >> likely to scale rapidly going forward. It is key. >> >> >> >> So how does draft-ietf-tls-sni-encryption it into the argument? >> > >> > >> > As you suggest, SNI encryption is intended to conceal the SNI, which of >> > course would make SNI inspection difficult. >> > >> > My evaluation of the current state of SNI encryption is that given the >> > current technical state, it will not see particularly wide deployment, >> with >> > the primary scenario being "at-risk" sites who are subject to >> censorship who >> > either hide behind or co-tenant with sites which are not subject to >> > censorship. That probably isn't going to be incredibly common right >> now. Of >> > course, this is regrettable from the perspective of people designing >> these >> > protocols, but I think that's the situation. >> >> EKR posted a draft to encrypt SNI, see: >> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html >> >> It targets the CDNs who host most of the web traffic in the US at >> least. The right place to comment on this would be the TLS list of >> course, but since proposals are being posted, this is a reality and >> needs to be discussed. Those using SNI need to make sure their use >> cases are clear and understood and argue the pros and cons. >> > > Kathleen, > > Thanks for pointing out this draft. > > As they say, predictions are hard, especially about the future. In March, > the ESNI problem looked pretty intractable and then subsequently we had > this idea about why it might be workable. > > -Ekr > > Best regards, >> Kathleen >> >> > >> > -Ekr >> > >> >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote: >> >> >> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > yaanatech.co.uk> >> >> wrote: >> >>> >> >>> Hi Diego, >> >>> >> >>> It is also worth referencing a relatively recent Lawfare article on >> the >> >>> scaling litigation in the U.S. against those supporting e2e encryption >> >>> services or capabilities. >> >>> >> >>> >> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis >> >>> >> >>> This litigation trend is also likely to increase the insurance costs >> of >> >>> providers. Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, >> may not >> >>> even be able to get insurance. It may be fun and games to play >> crypto rebel >> >>> in venues like the IETF where the risk exposure is minimal, but when >> it >> >>> comes to real world consequences and costs, the equations for >> providers are >> >>> rather different. >> >> >> >> >> >> I think this rather overestimates the degree to which both TLS 1.3 and >> >> QUIC change the equation about what a provider is able to determine >> from >> >> traffic inspection. As a practical matter, the primary change from TLS >> 1.2 >> >> is that the provider does not get to see the server's certificate, but >> it >> >> does see the SNI. Given that the SNI contains the identity of the >> server >> >> that the client is connected to and that the other identities in the >> >> certificate are often whatever the provider decided to co-locate on >> the same >> >> machine, I'm not sure how much information you are really losing. >> >> >> >> -Ekr >> >> >> >>> >> >>> >> >>> >> >>> --tony >> >>> >> >>> >> >>> _______________________________________________ >> >>> PATIENT mailing list >> >>> PATIENT at ietf.org >> >>> https://www.ietf.org/mailman/listinfo/patient >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> PATIENT mailing list >> >> PATIENT at ietf.org >> >> https://www.ietf.org/mailman/listinfo/patient >> >> >> >> >> > >> > >> > _______________________________________________ >> > PATIENT mailing list >> > PATIENT at ietf.org >> > https://www.ietf.org/mailman/listinfo/patient >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000060dc6a05701de42b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1

=


= On Tue, Jul 3, 2018 at 12:08 PM Bret Jordan <jordan.ietf@gmail.com> wrote:
From a discussion on the PATIENT list found he= re:=C2=A0https://www.ietf.org/mail-archive/web/patie= nt/current/msg00078.html


From m= y personal perspective, we need to be careful with all of these efforts. It= feels like the pendulum has swung so far to=C2=A0one side, the side of pri= vacy-at-any-cost, that we are unknowingly increasing the risk to individual= s and organizations by=C2=A0enabling threat actors and intrusions sets to a= ttack networks and clients without any level of protection from the network= .=C2=A0

It also feels like a lot of these initiatives are being done= without adequately involving and ensuring that enterprise networks and=C2= =A0critical infrastructure can work with these changes. Question, do we kno= w how these ideas and changes are going to impact an=C2=A0organizations abi= lity to fulfill their requirements for regulatory compliance?=C2=A0

= If we continue down these paths, then I fear networks will be required to w= rap all traffic in some other less secure protocol,=C2=A0outright deny some= of these protocols, or be forced to fully proxy all traffic or take an app= roach that Google has done with their=C2=A0BeyondCorp design.=C2=A0=C2=A0
The IETF work needs to do more outreach with enterprise networks and = critical infrastructure and be fundamentally more=C2=A0inclusive. Privacy-a= t-any-cost is not a holistic design.=C2=A0

Thanks,
Bret
PGP Fingerpr= int:=C2=A063B4 FC53 680A 6B7D 1= 447 =C2=A0F2C0 74F8 ACAE 7415 0050
<= span style=3D"color:rgb(124,124,124);font-size:8pt;font-family:Calibre,Verd= ana;text-align:-webkit-auto">"Without cryptography vihv vivc ce xhrnrw= , however, the only thing that can not be unscrambled is an egg."



### Copied content from the PATIENT = discussion ####


On Tue, Jul 3= , 2018 at 8:09 AM, Kathleen Moriarty=C2=A0<kathleen.moriarty.ietf at gmail.com>=C2=A0wrote:
On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr at rtfm= .com> wrote:
>
>
> On Sun, Mar 18, 2018 at 12:54 P= M, Tony Rutkowski <tony at yaanatech.co..uk>
> wrote:
>>
>> = Your point is one that deserves further discussion, Eric - which seems
&= gt;> likely to scale rapidly going forward.=C2=A0 It is key.
>>=
>> So how does draft-ietf-tls-sni-encryption it into the argument= ?
>
>
> As you suggest, SNI encryption is intended to con= ceal the SNI, which of
> course would make SNI inspection difficult.<= br>>
> My evaluation of the current state of SNI encryption is tha= t given the
> current technical state, it will not see particularly w= ide deployment, with
> the primary scenario being "at-risk"= sites who are subject to censorship who
> either hide behind or co-t= enant with sites which are not subject to
> censorship. That probably= isn't going to be incredibly common right now. Of
> course, this= is regrettable from the perspective of people designing these
> prot= ocols, but I think that's the situation.

EKR posted a dra= ft to encrypt SNI, see:
https://www.= ietf.org/mail-archive/web/tls/current/msg26468.html

It targets t= he CDNs who host most of the web traffic in the US at
least.=C2=A0 The r= ight place to comment on this would be the TLS list of
course, but since= proposals are being posted, this is a reality and
needs to be discussed= .=C2=A0 Those using SNI need to make sure their use
cases are clear and = understood and argue the pros and cons.

Kathleen,

Thanks for pointing out this draft.

As they say, predictions are hard, especially about t= he future. In March, the ESNI problem looked pretty intractable and then su= bsequently we had this idea about why it might be workable.
<= br>
-Ekr

Best regards,
Kathleen
=

>
> -Ekr<= br>>
>> On 18-Mar-18 8:45 AM, Eric Rescorla wrote:
>><= br>>> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <ton= y at yaanatech.co.uk>
>> wrote:
>>>
>>= > Hi Diego,
>>>
>>> It is also worth referencing= a relatively recent Lawfare article on the
>>> scaling litigat= ion in the U.S. against those supporting e2e encryption
>>> ser= vices or capabilities.
>>>
>>>=C2=A0https://www.lawfareblog.com= /did-congress-immunize-twitter-against-lawsuits-supporting-isis
>= >>
>>> This litigation trend is also likely to increase t= he insurance costs of
>>> providers.=C2=A0 Indeed, a provider t= hat supports TLS1.3, QUIC, SNI, etc, may not
>>> even be able t= o get insurance.=C2=A0 It may be fun and games to play crypto rebel
>= >> in venues like the IETF where the risk exposure is minimal, but wh= en it
>>> comes to real world consequences and costs, the equat= ions for providers are
>>> rather different.
>>
>= ;>
>> I think this rather overestimates the degree to which bot= h TLS 1.3 and
>> QUIC change the equation about what a provider is= able to determine from
>> traffic inspection. As a practical matt= er, the primary change from TLS 1.2
>> is that the provider does n= ot get to see the server's certificate, but it
>> does see the= SNI. Given that the SNI contains the identity of the server
>> th= at the client is connected to and that the other identities in the
>&= gt; certificate are often whatever the provider decided to co-locate on the= same
>> machine, I'm not sure how much information you are re= ally losing.
>>
>> -Ekr
>>
>>>
&g= t;>>
>>>
>>> --tony
>>>
>&g= t;>
>>> _______________________________________________
&= gt;>> PATIENT mailing list
>>>=C2=A0PATIENT at ietf.or= g
>>>=C2=A0https://www.ietf.org/mailman/l= istinfo/patient
>>
>>
>>
>>
>= > _______________________________________________
>> PATIENT ma= iling list
>>=C2=A0PATIENT at ietf.org
>>=C2=A0https://www.ietf.org/mailman/listinfo/patient
>>= ;
>>
>
>
> _____________________________________= __________
> PATIENT mailing list
>=C2=A0PATIENT at ietf.org=
>=C2=A0https://www.ietf.org/mailman/listinfo/p= atient
>



--=C2=A0
<= br>Best regards,
Kathleen

________________________________= _______________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--00000000000060dc6a05701de42b-- From nobody Tue Jul 3 13:09:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2CE7130E71 for ; Tue, 3 Jul 2018 13:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xGpz_f6XYqpT for ; Tue, 3 Jul 2018 13:09:37 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C6DE130FCA for ; Tue, 3 Jul 2018 13:09:37 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id b15-v6so6300941oib.10 for ; Tue, 03 Jul 2018 13:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=lb73/9mpxgQLmTJWadEW1dKJG0cvzLBVEUSPAH6w41U=; b=YV1rzkz/cymVzPFoftFtxeHAWTl9g+g60/+NBDg0qTeSi5Op7qudGp93Z9wo0ZyXxN I5fXrAmtDOSUzJb8oNQqwgtipsUFj+g4QOACeMtDenLTl58WMrSbO1NsmuJ6i+WGJd7d RJ5Kt8w9C5YEkqpLJEGsRwgSb2kl8D4GfP+LBaf71JcS5ZoBPbzfzEoa/EoTqnEE1AAN HNeby4uRsDw9b+5sn3qv2uBvzYGyVjR9sG9kh+HVJy4hRDLbXzZ5vwqz4JaepS12jv/9 ojE0/hj6/sDE3RdZzD1BVfHfLg5bSEnoAhW07DKzxZ4FJZY2yjLETC2WoSLFR7b3xHqz UCSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=lb73/9mpxgQLmTJWadEW1dKJG0cvzLBVEUSPAH6w41U=; b=LEPeyqZsKDL/XqGacJyXEOaMjpc06MXyMfGovQb+0FnUtcutKGwIjdqMiSSRm/O7IG QLlZMac5rUnVu4BgL4IliRUPuqjDq9Qx+iBcE/b2kZ35VYoZEfojIBYEgBKRQ6hYT6Wq dThCKsWM6DENWveRoHAWG8trMMF1GTV5+Xs4C03RDs7Y9wbRnhB3qwtuaKek0SJGxUS6 4OAFnD+GPkYc1rCLuMc1TwdI5TYmP/nuyS9XxpsDsmu3pKhkUsq1Y/AxgoUDgsSWvi8C ehEq3tnRtSvBs7CndZAnTyKfU7l82mAi0NJSCwXSdjr+8W65WVvJM0Xey+06pneiTycy COpA== X-Gm-Message-State: APt69E0Wg5b71ZcEqw6t85C+dAmmK5pWkuev3nzU8Rly983nqcbxSmdC oVC+ZQCVfv/o20MPuP5UYDxO1xWOYtfYPwF9gH0= X-Google-Smtp-Source: AAOMgpcCl7mZhfnZoSQRwCmrCCSM4PYCjt8hmRERUz+kMXcrz3OJOc+0NlEeBQt2Cuv2ilmOI5Sg27NujuXOSr3JizU= X-Received: by 2002:aca:3254:: with SMTP id y81-v6mr9868751oiy.317.1530648576510; Tue, 03 Jul 2018 13:09:36 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7ad0:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 13:08:56 -0700 (PDT) In-Reply-To: <20180703194903.GA14551@akamai.com> References: <20180703194903.GA14551@akamai.com> From: Kathleen Moriarty Date: Tue, 3 Jul 2018 16:08:56 -0400 Message-ID: To: Benjamin Kaduk Cc: Bret Jordan , "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 20:09:43 -0000 On Tue, Jul 3, 2018 at 3:49 PM, Benjamin Kaduk wrote: > On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan wrote: >> From a discussion on the PATIENT list found here: https://www.ietf.org/m= ail-archive/web/patient/current/msg00078.html >> >> >> From my personal perspective, we need to be careful with all of these ef= forts. It feels like the pendulum has swung so far to one side, the side of= privacy-at-any-cost, that we are unknowingly increasing the risk to indivi= duals and organizations by enabling threat actors and intrusions sets to at= tack networks and clients without any level of protection from the network. > > BCP 61 leads us to not expect any protection from the network, does it no= t? > >> It also feels like a lot of these initiatives are being done without ade= quately involving and ensuring that enterprise networks and critical infras= tructure can work with these changes. Question, do we know how these ideas = and changes are going to impact an organizations ability to fulfill their r= equirements for regulatory compliance? >> >> If we continue down these paths, then I fear networks will be required t= o wrap all traffic in some other less secure protocol, outright deny some o= f these protocols, or be forced to fully proxy all traffic or take an appro= ach that Google has done with their BeyondCorp design. > > I suspect you will find that many proponents of the proposals you find > worrisome would also be enthusiastic proponents of "an approach similar t= o what > Google has done with BeyondCorp". Such a discussion would be off-topic f= or > the TLS list, but you would probably be well-served to have some supporti= ng text > for why this sort of approach should be considered bad, if you want to ga= in > sympathy for your perspective. The proposal came from an AD who just a few moths ago told them not to worry about these possible changes (see referenced thread on PATIENT list) that impact their work, so in other words, don't prepare for it, don't worry about alternate solutions or figuring out ways to better articulate your use cases. Then that AD submits the proposal. Challenging comments are posted and I would expect that there be sensitivities as to the origin of the draft and making it even more fair for list participants to comment and understand that this draft should be treated as any other. While I agree that additional text and supporting use case information is needed, there also needs to be an openness to listen to all views on a proposal. If there are use cases that are critical for SNI, they need to surface and be considered. Best regards, Kathleen > > -Ben > >> The IETF work needs to do more outreach with enterprise networks and cri= tical infrastructure and be fundamentally more inclusive. Privacy-at-any-co= st is not a holistic design. >> >> Thanks, >> Bret >> PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 >> "Without cryptography vihv vivc ce xhrnrw, however, the only thing that = can not be unscrambled is an egg." >> >> >> >> ### Copied content from the PATIENT discussion #### >> >> >> On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty > wrote: >> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla > wrote: >> > >> > >> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski >> > wrote: >> >> >> >> Your point is one that deserves further discussion, Eric - which seem= s >> >> likely to scale rapidly going forward. It is key. >> >> >> >> So how does draft-ietf-tls-sni-encryption it into the argument? >> > >> > >> > As you suggest, SNI encryption is intended to conceal the SNI, which o= f >> > course would make SNI inspection difficult. >> > >> > My evaluation of the current state of SNI encryption is that given the >> > current technical state, it will not see particularly wide deployment,= with >> > the primary scenario being "at-risk" sites who are subject to censorsh= ip who >> > either hide behind or co-tenant with sites which are not subject to >> > censorship. That probably isn't going to be incredibly common right no= w. Of >> > course, this is regrettable from the perspective of people designing t= hese >> > protocols, but I think that's the situation. >> >> EKR posted a draft to encrypt SNI, see: >> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html >> >> It targets the CDNs who host most of the web traffic in the US at >> least. The right place to comment on this would be the TLS list of >> course, but since proposals are being posted, this is a reality and >> needs to be discussed. Those using SNI need to make sure their use >> cases are clear and understood and argue the pros and cons. >> >> Kathleen, >> >> Thanks for pointing out this draft. >> >> As they say, predictions are hard, especially about the future. In March= , the ESNI problem looked pretty intractable and then subsequently we had t= his idea about why it might be workable. >> >> -Ekr >> >> Best regards, >> Kathleen >> >> > >> > -Ekr >> > >> >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote: >> >> >> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > >> >> wrote: >> >>> >> >>> Hi Diego, >> >>> >> >>> It is also worth referencing a relatively recent Lawfare article on = the >> >>> scaling litigation in the U.S. against those supporting e2e encrypti= on >> >>> services or capabilities. >> >>> >> >>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-la= wsuits-supporting-isis >> >>> >> >>> This litigation trend is also likely to increase the insurance costs= of >> >>> providers. Indeed, a provider that supports TLS1.3, QUIC, SNI, etc,= may not >> >>> even be able to get insurance. It may be fun and games to play cryp= to rebel >> >>> in venues like the IETF where the risk exposure is minimal, but when= it >> >>> comes to real world consequences and costs, the equations for provid= ers are >> >>> rather different. >> >> >> >> >> >> I think this rather overestimates the degree to which both TLS 1.3 an= d >> >> QUIC change the equation about what a provider is able to determine f= rom >> >> traffic inspection. As a practical matter, the primary change from TL= S 1.2 >> >> is that the provider does not get to see the server's certificate, bu= t it >> >> does see the SNI. Given that the SNI contains the identity of the ser= ver >> >> that the client is connected to and that the other identities in the >> >> certificate are often whatever the provider decided to co-locate on t= he same >> >> machine, I'm not sure how much information you are really losing. >> >> >> >> -Ekr >> >> >> >>> >> >>> >> >>> >> >>> --tony >> >>> >> >>> >> >>> _______________________________________________ >> >>> PATIENT mailing list >> >>> PATIENT at ietf.org >> >>> https://www.ietf.org/mailman/listinfo/patient >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> PATIENT mailing list >> >> PATIENT at ietf.org >> >> https://www.ietf.org/mailman/listinfo/patient >> >> >> >> >> > >> > >> > _______________________________________________ >> > PATIENT mailing list >> > PATIENT at ietf.org >> > https://www.ietf.org/mailman/listinfo/patient >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> > >> _______________________________________________ >> 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 --=20 Best regards, Kathleen From nobody Tue Jul 3 13:24:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5105D130DD5 for ; Tue, 3 Jul 2018 13:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fgmq_XlGl0e3 for ; Tue, 3 Jul 2018 13:24:17 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72128124BE5 for ; Tue, 3 Jul 2018 13:24:17 -0700 (PDT) Received: from computer.lan ([2001:2012:127:3e00:ff5e:3a82:43d7:a6d6]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 03 Jul 2018 22:24:24 +0200 id 00000000000000B6.000000005B3BDB78.0000603D Date: Tue, 3 Jul 2018 22:24:14 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20180703222414.17ee820c@computer.lan> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 20:24:22 -0000 So-called "Enterprise" infrastructure has delayed the work of this group for at least a year. Noone of the people creating that mess has reached out to this group to explain why they constantly break TLS - let alone apologize for it. I believe there's a large overlap of the actors breaking TLS with the actors who are worried about things like SNI encryption. I'm not sure I see any reason not to consider these actors as anything but opposed to the work of this group. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Tue Jul 3 14:12:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CEBF130E22 for ; Tue, 3 Jul 2018 14:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wRe7xu3w9ofF for ; Tue, 3 Jul 2018 14:12:02 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFD62130E0F for ; Tue, 3 Jul 2018 14:12:01 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id s8-v6so1274394ybe.8 for ; Tue, 03 Jul 2018 14:12:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+XVjdyTMcFYiL4v9AFlvyPbqhyc2eYU28hOe0g7yD/Q=; b=QVMwpr9LsnSsGNfaT1jyce/VtH+A8Bo2uuG44np3LhAab7pU7WeerYmw6V7q+7/h+d J38F6u9pSKYjdWurCnSpZAWViRctENIUqxazJYVt1/ZMYymLjNlo9FD06RsftrFfv3Gv gEr7ru+0Uknx3Frp4+vb2UgDHHrrk2j9wJ3sKm1GZRFNUyE4TiFd8QrzhODe45CLSm/K d4VeW41pS34OZxMfqUwj2Ca3aaXILaxs//eGcNyoYlMO8OUgUabl+un5+XEEBeQR5v9a 4DPTi1Xq4xHXotlIOF8/eEd0/fZYmj51ThuU5GMtVUpUw+Zn0dKXSRo/hXdnAF0vgeuY o0XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+XVjdyTMcFYiL4v9AFlvyPbqhyc2eYU28hOe0g7yD/Q=; b=LsN4W2gU9MPLEsNCdmc9LDwsXWvzjEDpgEv2B8NN4fpSf4ed1ojLRAySo0F/NR3i3e cVXtyw0cw4rALODDmLaGBmoAUHc0tFM8QzDmdEApimfztHaPPCy0EBKKx1Ol9hpeQNCn mDY2SRbUHCmzIfB0wO1s6yi101j1kXZDsAxDEprUjMIwxPpVcGU/tadAb1JwUExR0Kcd 54DQxD6TSdFOdhzf1rABrVxBq/4KkZ2xk9/ZJF5FGRoObXXjFPd3QcPPzKjEKVb1nl3u d9xCIH6jXKwIQyGzqkQ/9ApEsruIM5OusDr7qW7exGPDga1KsYmIOspUDBX4n+l8G42m oDfw== X-Gm-Message-State: APt69E1JhmJHakG55PVwvnYNdVR4jdF963HDs0+97lYW6R+tXmXIan1z o7kKFr6ZLN+/EhEymL8GWABvH2XZAHtVVSxSOv37DQ== X-Google-Smtp-Source: AAOMgpe2vAbl0F/pTdf8+uWlw3rVg+3szXBdRqXA7BGqoHJKSUnSSmr1HRX0ZGTkpSh45RNfCHoLOIxAR9jjNzwgODg= X-Received: by 2002:a25:acd0:: with SMTP id x16-v6mr15923314ybd.407.1530652320923; Tue, 03 Jul 2018 14:12:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 14:11:20 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Tue, 3 Jul 2018 14:11:20 -0700 Message-ID: To: Bret Jordan Cc: "" Content-Type: multipart/alternative; boundary="000000000000dd1d3105701ec307" Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 21:12:05 -0000 --000000000000dd1d3105701ec307 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 10:08 AM, Bret Jordan wrote: > From a discussion on the PATIENT list found here: https://www.ietf.org/mai > l-archive/web/patient/current/msg00078.html > > > From my personal perspective, we need to be careful with all of these > efforts. It feels like the pendulum has swung so far to one side, the side > of privacy-at-any-cost, that we are unknowingly increasing the risk to > individuals and organizations by enabling threat actors and intrusions sets > to attack networks and clients without any level of protection from the > network. > > It also feels like a lot of these initiatives are being done without > adequately involving and ensuring that enterprise networks and critical > infrastructure can work with these changes. Question, do we know how these > ideas and changes are going to impact an organizations ability to fulfill > their requirements for regulatory compliance? > Well "these changes" covers a lot of ground, but in this particular case, can't enterprise just strip ESNI records from DNS? -Ekr > The IETF work needs to do more outreach with enterprise networks and > critical infrastructure and be fundamentally more inclusive. > Privacy-at-any-cost is not a holistic design. > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that > can not be unscrambled is an egg." > > > > ### Copied content from the PATIENT discussion #### > > > On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty at gmail.com> wrote: > >> On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla wrote: >> > >> > >> > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski > ..uk> >> > wrote: >> >> >> >> Your point is one that deserves further discussion, Eric - which seems >> >> likely to scale rapidly going forward. It is key. >> >> >> >> So how does draft-ietf-tls-sni-encryption it into the argument? >> > >> > >> > As you suggest, SNI encryption is intended to conceal the SNI, which of >> > course would make SNI inspection difficult. >> > >> > My evaluation of the current state of SNI encryption is that given the >> > current technical state, it will not see particularly wide deployment, >> with >> > the primary scenario being "at-risk" sites who are subject to >> censorship who >> > either hide behind or co-tenant with sites which are not subject to >> > censorship. That probably isn't going to be incredibly common right >> now. Of >> > course, this is regrettable from the perspective of people designing >> these >> > protocols, but I think that's the situation. >> >> EKR posted a draft to encrypt SNI, see: >> https://www.ietf.org/mail-archive/web/tls/current/msg26468.html >> >> It targets the CDNs who host most of the web traffic in the US at >> least. The right place to comment on this would be the TLS list of >> course, but since proposals are being posted, this is a reality and >> needs to be discussed. Those using SNI need to make sure their use >> cases are clear and understood and argue the pros and cons. >> > > Kathleen, > > Thanks for pointing out this draft. > > As they say, predictions are hard, especially about the future. In March, > the ESNI problem looked pretty intractable and then subsequently we had > this idea about why it might be workable. > > -Ekr > > Best regards, >> Kathleen >> >> > >> > -Ekr >> > >> >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote: >> >> >> >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski > yaanatech.co.uk> >> >> wrote: >> >>> >> >>> Hi Diego, >> >>> >> >>> It is also worth referencing a relatively recent Lawfare article on >> the >> >>> scaling litigation in the U.S. against those supporting e2e encryption >> >>> services or capabilities. >> >>> >> >>> https://www.lawfareblog.com/did-congress-immunize-twitte >> r-against-lawsuits-supporting-isis >> >>> >> >>> This litigation trend is also likely to increase the insurance costs >> of >> >>> providers. Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, >> may not >> >>> even be able to get insurance. It may be fun and games to play >> crypto rebel >> >>> in venues like the IETF where the risk exposure is minimal, but when >> it >> >>> comes to real world consequences and costs, the equations for >> providers are >> >>> rather different. >> >> >> >> >> >> I think this rather overestimates the degree to which both TLS 1.3 and >> >> QUIC change the equation about what a provider is able to determine >> from >> >> traffic inspection. As a practical matter, the primary change from TLS >> 1.2 >> >> is that the provider does not get to see the server's certificate, but >> it >> >> does see the SNI. Given that the SNI contains the identity of the >> server >> >> that the client is connected to and that the other identities in the >> >> certificate are often whatever the provider decided to co-locate on >> the same >> >> machine, I'm not sure how much information you are really losing. >> >> >> >> -Ekr >> >> >> >>> >> >>> >> >>> >> >>> --tony >> >>> >> >>> >> >>> _______________________________________________ >> >>> PATIENT mailing list >> >>> PATIENT at ietf.org >> >>> https://www.ietf.org/mailman/listinfo/patient >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> >> PATIENT mailing list >> >> PATIENT at ietf.org >> >> https://www.ietf.org/mailman/listinfo/patient >> >> >> >> >> > >> > >> > _______________________________________________ >> > PATIENT mailing list >> > PATIENT at ietf.org >> > https://www.ietf.org/mailman/listinfo/patient >> > >> >> >> >> -- >> >> Best regards, >> Kathleen >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --000000000000dd1d3105701ec307 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018 at 10:08 AM, Bret Jordan <jordan.ietf@gmail.co= m> wrote:
From a discussion on t= he PATIENT list found here:=C2=A0https://www.ietf.or= g/mail-archive/web/patient/current/msg00078.html

From my personal perspective, we need to be car= eful with all of these efforts. It feels like the pendulum has swung so far= to=C2=A0one side, the side of privacy-at-any-cost, that we are unknowingly= increasing the risk to individuals and organizations by=C2=A0enabling thre= at actors and intrusions sets to attack networks and clients without any le= vel of protection from the network.=C2=A0

It also feels like a lot o= f these initiatives are being done without adequately involving and ensurin= g that enterprise networks and=C2=A0critical infrastructure can work with t= hese changes. Question, do we know how these ideas and changes are going to= impact an=C2=A0organizations ability to fulfill their requirements for reg= ulatory compliance?=C2=A0

W= ell "these changes" covers a lot of ground, but in this particula= r case, can't enterprise just strip ESNI records from DNS?
-Ekr

=C2=A0
T= he IETF work needs to do more outreach with enterprise networks and critica= l infrastructure and be fundamentally more=C2=A0inclusive.



<= div> Privacy-at-any-cost is not a holistic design.=C2=A0

Thanks,
Bret
PGP Fingerpr= int:=C2=A063B4 FC53 680A 6B7D 1= 447 =C2=A0F2C0 74F8 ACAE 7415 0050
<= span style=3D"color:rgb(124,124,124);font-size:8pt;font-family:Calibre,Verd= ana;text-align:-webkit-auto">"Without cryptography vihv vivc ce xhrnrw= , however, the only thing that can not be unscrambled is an egg."



### Copied content from the PATIENT = discussion ####


On Tue, Jul 3= , 2018 at 8:09 AM, Kathleen Moriarty=C2=A0<kathleen.moriarty.ietf at gmail.com>=C2=A0wrote:
On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescor= la <ekr at rtfm.com> wrote:
>
>
> On Sun, Mar 18= , 2018 at 12:54 PM, Tony Rutkowski <tony at yaanatech.co..uk>
> wrote:
>= >
>> Your point is one that deserves further discussion, Eric -= which seems
>> likely to scale rapidly going forward.=C2=A0 It is= key.
>>
>> So how does draft-ietf-tls-sni-encryption it = into the argument?
>
>
> As you suggest, SNI encryption i= s intended to conceal the SNI, which of
> course would make SNI inspe= ction difficult.
>
> My evaluation of the current state of SNI = encryption is that given the
> current technical state, it will not s= ee particularly wide deployment, with
> the primary scenario being &q= uot;at-risk" sites who are subject to censorship who
> either hi= de behind or co-tenant with sites which are not subject to
> censorsh= ip. That probably isn't going to be incredibly common right now. Of
= > course, this is regrettable from the perspective of people designing t= hese
> protocols, but I think that's the situation.

EKR posted a draft to encrypt SNI, see:
https://www.ietf.org/mail-archive/web/tls/current/msg26468.h= tml

It targets the CDNs who host most of the web traffic in the = US at
least.=C2=A0 The right place to comment on this would be the TLS l= ist of
course, but since proposals are being posted, this is a reality a= nd
needs to be discussed.=C2=A0 Those using SNI need to make sure their = use
cases are clear and understood and argue the pros and cons.

Kathleen,

Thanks for p= ointing out this draft.

As they say, predictions a= re hard, especially about the future. In March, the ESNI problem looked pre= tty intractable and then subsequently we had this idea about why it might b= e workable.

-Ekr

Be= st regards,
Kathleen

>
> -Ekr
>
>> On 18-Mar-18 8:45 AM, Eric R= escorla wrote:
>>
>> On Sun, Mar 18, 2018 at 12:30 PM, To= ny Rutkowski <tony at yaanatech.co.uk>
>> wrote:<= br>>>>
>>> Hi Diego,
>>>
>>> I= t is also worth referencing a relatively recent Lawfare article on the
&= gt;>> scaling litigation in the U.S. against those supporting e2e enc= ryption
>>> services or capabilities.
>>>
>&g= t;>=C2=A0= https://www.lawfareblog.com/did-congress-immunize-twitter-against= -lawsuits-supporting-isis
>>>
>>> This lit= igation trend is also likely to increase the insurance costs of
>>= > providers.=C2=A0 Indeed, a provider that supports TLS1.3, QUIC, SNI, e= tc, may not
>>> even be able to get insurance.=C2=A0 It may be = fun and games to play crypto rebel
>>> in venues like the IETF = where the risk exposure is minimal, but when it
>>> comes to re= al world consequences and costs, the equations for providers are
>>= ;> rather different.
>>
>>
>> I think this ra= ther overestimates the degree to which both TLS 1.3 and
>> QUIC ch= ange the equation about what a provider is able to determine from
>&g= t; traffic inspection. As a practical matter, the primary change from TLS 1= .2
>> is that the provider does not get to see the server's ce= rtificate, but it
>> does see the SNI. Given that the SNI contains= the identity of the server
>> that the client is connected to and= that the other identities in the
>> certificate are often whateve= r the provider decided to co-locate on the same
>> machine, I'= m not sure how much information you are really losing.
>>
>&= gt; -Ekr
>>
>>>
>>>
>>>
>= ;>> --tony
>>>
>>>
>>> __________= _____________________________________
>>> PATIENT mailing = list
>>>=C2=A0PATIENT at ietf.org
>>>=C2=A0<= a rel=3D"nofollow" href=3D"https://www.ietf.org/mailman/listinfo/patient" t= arget=3D"_blank">https://www.ietf.org/mailman/listinfo/patient
= >>
>>
>>
>>
>> __________________= _____________________________
>> PATIENT mailing list
>= >=C2=A0PATIENT at ietf.org
>>=C2=A0htt= ps://www.ietf.org/mailman/listinfo/patient
>>
>>=
>
>
> _____________________________________________= __
> PATIENT mailing list
>=C2=A0PATIENT at ietf.org
= >=C2=A0https://www.ietf.org/mailman/listinfo/pati= ent
>



--=C2=A0
Best regards,
Kathleen
=

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


--000000000000dd1d3105701ec307-- From nobody Tue Jul 3 14:19:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E29D6130E54 for ; Tue, 3 Jul 2018 14:19:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id adEp9bXZq8q1 for ; Tue, 3 Jul 2018 14:19:27 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB6F130E0F for ; Tue, 3 Jul 2018 14:19:27 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w63LCOcv003567; Tue, 3 Jul 2018 22:19:23 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding; s=jan2016.eng; bh=WI4nqmUfuB0ne7JS9BLwA6+CN0kKHpJp5Y9lDB0SiII=; b=hz/jZAUsu0gZtge85GyWSV7dKIOkVy8LBbsaWUOGTRa2M+TnHIs1mHrDkb8pPOxiG54X l/RAkPK3N0zMgSbNMMvn7C4oPrqcg3jfcNa6EYlT8UtNkyqf3eUO4OGEmIu7tesext13 4xQagqpTYgJrqRvP/7zZv2iAaeyxbz+SGvg+ZKH+grSkpi5rR4vfJ0npwcYwNE7DnRdE bIMn0YVIvc4iC1OFlJ9nRCdN47lAXWFpqFuqMSVvMrDb67wU2SnkDNZWFgSPtBv+MN5H n1pafhnsjF0iAnq8tsIZ1Bg7aS32Q/cQIUTfBEygWG0zSVMRYOOPY82tnM+UjsOr2dCw EA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050093.ppops.net-00190b01. with ESMTP id 2jx14k24n1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 03 Jul 2018 22:19:22 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w63L530q031639; Tue, 3 Jul 2018 17:19:21 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jx57bb8ge-1; Tue, 03 Jul 2018 17:19:21 -0400 Received: from Tereva.local (unknown [172.19.40.96]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 654DD20067; Tue, 3 Jul 2018 21:19:21 +0000 (GMT) From: Brian Sniffen To: Hanno =?utf-8?Q?B=C3=B6ck?= , tls@ietf.org In-Reply-To: <20180703222414.17ee820c@computer.lan> References: <20180703222414.17ee820c@computer.lan> Date: Tue, 03 Jul 2018 17:19:20 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-03_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030237 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-03_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807030239 Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 03 Jul 2018 21:19:31 -0000 Hanno B=C3=B6ck writes: > So-called "Enterprise" infrastructure has delayed the work of this group > for at least a year. Noone of the people creating that mess has reached > out to this group to explain why they constantly break TLS - let alone > apologize for it. > > I believe there's a large overlap of the actors breaking TLS with the > actors who are worried about things like SNI encryption. I'm not sure I > see any reason not to consider these actors as anything but opposed to > the work of this group. Whoah! I've been involved for years specifically to ask for care about encrypted SNI. I don't know whether I break TLS; maybe opinions vary. But my concerns have been specific: First, at the engineering level, a requirement that servers do expensive cryptographic work in response to a first packet *and* an inability to charge that work to a user or application is a big problem. It makes it too hard for users or applications to share a server, or leads to levels of address waste expensive even with IPv6. If we're going to have 0RTT and 1RTT and TCP Fast Open and ECDHE... then Encrypted SNI is a hard engineering problem!=20 Second, at the architectural level, a serious question about whether this actually helps anybody, and if so whom? I think the case of the Amnesty International worker in an oppressive dictatorship is almost certainly *not* helped by this work---see my questions about how many bits of security this provides against an adaptive adversary from this morning---and would like some clarity that this is about inhibiting the ISPs, from cafes through enterprises up to Comcast-TWC, from monkeying with user sessions.=20=20 My concerns at the engineering level have been welcomed, recognized, validated, and addressed. Not always exactly the way I'd like, but absolutely addressed in a way that's appropriate and sincere. I saw the same with requests to re-insert RSA Kx late last year. The PATIENT folks have gotten a fair hearing. My architectural concerns have been heard, somewhat less eagerly. Some participants, including our colleagues who are vendors to enterprises and folks like Ben Schwartz, have been clear that they will not bring all their motivations and evidence to the table. I significantly discount their arguments and expect others to do the same---but not to zero. It means we need to check their work as we go, or actually trust them as people, but it *can't* be harder than keeping NSA/IA people on CFRG! Anyway, I think the PATIENT folks concerns about the engineering of TLS 1.3 have been heard, have been taken seriously, and have been addressed---same as mine or yours. What I've seen of the architectural concerns leading to network-centric management and "tap" devices come down to claims about changes in architecture being too expensive, middleboxes being too expensive, changes to applications being too expensive, and general citation of an architecture only a few years old as immutable tradition. Those claims have also been heard, plenty of folks have respectfully and diligently combed through them for evidence, and we've moved on. I bet that's frustrating and frightening for the folks writing from a world where those claims aren't faith-based---they're obvious. They don't need citation any more than "China is a country"[1] needs citation. Nonetheless, engineering conversations based on data-supported arguments continue to be welcome. -Brian Footnotes:=20 [1] https://www.cia.gov/library/publications/the-world-factbook/geos/ch.ht= ml but see also https://www.cia.gov/library/publications/the-world-factbo= ok/geos/tw.html --=20 Brian Sniffen From nobody Tue Jul 3 17:47:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A420130E86 for ; Tue, 3 Jul 2018 17:47:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2CoRow64N4VG for ; Tue, 3 Jul 2018 17:47:12 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61CD5130E77 for ; Tue, 3 Jul 2018 17:47:12 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id t18-v6so1349450ywg.2 for ; Tue, 03 Jul 2018 17:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=346/4ifdu+Sg3YrJkbi4CD2SLFkZwpaWeMfZajjp/PA=; b=kgYjfKMdjVyzV9I8INtjISNB31j7qlfrBg5vTiblju3BkPHufWQY/AX3+tlMS3yupq aIzc4ocNc5BMzLjmHVqDmNwSOaabFs3Qv4V4cpdQSFC0GX8SSnpNjqRW2wHpCKXIf7iR f2/yphZ9eYHE4QywPoPGSvNYQ0FVp+voRm7ebtyaKfqfK7+b9glkCQxt5gRe5twfHikG RBU79YCgi9pD2Pt5U89izBmDDzljjFjlEZeKEHOELp0NNghMsgaC3j3jntConz2IOtWq J/GxyuEKv1wBHzFma/EkN+IwbxeW8oAMUM0EeDrPYwepL+p7t4MDwz91/smuQP8PD5Xp XMAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=346/4ifdu+Sg3YrJkbi4CD2SLFkZwpaWeMfZajjp/PA=; b=L71nvgz6ocw2cBy2laGuO6NiNXjUsuhEPefl6CHmWm6sAn6oFzAoFYsxGkHZX2sXLE xfHS3vH/8R26zaER4y2IGtSZYYDHxJe811EMu7y9pAWsrGcpEnq4QlJTO3e06j9DR1kK maFpFpeucGvMXgAiA4S4RKiIAjwHgqWKK0mb6/TwQYogM5yQbgOCexpRFCsYUzqjv4XZ 2G4JJtwA04dPurzgkmDU4MHKGs07b1HzGtWAPtuvsQcPDlNDahj3qEXhy/cPoMVQVho/ NQXZJcngvEx3sRb3rr80c9nyi44pugOoMgaAjgrnI7WNans7JlydcgnbTd78XOzsOl0q oSBg== X-Gm-Message-State: APt69E1ICTRgZQGw7R/pkefjoQw1hJXvx1cfaQJu7nKAI/BZqBOTP5Ik cFQW7PzIodAWqaKVaWLDKOFzWm8EVtY6bgty5i0FQw== X-Google-Smtp-Source: AAOMgpckCXr7UK1wodfw99lai/hJ137J+l1E+xVhtNThP1us0cdFZiPmDMJe22V5g1Ie0glXdjc9ENdBPTEpqQsch9I= X-Received: by 2002:a81:b642:: with SMTP id h2-v6mr10426063ywk.102.1530665231546; Tue, 03 Jul 2018 17:47:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 17:46:30 -0700 (PDT) In-Reply-To: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> From: Eric Rescorla Date: Tue, 3 Jul 2018 17:46:30 -0700 Message-ID: To: "Sniffen, Brian" Cc: "" Content-Type: multipart/alternative; boundary="0000000000006591ed057021c5c7" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 00:47:15 -0000 --0000000000006591ed057021c5c7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian wrote: > Looks neat. > > 1) TFO DOS vector: is the idea servers will disable TFO under strain but > not be able to disable ESNI? > I hadn't thought about it, but that seems right. I'm not really seeing why this is a DOS vector? At present, if you're able to pass a routability test, you can force a server to do a DH exchange and a signature, so forcing them to do ESNI decryption doesn't seem like it's that much of an amplification. > 2) =E2=80=9Cclients might opt to attempt captive portal detection to see = if they > are in the presence of a MITM proxy, and if so disable ESNI.=E2=80=9D > > If I=E2=80=99m operating a great firewall, I can use this to discover dis= sidents, > right? Either they send me dangerous SNI values or they are configured t= o > not disable ESNI, and taking the fifth is fatal. To protect them, I think > nobody can have this mode. > This doesn't sound right to me. The idea here is that you only disable ESNI if the attacker is able to generate a valid TLS connection to a *non-default* root, which means that they are MITM-capable, which nation state firewall operators typically are not. And of course if they are, then you have real problems. Can you walk me through the flow you have in mind. > 3) How many bits does this offer? Hiding in a set of a million uniform > hosts is 20 bits, Well, I would say it's got an anonymity set of 2^{20}. It's not 20 bits strong in the sense that the attacker can do a computation of cost 2^{20}.n and the nonuniformity will accrue to the adversary=E2=80=99s benefit. Activ= e > probing will unmask visitors to dissident sites. > I don't really follow this. Can you explain? -Ekr I worry that this tool is so weak against a GFW-style adversary for the > purpose of allowing dissident access to restricted web sites that it will > be dangerous if released. But maybe I misunderstand the purpose. If this = is > just to keep Western ISPs from monkeying with traffic, sure, ship it. > Labelling the encryption with its strength as applied, or showing CDNs an= d > ISPs how to work out some bounds, seems one way to help users understand > whether this can help them or put them more at risk. > > -- > Brian Sniffen > > --0000000000006591ed057021c5c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian <bsniffen@akamai.com<= /a>> wrote:
Looks neat.

1) TFO DOS vector: is the idea servers will disable TFO under strain but no= t be able to disable ESNI?

I hadn't= thought about it, but that seems right. I'm not really seeing why this= is a DOS vector? At present, if you're able to pass a routability test= , you can force a server to do a DH exchange and a signature, so forcing th= em to do ESNI decryption doesn't seem like it's that much of an amp= lification.


=C2=A0
2) =E2=80=9Cclients might opt to attempt captive portal detection to see if= they are in the presence of a MITM proxy, and if so disable ESNI.=E2=80=9D=

If I=E2=80=99m operating a great firewall, I can use this to discover dissi= dents, right?=C2=A0 Either they send me dangerous SNI values or they are co= nfigured to not disable ESNI, and taking the fifth is fatal. To protect the= m, I think nobody can have this mode.

= This doesn't sound right to me. The idea here is that you only disable = ESNI if the attacker is able to generate a valid TLS connection to a *non-d= efault* root, which means that they are MITM-capable, which nation state fi= rewall operators typically are not. And of course if they are, then you hav= e real problems. Can you walk me through the flow you have in mind.

=C2=A0
3) How many bits does this offer? Hiding in a set of a million uniform host= s is 20 bits,

Well, I would say it's go= t an anonymity set of 2^{20}. It's not 20 bits strong in the sense that= the attacker can do a computation of cost 2^{20}.n


and the nonuniformity will= accrue to the adversary=E2=80=99s benefit. Active probing will unmask visi= tors to dissident sites.

I don't re= ally follow this. Can you explain?

-Ekr
=


I worry that this tool is so weak against a GFW-style adversary for the pur= pose of allowing dissident access to restricted web sites that it will be d= angerous if released. But maybe I misunderstand the purpose. If this is jus= t to keep Western ISPs from monkeying with traffic, sure, ship it.=C2=A0 La= belling the encryption with its strength as applied, or showing CDNs and IS= Ps how to work out some bounds, seems one way to help users understand whet= her this can help them or put them more at risk.

--
Brian Sniffen


--0000000000006591ed057021c5c7-- From nobody Tue Jul 3 18:37:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94DE0130E93 for ; Tue, 3 Jul 2018 18:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQG9qQahVeK2 for ; Tue, 3 Jul 2018 18:37:02 -0700 (PDT) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD4B130E8E for ; Tue, 3 Jul 2018 18:37:01 -0700 (PDT) Received: by mail-lf0-x233.google.com with SMTP id i15-v6so3067329lfc.2 for ; Tue, 03 Jul 2018 18:37:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D6mhL/jPwfE8XdekJhB+QWCzFlF4CfFT/dWUjLSmMGE=; b=bkviPWeEwxSK9dxebTAvw+6WWjJjveTdLReORbF1R2LsqtIwo9HYYIcm9ysC66KfDt YTZhNohyq5yAJnacZpDd3P2bgR4BKHD933US39Xt9aj8zC4HP9mXfkaNosqmIjfvcDaf l1PgBw/zlEI9zNLR91RnamI6tO2XFnpN4LxzVlfR0gAu+P5rWKUR3z6va/tlegV9BT9U KPSCXZr+BwxjFrm5H8ALGUzmCj8FvGDC+I3YyZB+JYFigxhFZUGsmtYqGAMN8kFrdIJe 0V3ZNg0CCmajmzQ3O/fB3QmeaJL2ELapaneG8ROb4chhuOnJiVB0pTBqVO3atUcMBq6j u8gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D6mhL/jPwfE8XdekJhB+QWCzFlF4CfFT/dWUjLSmMGE=; b=EJE7+I4xOxbWGUaNZmSYsqeKC5W3+C/DrOV70Bri8jQN8+DInIHXzAJf/uwn9MVjcb qC08vcuhA0qDfeLBahWjSEIr7TziF690mvx5d8N5zU3PKbYUWjJGSruHg6lMgIy4T1wY +dykvZrST0nAQBJtCbciQRnzuksJKi3WZ4bbpL99XZ+NZGTo2Qd0rwIPCI2gn8F5sEDq mgBjUYtyOwFYOJSvYGs8ZNVwBDmIK3SNd+yyA+TX23ikGfRWDxjWr/L1jrurdTP43V3S hDdfxH0FoC6DrsOyLS7XcyJ4cnILOOqYvxJ1swcMUKJ5Yb2vFhWUOHqGkOhgSaIS81xM KvPw== X-Gm-Message-State: APt69E2klm1AtzjbrNTA3p17xOmxB6eGMZaquN6/xBi4X9QO+QNji/6T BL+jN5JIehM/oDzuMd6sVbvTtf6sj6pZMUgNCZg= X-Google-Smtp-Source: AAOMgpejjNaJSyj9i13UgPOxSgMdfrgcEJUjkoteV59EKhHpzJazl7APcwIv/WnCVFsYy2yF3hEZRm/hV9Xo4XJ8Szg= X-Received: by 2002:a19:1510:: with SMTP id l16-v6mr31083lfi.88.1530668219843; Tue, 03 Jul 2018 18:36:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 18:36:59 -0700 (PDT) In-Reply-To: References: From: Kazuho Oku Date: Wed, 4 Jul 2018 10:36:59 +0900 Message-ID: To: Eric Rescorla Cc: Paul Wouters , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 01:37:05 -0000 2018-07-04 0:55 GMT+09:00 Eric Rescorla : > > > On Tue, Jul 3, 2018 at 8:40 AM, Paul Wouters wrote: >> >> On Mon, 2 Jul 2018, Eric Rescorla wrote: >> >>> It is strongly recommended not to use TXT records. Why not use a >>> new >>> RRTYPE? Everything these days knows how to serve unknown record >>> types >>> (see RFC 3597). The only possibly exception is provisioning tools >>> of >>> small players, but this document starts of saying you basically >>> need >>> to be on a bulk hosting provider anyway. They can properly >>> provision. >>> >>> See: >>> >>> https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906 >> >> >> [Can we keep the discussion within the IETF and the Note Well please. We >> also don't know what happens in 10 years with these links.] > > > If you look carefully, you'll see that this discussion happened weeks ago. I > was > just pointing you at it because you asked why we did it the way we did. > > With that said,IETF policy does not prohibit having discussions on Github.. > We do it > regularly in TLS and it's the standard policy in QUIC. > > >> >> quoting from that link: >> >> These facts lead to the conclusion that if we choose RRtype as the >> method, there would often be cases where the DNS record of the >> ESNIKey >> and the TLS server would be required to be operated by different >> entities. >> >> That seems to have confused two things with each other. I did not say >> anything about the location of the DNS record, only of the RRTYPE. >> Clearly, with the same location, it would be under control of the same >> entity, so I don't understand why you bring this up as a reason against >> using a dedicated RRTYPE. > > > I'm just quoting Kazuho here, so I'll let him respond to himself. The discussion was about comparing two approaches: a) use a new record type without suffix, b) use TXT record type with suffix. My argument was that we should select b because a has the deployability issue in regard to APEX names. It is true that the deployability issue is a concern related to the non-use of prefix. It is _not_ related to the selection of the record type. OTOH, I think that the reliability issue related to using a new record type exists, as others have pointed out. > > -Ekr > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku From nobody Tue Jul 3 19:44:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 793EC130EA4 for ; Tue, 3 Jul 2018 19:44:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfe8y9w5e-h2 for ; Tue, 3 Jul 2018 19:44:50 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 543E9130934 for ; Tue, 3 Jul 2018 19:44:50 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 4410C2975E9; Tue, 3 Jul 2018 22:44:49 -0400 (EDT) Date: Tue, 3 Jul 2018 22:44:49 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180704024449.GI85096@straasha.imrryr.org> Reply-To: tls@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 02:44:53 -0000 On Tue, Jul 03, 2018 at 10:41:18AM -0400, Allison Mankin wrote: > I haven't chimed in on the mailing list on this draft, but I'm one of the > people who had discussions with browserfolk in hallways, in the corners of > interim meetings for HTTP2, and other such places, in order to see what it > would take to get a start on TLSA use by browsers. The present dilemma for this draft is how to ensure that it has enough security benefit to warrant deployment and sufficient scope to cover would-be applications. The draft as originally approved had two major defects: * Required not only extension support, but also DNSSEC and DANE TLSA records in order to support "greefield" applications that mandate the extension from the get-go. * No plausible path to incremental adoption by existing WebPKI applications, that can't mandate the extension (let alone DNSSEC and DANE), but might employ DANE when present, but otherwise continue with WebPKI alone. The first defect is addressed by incorporating denial of existence. This allows a server to present an extension that proves lack of DNSSEC for a containing DNS zone or just absence of the associated TLSA records. In this way "greenfield" applications that mandate the extension can interoperate with servers that have not yet deployment DNSSEC or DANE. The second defect requires at least the ability to mandate the extension, when a server commits to continue to present it for some time. Since pinning is potentially fragile, we should be pinning as little as possible. Hence once again only support for the extension, rather than a continued expectation of DNSSEC, DANE, particular certificate details, ... This is NOT HPKP. This requires denial of existence support, adding which fortunately seems to have broad consensus. > Looking forward to discussion in Montreal. I'd like to see as much of the discussion as possible on list, where we can get responsive comments from informed participants, and not just "humming". > > 1. Do you support the working group taking on future work on a pinning > > mechanism (based on the modifications or another approach)? > > I support future work if there is extensive engagement and involvement by > members of the browser community who have expressed concerns about pinning. * TLS is not exclusively for HTTPS. * This extension is NOT just about browsers. It should support IMAP, SUBMIT, POP, XMPP, NNTP, ... * The "concerns about pinning" are often related to the unsurprising failure of HPKP. It is unfortunate that HPKP has tainted "pinning". And yet the IETF has just approved MTA-STS, which pins a commitment to WebPKI authentication along with a list of the domain's MX hosts. It is easy to taint the proposed downgrade protection mechanism by associating it (incorrectly) with HPKP. The proposal DOES NOT pin the peer certificates or keys. This is an STS-lite proposal, that pins only a capability: support for the extension for a particular TLS service endpoint. And in this case no "testing" mode is applicable, and sub-domain pinning is impactical. Looking at the existing STS-like protocols, it is easy to see that only their TTL applies here. > Reserving the bytes without a mechanism is not a good idea, so no. I don't see a rationale for this. The mechanism is a TTL to be carried in those bytes. We're willing to accept a variable-length field in order to accommodate objections that a TTL *might* not be enough, and a compelling case for additional attributes might be made in the future. I'm confident that no such case will hold up to scrutiny. -- Viktor. From nobody Tue Jul 3 20:31:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A18FC130934 for ; Tue, 3 Jul 2018 20:31:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3y3Pft2gyGMG for ; Tue, 3 Jul 2018 20:31:36 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2879130E69 for ; Tue, 3 Jul 2018 20:31:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41L63R4pvJz1km for ; Wed, 4 Jul 2018 05:31:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530675091; bh=PXPFtcadBv2zaaig/kZRFG09JjIUChSNe0ksjA4njLs=; h=Date:From:To:Subject:In-Reply-To:References; b=ZlyLXWmTmz2TXwE8rbJjCG23tQy1pqndr3Am57ETzIVjqH6Avi0TU6v/65/obr9Tz zPSaUynAKyRgmu8zuVYEmAPmsCFU9SIZ6BIeszG8QsmYuFl/H+kPPATV6L5gWsfDWn YaFbOjBDksJgX7nsifvaSL5zTexR+97aZ2wzyf7Y= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 6c4mAdkrPRsP for ; Wed, 4 Jul 2018 05:31:30 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Wed, 4 Jul 2018 05:31:29 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6896B62E80D; Tue, 3 Jul 2018 23:31:28 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 6896B62E80D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6101D457B314 for ; Tue, 3 Jul 2018 23:31:28 -0400 (EDT) Date: Tue, 3 Jul 2018 23:31:28 -0400 (EDT) From: Paul Wouters To: tls@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 03:31:39 -0000 On Tue, 3 Jul 2018, Eric Rescorla wrote: > but in this particular case, can't enterprise just strip ESNI records from DNS? Not if endnodes within the enterprise also use DNSSEC. Unless you want the enterprise to run authoritative fake DNSSEC for the entire world. It also requires installing internal trust anchors, which is something you pushed back hard on with draft-ietf-ipsecme-split-dns One way this could be done is if draft-ietf-dnsop-dns-rpz finally goes RFC, so IETF gains change control of a bis document, where we define the filtering to move the filtered record from the additional to the authority section, so the filtering can be detected yet DNSSEC verified. But it seems draft-ietf-dnsop-dns-rpz is being kept in draft state forever, which basically prevents us from fixing this. Paul ps. also note stripping a ESNI RRTYPE is easier than stripping _some_ TXT records :) From nobody Tue Jul 3 21:27:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA8B130E39 for ; Tue, 3 Jul 2018 21:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ohu6mOKykYeY for ; Tue, 3 Jul 2018 21:27:55 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003: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 7D6D2126CB6 for ; Tue, 3 Jul 2018 21:27:55 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id s198-v6so8168577oih.11 for ; Tue, 03 Jul 2018 21:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WcHCbbsaqvtshyO1y2b1bit5u/SR9AK1rPMt9UOGkE4=; b=JG4QfEhVQxuzLWuZJkz0KGuJdWmmLyjmZx52yFegxakPhLeDOuZdqlWiSIlHwjgfbV z8gP/NVXlZEU1f3F0RaQHdzDufJqnc08gMg6UPQvg8Ib2IM+XZVXLatCgl+3KuD4FcBE fLj69/tJZNj646kSLI7XjY3UxS6KUywQfA/7KeZXqFW10chAnqUp66wtvcaeoDaezNEw aKIG6EaRCMuLsjljPukO9gp07mZF/QkYvyXU6BZ9Och4giThfvOQuDF1QIU12wN06+BM R+c7nJ/GbiGiFrPrxDapLRMkQTmXaKorCXBzcC8Sv8ZF4XtMz3VdGlPNDbuoMwqV1f0y kPZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WcHCbbsaqvtshyO1y2b1bit5u/SR9AK1rPMt9UOGkE4=; b=HNR43gSmFMCJoJapCfwrJ83EDwLazCDlWCRBzdXgzzkQO+UbwhXWosDE8/4b9cCwiN uL/LjNzhKh/DeM0YXkAatyrRHzPiQzuVMs2nAWx85nE/QM32JRQv7orc1rHFe/6w0D2D w2rawzm11+dbNOapiEWfxkkCKZMCk80qyLwqG1T9jBSzfb4RRElQ7od3Qum8EjB4xKvC bZx97HrDMoFYNhARm6OakRX3B/EmFLwx3VDg8iCTB1AlmY5JT+bsGjzq29ADVptZAoLq ZAat1BUJaiZ1JvKTrluiSNlHhWW1PS3xZENkwV/6LJ8YyhcSrfaH7aV5ZMVBlbSo5EvJ FfWQ== X-Gm-Message-State: APt69E15bnY6dDPJ67TVX0cvMkOGKqkaa14Q4oz3uwVJMIeDWyWh59y2 iuyRM9n1kVNsJVCTIX0z3aq9Vc5tqp+pq4iij5b5qv/4 X-Google-Smtp-Source: AAOMgpejlo/sjVs8FRhlsn+Uj92W1+7vneXRMWaKmYE0A2/LOrK5pZ8tNfd5Rp783gCRw0sle1/Ilgo++zKGVWGuXkU= X-Received: by 2002:aca:afcc:: with SMTP id y195-v6mr494672oie.322.1530678474587; Tue, 03 Jul 2018 21:27:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:6082:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 21:27:53 -0700 (PDT) In-Reply-To: <20180703222414.17ee820c@computer.lan> References: <20180703222414.17ee820c@computer.lan> From: nalini elkins Date: Wed, 4 Jul 2018 09:57:53 +0530 Message-ID: To: =?UTF-8?Q?Hanno_B=C3=B6ck?= Cc: "" Content-Type: multipart/alternative; boundary="000000000000be5635057024da02" Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 04:27:57 -0000 --000000000000be5635057024da02 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >So-called "Enterprise" infrastructure has delayed the work of this group >for at least a year. Noone of the people creating that mess has reached >out to this group to explain why they constantly break TLS - let alone >apologize for it. >I believe there's a large overlap of the actors breaking TLS with the >actors who are worried about things like SNI encryption. I'm not sure I >see any reason not to consider these actors as anything but opposed to >the work of this group. I believe that enterprise people have tried over and over again to explain. You may wish to take a serious look at: https://datatracker.ietf.org/doc/draft-fenter-tls-decryption/ I, personally, have tremendous respect for the people in the TLS group. The level of cryptographic expertise as well as the passion / commitment is unparalleled. I think both "sides" are acting with good intentions - while looking at the world through their own lenses. Enterprises need to be able to do Busines= s As Usual (BAU) while integrating innovation into their networks. I suspect that no one likes middleboxes or "breaking" TLS but it is at leas= t temporarily necessary. You cannot hide your head in the sand and pretend it does not exist. Markets exist for a reason. People do not spend time and money to make presentations (at the TLS group) without having a very good reason to do so. IMHO, having everything at the end points (or the end-to-end principle) has led to an unsustainable trajectory to expensive and complex network functions and end-points. I have done a rudimentary survey of some of the enterprises I know and they say that much (if not most) of their time is spent in patchin= g applications and end points. This is one reason they cannot look ahead to bigger tasks like migrating to IPv6. I completely agree that enterprises have not presented the statistics and a carefully reasoned study to substantiate the above claims. I am in the process of taking a step back to see what we need to do - what drafts we need to write and what numbers we need to present - to have a full picture of how Internet protocols are used. Enterprises are a very large group of users of the Internet protocols and need to be considered as such. Nalini On Wed, Jul 4, 2018 at 1:54 AM, Hanno B=C3=B6ck wrote: > So-called "Enterprise" infrastructure has delayed the work of this group > for at least a year. Noone of the people creating that mess has reached > out to this group to explain why they constantly break TLS - let alone > apologize for it. > > I believe there's a large overlap of the actors breaking TLS with the > actors who are worried about things like SNI encryption. I'm not sure I > see any reason not to consider these actors as anything but opposed to > the work of this group. > > -- > Hanno B=C3=B6ck > https://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com --000000000000be5635057024da02 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>So-called "Enterprise&= quot; infrastructure has delayed the work of this group
>for at least a year. Noo= ne of the people creating that mess has reached
>out to this group to explain why= they constantly break TLS - let alone
>apologize for it.
<= br style=3D"font-size:12.8px;text-decoration-style:initial;text-decoration-= color:initial">>I believe th= ere's a large overlap of the actors breaking TLS with the
>actors who are wor= ried about things like SNI encryption. I'm not sure I
>see any reason not t= o consider these actors as anything but opposed to
>the work of this group.

I believe that enterprise people have tried over and over ag= ain to explain.=C2=A0=C2=A0
You may wish to take a serious look a= t:


= I, personally, have tremendous respect for the people in the TLS group.
The level of cryptographic expertise as well as the passion /
<= div>commitment is unparalleled.

I think both "= ;sides" are acting with good intentions - while looking at the
world through their own lenses.=C2=A0 =C2=A0Enterprises need to be able to = do Business
As Usual (BAU) while integrating innovation into = their networks.=C2=A0

I suspect that= no one likes middleboxes or "breaking" TLS but it is at least
temporarily necessary.=C2=A0 =C2=A0You cannot hide your= head in the sand and pretend
it does not exist.=C2=A0 Market= s=C2=A0exist for a reason.=C2=A0 =C2=A0

=
People do not spend time and money to make presentations (at the TLS grou= p)
without having a very good reason to do so.

IMHO,=C2=A0 hav= ing everything at the end points (or the end-to-end principle) has led=C2= =A0
to an uns= ustainable trajectory to expensive and complex=C2=A0network functions and
end-points.=C2= =A0 =C2=A0I have done a rudimentary survey of some of the enterprises I=C2= =A0
know and = they say that much (if not most) of their time is spent in patching<= /div>
applications and end= points.=C2=A0 This is one reason they cannot look ahead to
bigger tasks like migrating = to IPv6.

=
I completely= agree that enterprises have not presented the statistics and a=C2=A0
carefully reasoned= study to substantiate the above claims.=C2=A0 I am in the=C2=A0
process of taking a ste= p back to see what we need to do - what drafts we=C2=A0
<= div id=3D"gmail-yiv2549434813yui_3_16_0_ym19_1_1530412718209_10380" style= =3D"color:rgb(0,0,0);text-decoration-style:initial;text-decoration-color:in= itial">need to write and what n= umbers we need to present - to have a full
picture of how Internet protocols are used.

Enterprises are a very= large group of users of the Internet protocols and
need = to be considered as such.

Nalini

<= /div>

On Wed, Jul = 4, 2018 at 1:54 AM, Hanno B=C3=B6ck <hanno@hboeck.de> wrote:
So-called "Enterprise" infrastru= cture has delayed the work of this group
for at least a year. Noone of the people creating that mess has reached
out to this group to explain why they constantly break TLS - let alone
apologize for it.

I believe there's a large overlap of the actors breaking TLS with the actors who are worried about things like SNI encryption. I'm not sure I=
see any reason not to consider these actors as anything but opposed to
the work of this group.

--
Hanno B=C3=B6ck
https:/= /hboeck.de/

mail/jabber: hanno@hbo= eck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

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



--
Thanks,
Nalini Elkins
<= div style=3D"font-size:12.8px">President
Enterprise Data Center Operators
www.e-dco.com

--000000000000be5635057024da02-- From nobody Tue Jul 3 21:34:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48149130E3E for ; Tue, 3 Jul 2018 21:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lNs-cGm_jISe for ; Tue, 3 Jul 2018 21:34:19 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3CE126CB6 for ; Tue, 3 Jul 2018 21:34:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8C0DA4F8B8 for ; Wed, 4 Jul 2018 07:34:17 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 4S3a80jGC--Z for ; Wed, 4 Jul 2018 07:34:17 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1ADC772 for ; Wed, 4 Jul 2018 07:34:15 +0300 (EEST) Date: Wed, 4 Jul 2018 07:32:49 +0300 From: Ilari Liusvaara To: "tls@ietf.org" Message-ID: <20180704043249.GA10665@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 04:34:23 -0000 On Tue, Jul 03, 2018 at 07:50:00PM +0000, Tim Hollebeek wrote: > One of the things we found out with CAA is that this extremely optimistic view > of the support for unknown RR types by large hosting providers is not > accurate. As context, problems with CAA were not limited to various DNS hosters not supporting it or DNS recursives choking on it, but also things like: 1) Broken replies from _authoritative_ nameservers for CAA queries. 2) Timeouts from _authoritative_ nameservers for CAA queries. 3) Broken DNSSEC proofs for empty record sets. The most worrisome here is the 2). Even with good DNS recursive, you would still take timeouts. There are quite a bit of CAA-related problem reports on Let's Encrypt forums. Those are almost never of incorrect CAA records and rarely questions on how to add CAA, but generally problems caused by some authoritative nameserver being broken and causing CAA lookups to fail or return bogus answers. -Ilari From nobody Tue Jul 3 21:50:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5C1130E9D for ; Tue, 3 Jul 2018 21:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EL-_py_j9dbO for ; Tue, 3 Jul 2018 21:50:17 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7324130E3E for ; Tue, 3 Jul 2018 21:50:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 5F57D21C3F; Wed, 4 Jul 2018 07:50:14 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id P8X9MlygRnxj; Wed, 4 Jul 2018 07:50:13 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C9BFC79; Wed, 4 Jul 2018 07:50:10 +0300 (EEST) Date: Wed, 4 Jul 2018 07:48:44 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "" Message-ID: <20180704044844.GB10665@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 04:50:21 -0000 On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote: > > I just submitted: > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 > > This draft describes a DNS-based approach to doing encrypted SNI. > > Previously, we had thought this wouldn't work because only sites that > were particularly vulnerable would do it, and so the use of ESNI marks > you out. The idea behind this draft is that there are a lot of sites > which are hosted by -- and whose DNS is run by -- a large provider, > and that provider can shift many if not all of its sites to ESNI at > once, thus removing the "standing out" issue and making a DNS-based > approach practical. The recent Russia versus Telegram episode is kinda worrisome in this regard. Basically, it looked like the actions that created massive collaterial damage got at least two very large cloud provoders to disable one technique of hiding the name of the target server. > I am working on an implementation for NSS/Firefox and I know some > others are working on their own implementations, so hopefully we can > do some interop in Montreal. > > This is at a pretty early stage, so comments, questions, defect > reports welcome. One thing I noticed: First there is this in evaluation: 7.2.4. Do not stick out By sending SNI and ESNI values (with illegitimate digests), or by sending legitimate ESNI values for and "fake" SNI values, clients do not display clear signals of ESNI intent to passive eavesdroppers. Is that suggesting to send fake ESNI values? If so, there is this in endpoint behavior: 5.2. Client-Facing Server Behavior o If the EncryptedSNI.record_digest value does not match the cryptographic hash of any known ENSIKeys structure, it MUST abort the connection with an "illegal_parameter" alert. This is necessary to prevent downgrade attacks. So sending out fake ESNI values seems unsafe. My reading of that is that if server supports ESNI, but is not configured, then it MUST terminate (illegal_parameter) any handshake where ESNI extension was offered in. But that behaviour would cause any split mode handshakes to fail if backend supports ESNI. -Ilari From nobody Tue Jul 3 22:37:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149C6130DEF for ; Tue, 3 Jul 2018 22:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oDcIxZXqO4Gr for ; Tue, 3 Jul 2018 22:37:29 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003: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 DC456130E39 for ; Tue, 3 Jul 2018 22:37:27 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id c6-v6so8463253oiy.0 for ; Tue, 03 Jul 2018 22:37:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=lumRRQHZOSjiW2/RjrkbgNUj7UbbWbpVjzS4chq87qE=; b=rKbBZ1dS8mwR8Cr3IMHTdQX38y8EbipxIuBdbDVYXhPkhTeGaecjznbX6TYfD/Uh2g vQDwIdoV7WeokINGXKANQmo0ezGExVto7EbEyKARb2OmggE4JncnwM2++azW066Wb78a fntI1bT3fu147xxPW2o+9CL65v1EUDPqYVgY8J6sATgR94FkVOABNmV49bocvnaZeCAT 4OXPBeE9GjsG53jSBr3UEBiRtVR9Na2SrhsU5KVupV7WNf4wY9GQcWi/NCPHV53XYx7C c6q0R8AVTe6NaFOswN8UBiQR8FbRVCCT9NI0hJzyGw//1qWlOwZMQ9ZL/hAgv5hG6nba 2K/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=lumRRQHZOSjiW2/RjrkbgNUj7UbbWbpVjzS4chq87qE=; b=e6lDrujqeXQNsbVVUulBll/7pBkSTk3R14+a1kxt4B4ccbYUz7wN1s60UTpBV1TmrZ Dfhxaul556Pj79TK2vancAajwoP5XCryJAmxJY6zzOefVKjVVNcna19DMlPVA1HYuEo7 bVuXyVLGQ0pjHN0HrQoTNY6TsDGSbc1kbB1P1KB/YyuTUdVSlntr3YoFnnKomFNll3qz 3Hn5GKnumP7s4okuxCJr9WWy7jwjyOySgBsEaHdbn4PJ7qgoM83ImhujHCa5q5dGwZeR oxsktCVgH60B4Mnz1U4DehYcRRS/aKa0x3tSSG82qcCQxhe3r3K4KyfEoxZD12WVe0if kjbQ== X-Gm-Message-State: APt69E3vIMHcb1Qbq4vBjOSm5URmqOrLUhJvwLIbDiZ8hY9IV+8RZjXK Egd5tcoidTkCXBV2fgzvn7mlKr5QoRBzkP/d4pY5wg== X-Google-Smtp-Source: AAOMgpdfFIox6Uz0fBt4Y800iw4XxuB4OKlBJuobXMoNfbyAzDAoWlMBowFlnIF/KAvSVU5aZka7otezIvKBmqhzg6M= X-Received: by 2002:aca:d592:: with SMTP id m140-v6mr702933oig.346.1530682647000; Tue, 03 Jul 2018 22:37:27 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Wed, 4 Jul 2018 15:37:15 +1000 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Seeking reviews for draft-ietf-mmusic-sdp-uks X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 05:37:32 -0000 TLS People, The use of DTLS for real-time media doesn't get a whole lot of attention here, but there's some work in MMUSIC on fixing a problem with the interaction between an external signaling protocol and (D)TLS. This came out of some of the 1.3 analysis we were doing a while back. It's not a huge problem in a practical sense, but it's a hole we believe is worth patching. The MMUSIC chairs would like to move things along and feel like they need more eyes on this. As an author, I'd appreciate the same, especially from a group that is more likely to understand the problem space. Cheers, Martin From nobody Tue Jul 3 23:52:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64CCA130ED4 for ; Tue, 3 Jul 2018 23:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IW4y1wg1RXX6 for ; Tue, 3 Jul 2018 23:52:41 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 AC222130EC8 for ; Tue, 3 Jul 2018 23:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530687160; x=1562223160; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=JWiVpGla0jBZyAMrKdpW/Mk7F0K/6oLCDv+QEu5/17Y=; b=YPrilavKQwSFicX7A5deF5tIHmPR/GudpRwR0mk2LH+JzogXbbYL3iCE RDMikLYamNyHVe+ZtwVb+qxRKGUiTwBlFnQe7G1d9GSITT8ZBHUrqm64t x9qxScrN6sQaPdqvH0j5UuPELeSMZzALyx5iZrNGDhpmSTOSDY/K1Asq7 k8rBNH2Ugyec9a7Rh1hlbGnqfCwZk6z4vKcWpAXcUVcZnlGHOnGTQfMMt DKcFB4d9PdVENJ2zsbodDuBZ5TCU0kyUiU7K/Isml2TcBv9z9I/yCcJT5 FljNuEaO2EcGtJ/DRXJadkqxWOlIaVu+2rfVtjE7qbnLG45ylXnV4itA6 Q==; X-IronPort-AV: E=Sophos;i="5.51,306,1526299200"; d="scan'208";a="19528805" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Jul 2018 18:52:35 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Jul 2018 18:52:34 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Wed, 4 Jul 2018 18:52:34 +1200 From: Peter Gutmann To: "" Thread-Topic: Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YA== Date: Wed, 4 Jul 2018 06:52:33 +0000 Message-ID: <1530687136897.97792@cs.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 06:52:44 -0000 The following is an attempt to condense some off-list discussions with SCAD= A=0A= folks about the broken behaviour of some browsers when it comes to interact= ion=0A= with SCADA devices running TLS. tl;dr: Chrome is practically unusable, at = the=0A= other end of the scale Firefox is fine, and there's something weird happeni= ng=0A= with IE, possibly due to the use of non-CA-bought certificates.=0A= =0A= A disclaimer for the following: This involved a lot of fiddling with server= =0A= configs to exercise all the different options and recreate what people were= =0A= reporting, so there may be some anomalies arising from getting a particular= =0A= combination of browser+server config wrong. I can post a full trace of cip= her=0A= suites offered and accepted if anyone's interested.=0A= =0A= Browser versions=0A= =0A= IE =3D 11.0.9600.18538=0A= Chrome =3D 67.0.3396.87=0A= Firefox =3D last version before they broke all the extensions=0A= =0A= DHE + RSA, ECDHE + ECDSA, ECDHE + RSA, RSA only:=0A= Chrome:=0A= [Connects correctly]=0A= Firefox:=0A= [Connects correctly]=0A= IE:=0A= [Does some weird fallback dance where it reconnects using TLS 1.0 several= =0A= times when the cert is unrecognised and you click OK to accept it, then=0A= closes the connection after negotiating DHE at the point where the server = has=0A= sent its Server Hello Done]=0A= =0A= DHE + RSA, ECDHE + ECDSA, RSA only (using RSA server key, so in effect no E= CDSA):=0A= Chrome:=0A= [Client negotiates non-PFS pure-RSA and ignores PFS DHE, then disconnects= =0A= after sending/receiving Finished, then reconnects and repeats]=0A= Firefox:=0A= [Connects correctly]=0A= IE:=0A= [Does some weird fallback dance where it reconnects using TLS 1.0 several= =0A= times when the cert is unrecognised and you click OK to accept it, then=0A= closes the connection after negotiating DHE at the point where the server = has=0A= sent its Server Hello Done]=0A= =0A= DHE + RSA, RSA only:=0A= =0A= Chrome:=0A= [Client negotiates non-PFS pure-RSA and ignores PFS DHE]=0A= Firefox:=0A= [Connects correctly]=0A= IE:=0A= [Does some weird fallback dance where it reconnects using TLS 1.0 several= =0A= times when the cert is unrecognised and you click OK to accept it, then=0A= closes the connection after negotiating DHE at the point where the server = has=0A= sent its Server Hello Done]=0A= =0A= DHE + RSA only:=0A= =0A= Chrome:=0A= [Unable to connect, "The client and server don't support a common SSL proto= col=0A= version or cipher suite"]=0A= Firefox:=0A= [Connects correctly]=0A= IE:=0A= [Does some weird fallback dance where it reconnects using TLS 1.0 several= =0A= times when the cert is unrecognised and you click OK to accept it, then=0A= closes the connection after negotiating DHE at the point where the server = has=0A= sent its Server Hello Done]=0A= =0A= Summary:=0A= =0A= Most broken browser unless exactly the right cipher suite is available: Chr= ome=0A= Least broken browser: Firefox (at least for the last proper version they re= leased)=0A= =0A= Peter.=0A= From nobody Wed Jul 4 00:05:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80826130DD7 for ; Wed, 4 Jul 2018 00:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9kq-VuAZ_5i for ; Wed, 4 Jul 2018 00:05:20 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 75505130E44 for ; Wed, 4 Jul 2018 00:05:20 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id k81-v6so8785385oib.4 for ; Wed, 04 Jul 2018 00:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0qWK92xYsRvsgjdDZnaCnZAACbu16i3G49VumJgulPA=; b=h8DiKFu5SFveigYPXBxt0ztiNtXvPiI5MImNbqUpyj1v4JLfucbU2p4wJBCpEjUaJN KKd6NAZpmFafUJWXpfBUX9A++Brzt/9p0pT2YAL9jyfFFWG2k/TaHesarc0sxRqJVfjy ydSO+tQJUsIgsRKDG89nyDZjmQUADkgeaaKXQo/B/T4Wa/qgRtm1ErFCgX20II4ebQtQ uM2ctDzxR/dWPytYuCueK9uulkUVH5uvGKo9cxkvD6bK0YzBZB2qTbEREO7iQtE8vwlv 7cHEeE0lt6P1+ENNdqhXNVfFx53/tDeZl7/ghxTyhzs2W3kb9LArbc3mmZD+RKkUlQDE OaUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0qWK92xYsRvsgjdDZnaCnZAACbu16i3G49VumJgulPA=; b=fa/jWp90eUHwkIz/PbOaoqvc2FBTIpjiYTMB2LudGx2+6GYSDaez4inU1L3fukblQe 0of5wAcXjB169q34uOmkqY79sny/A0nwkrTDhQRff2b9BKiHS9Z+Qycqwh0phT5jwsdC 44+gFkwOd4SOn9qgN/9K0eccHJTadsRhJ2fe9u6WwOnWyVUUDPvIa7tJEEim+NMa93Ax Wx4c5p/+VYOX8y5w32smXTRqhu1CYdVl18/SWRuElUVBVmg2F1SRtJ7w+Wx+rdpJ1GpW Q/LEZfD0yOKguZgIloLTwoXdAmAvbXd68ua1aiOYucYhhJwiItVApvIbjdZ5jTZeHnaM QaCQ== X-Gm-Message-State: APt69E38jFKHwi4qPXdlUkJiJkAjlxK/LjViM4PW6x9ViBi2Cd9JdGVD 0I0OJyac8TodBaIjjvo4WBPtTrHrkzCA9L45j9pEs4ol X-Google-Smtp-Source: AAOMgpck7hMhXT3KBKOOeJ6laE2qzrKew3Zn9iruN+FRGohzyC8zbUDUqOEND99s/5+PzixJM6u5oVUpNYvqQvn3NoY= X-Received: by 2002:aca:d592:: with SMTP id m140-v6mr961888oig.346.1530687919681; Wed, 04 Jul 2018 00:05:19 -0700 (PDT) MIME-Version: 1.0 References: <1530687136897.97792@cs.auckland.ac.nz> In-Reply-To: <1530687136897.97792@cs.auckland.ac.nz> From: Martin Thomson Date: Wed, 4 Jul 2018 17:05:08 +1000 Message-ID: To: Peter Gutmann Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 07:05:23 -0000 On Wed, Jul 4, 2018 at 4:53 PM Peter Gutmann wrote: > ... Client negotiates non-PFS pure-RSA and ignores PFS DHE ... How is the client doing any of this? The server picks the cipher suite. > Least broken browser: Firefox (at least for the last proper version they released) Newer versions might not have DHE, which I hope is consistent with your expectations. But we haven't started on those plans. As of the latest version, things should be the same - extensions shouldn't affect whether connections work. The problem with DHE of course being that it uses the TLS 1.0 suites with the SHA1 MAC and with the MAC and encrypt in the wrong order. And that it is subject to small subgroup attacks from the server unless it negotiates the FFDHE extension. From nobody Wed Jul 4 00:42:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E121130DFD for ; Wed, 4 Jul 2018 00:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eRG2uGnwiESW for ; Wed, 4 Jul 2018 00:42:33 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 937FA130DF0 for ; Wed, 4 Jul 2018 00:42:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 386F94FAD7; Wed, 4 Jul 2018 10:42:31 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id QsAEStzRml0U; Wed, 4 Jul 2018 10:42:30 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 62C3E72; Wed, 4 Jul 2018 10:42:28 +0300 (EEST) Date: Wed, 4 Jul 2018 10:41:01 +0300 From: Ilari Liusvaara To: Martin Thomson Cc: "" Message-ID: <20180704074101.GA19789@LK-Perkele-VII> References: <1530687136897.97792@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 07:42:37 -0000 On Wed, Jul 04, 2018 at 05:05:08PM +1000, Martin Thomson wrote: > On Wed, Jul 4, 2018 at 4:53 PM Peter Gutmann wrote: > > ... Client negotiates non-PFS pure-RSA and ignores PFS DHE ... > > How is the client doing any of this? The server picks the cipher suite. > > > Least broken browser: Firefox (at least for the last proper version they released) > > Newer versions might not have DHE, which I hope is consistent with > your expectations. But we haven't started on those plans. As of the > latest version, things should be the same - extensions shouldn't > affect whether connections work. > > The problem with DHE of course being that it uses the TLS 1.0 suites > with the SHA1 MAC and with the MAC and encrypt in the wrong order. > And that it is subject to small subgroup attacks from the server > unless it negotiates the FFDHE extension. More serious problem is servers returning too small modulus due lack of negotiation. Which was the reason why Chrome disabled DHE. Also, there are finite-field AEAD ciphersuites in TLS 1.2, which do not use the broken blockmode nor SHA-1 (but Firefox does not appear to support any of these): - AES, ARIA or CAMELLIA in GCM mode, with 128 or 256 bit keys, and with RSA or DSS certificate (good luck getting DSS certificate, and even more luck getting clients to accept it). - AES in CCM mode, with 128 or 256 bit keys and 64 or 128 bit tags. Only RSA certificates are supported. - CHACHA20-POLY1305-AEAD with 256 bit keys. Only RSA certificates are supported. -Ilari From nobody Wed Jul 4 00:45:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06802130DF0 for ; Wed, 4 Jul 2018 00:45:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CUw1JB6bmxhF for ; Wed, 4 Jul 2018 00:45:41 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 05904130DF9 for ; Wed, 4 Jul 2018 00:45:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530690341; x=1562226341; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=7a9TuacCOXbVZzVWiHr9mGoIDXfqgWnIO4CrgaF04ZA=; b=bfpJ+0Rzn8L9mugmFG3a3QUAAw0PKs9FiRbZiZVYqRI3blJcTsJxlfp7 FWpKoy7RTwca489eije9VAtJBLN5i27CiRKPKYAcMxA+CJ3lwSOeZhwpx 5gRtTztRSpbFOg0f2U8M3q9APLMSQCsYAKyDSI8c5HQOrI0juWEv7Ffue VF1k+R/EeW5s4gxrTG2Wce1cJrF4a9HF0tPqMFtAWNV9YzZfuhbG7Xj2+ uScjvZUf+iX4Ja1VL391rpJmfOrvLKy0t+w0A479bkusvX5H6O/TOSTo1 m2fYYUCRbs0FI4gUABIlYnbWOEVQQwndMc7iwrn/YuPCLnscCRtwpzy5h Q==; X-IronPort-AV: E=Sophos;i="5.51,306,1526299200"; d="scan'208";a="19534687" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Jul 2018 19:45:38 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Jul 2018 19:45:37 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Wed, 4 Jul 2018 19:45:37 +1200 From: Peter Gutmann To: Martin Thomson CC: "" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgADQEJ8= Date: Wed, 4 Jul 2018 07:45:36 +0000 Message-ID: <1530690320155.99154@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 07:45:44 -0000 Martin Thomson writes:=0A= =0A= >How is the client doing any of this? The server picks the cipher suite.= =0A= =0A= Sorry, I meant the client only offers pure-RSA, not DHE+RSA, so the server = is=0A= forced to pick pure-RSA, e.g.:=0A= =0A= Chrome:=0A= =0A= Offered suite: TLS_RSA_WITH_AES_128_CBC_SHA.=0A= Accepted suite: TLS_RSA_WITH_AES_128_CBC_SHA.=0A= Offered suite: TLS_RSA_WITH_AES_256_CBC_SHA.=0A= Offered suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA.=0A= =0A= This is on a system without ECDHE present, so the server is looking for DHE= =0A= (preferentially) or RSA (if it really has to), the ECDHE suites are skipped= .=0A= This was noticed on systems which had disabled the pure-RSA suites because= =0A= some industry compliance thing required it, and found that Chrome was now= =0A= unusable for any of their devices.=0A= =0A= (My suggestion that they might consider QQ Browser didn't go down too=0A= well...).=0A= =0A= >Newer versions might not have DHE, which I hope is consistent with your=0A= >expectations=0A= =0A= Well, that'd bring FF closer to Chrome's brokenness. I guess I could add a= =0A= comment about FF copying everything Chrome does as being consistent with my= =0A= expectations :-).=0A= =0A= >As of the latest version, things should be the same - extensions shouldn't= =0A= >affect whether connections work.=0A= =0A= Sure, the only reason for mentioning the "last version with extensions" is= =0A= that apparently some of the systems require browser extensions, and they=0A= aren't going to be rewritten for current versions of Firefox. So it was=0A= whatever the last version with extensions was, either 52ESR or 56 (I didn't= =0A= ask, I'm on FF 56).=0A= =0A= >The problem with DHE of course being that it uses the TLS 1.0 suites with = the=0A= >SHA1 MAC and with the MAC and encrypt in the wrong order. =0A= =0A= Given that SHA-1 is used in the HMAC form it doesn't really matter security= -=0A= wise... the order of MAC and encrypt also depends on EtM/LTS support, I did= n't=0A= check for who does what there, the real issue was to report on browser issu= es=0A= when used in a SCADA environment and to poke vendors with a bit of a WTF?! = for=0A= their cipher suite support, or lack thereof. Currently the best by a long= =0A= shot is FF.=0A= =0A= Peter.=0A= From nobody Wed Jul 4 00:57:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2B35130DF9 for ; Wed, 4 Jul 2018 00:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlgHZlI_T6Yc for ; Wed, 4 Jul 2018 00:57:44 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 3850D130DC1 for ; Wed, 4 Jul 2018 00:57:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530691064; x=1562227064; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=booJYq1fNY16ggp/2EzRLAMRO2LvxeNokz6ouRRO7jo=; b=lA1kgohnS5n6Z9KEh6jPQ+g/0LUk+ec1sIYkZ8Zj4gD2Q+8bHFm8gUFC 9SgZN3huEWjDkV2S7XSTYOcMLSGSjOX6r2HpMppNB1z/ZcS0JzLQrwZVt tdqvyHJ/3ql9psbuBasYBUijlxnDP4oaTP5cZhc138vO4FKIEuuSUIpMS 4oZCQBKJTNQODrgNR3MdVxGS9307OwX+YyFPOK5MMfwRGBeDn1dlZc17Z sS38sayNzq6Ny/PR3S9xO/TeNFTMWwPUp/8oaOc3BwUQZtfX5saumGdvA J6E8mXJdepBHN6qS4kD1CrTieYVcEwXvXioVjTEbZlP/YJlcSw2HlE0Kg g==; X-IronPort-AV: E=Sophos;i="5.51,306,1526299200"; d="scan'208";a="19536371" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 04 Jul 2018 19:57:42 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.29) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Jul 2018 19:57:41 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Wed, 4 Jul 2018 19:57:41 +1200 From: Peter Gutmann To: Ilari Liusvaara , Martin Thomson CC: "" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYg== Date: Wed, 4 Jul 2018 07:57:41 +0000 Message-ID: <1530691044974.54956@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> , <20180704074101.GA19789@LK-Perkele-VII> In-Reply-To: <20180704074101.GA19789@LK-Perkele-VII> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 07:57:47 -0000 Ilari Liusvaara writes:=0A= =0A= >More serious problem is servers returning too small modulus due lack of=0A= >negotiation. Which was the reason why Chrome disabled DHE.=0A= =0A= Why not reject the handshake if the modulus is too small, rather than=0A= disabling all DHE suites on the off chance that the server returns a value = you=0A= don't like?=0A= =0A= >- AES, ARIA or CAMELLIA in GCM mode, with 128 or 256 bit keys, and with=0A= > RSA or DSS certificate (good luck getting DSS certificate, and even=0A= > more luck getting clients to accept it).=0A= >- AES in CCM mode, with 128 or 256 bit keys and 64 or 128 bit tags. Only= =0A= > RSA certificates are supported.=0A= >- CHACHA20-POLY1305-AEAD with 256 bit keys. Only RSA certificates are=0A= > supported.=0A= =0A= Wouldn't matter much anyway, suport for those is practically nonexistent (C= CM,=0A= Aria, Camellia, ChaCha20, and so on, I mean).=0A= =0A= OK, "practically nonexistent" may be too optimistic, I've never heard of=0A= anything supporting those. Having said that I don't know of every SCADA=0A= device in existence, maybe some Korean devices somewhere do Aria.=0A= =0A= DSA certs aren't a problem since they're all from non-commercial CAs (in-ho= use=0A= or self-signed), but I only know of a few systems using DSA. Can't remembe= r=0A= why they did that... oh yes, because keygen was faster/more efficient for D= SA,=0A= just a single modexp and no requirement for lots of CPU and memory.=0A= =0A= Peter.=0A= From nobody Wed Jul 4 01:16:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82809130E2E for ; Wed, 4 Jul 2018 01:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLQP8QWTDP-z for ; Wed, 4 Jul 2018 01:16:52 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495D0130DEC for ; Wed, 4 Jul 2018 01:16:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 12EB654911; Wed, 4 Jul 2018 11:16:49 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id zU-TvMf710T5; Wed, 4 Jul 2018 11:16:48 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 8AA6B2308; Wed, 4 Jul 2018 11:16:46 +0300 (EEST) Date: Wed, 4 Jul 2018 11:15:19 +0300 From: Ilari Liusvaara To: Peter Gutmann Cc: "" Message-ID: <20180704081519.GA20000@LK-Perkele-VII> References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1530691044974.54956@cs.auckland.ac.nz> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 08:16:56 -0000 On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote: > Ilari Liusvaara writes: > > >More serious problem is servers returning too small modulus due lack of > >negotiation. Which was the reason why Chrome disabled DHE. > > Why not reject the handshake if the modulus is too small, rather than > disabling all DHE suites on the off chance that the server returns a value you > don't like? Chrome initially did that. It caused quite a lot of bad feedback from owners of various bad embedded stuff. The thread on relevant forums was quite something. Hundreds of messages blaming Google for breaking stuff. -Ilari From nobody Wed Jul 4 01:41:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624AF130DFD for ; Wed, 4 Jul 2018 01:41:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSq0M5hs5_zt for ; Wed, 4 Jul 2018 01:41:34 -0700 (PDT) Received: from mail-wr0-f172.google.com (mail-wr0-f172.google.com [209.85.128.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04EF2130DC1 for ; Wed, 4 Jul 2018 01:41:34 -0700 (PDT) Received: by mail-wr0-f172.google.com with SMTP id s11-v6so4448051wra.13 for ; Wed, 04 Jul 2018 01:41:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=qFRNYagVNgKy87fxIXT3Bvg6e4O58ATDoxx/MQWqkFU=; b=teLGk1ZJT2zHansCU6SX8/0twyNareXwP6xT1uzWgRH3MSHDqpIgQ1E9CSNgsFEZs4 er/KP8sh8vZfEMAC5OX99Jhga13yvil19gL57CjNl7bC4TREexnOoIZApd2EN7Atq2RE axt/KQJYYteZl0AWzoID7sUrrUtvjZZ9HqpibPdn3zHT6wDvkmM/m0zNGUbsAEyCX2Zq 2KhJVz9lInKAWz1QpezDjJSPwcvjS0tv0aL/QBspuFZNppSNgyWyBFUnAgjiOl4hj/VE qAYIIBNbRsu2KvjdreqdGE1VUcI/S+VB5G0NE2p+svJmOqdkh9nRxP3u6wZxU1fQ8ck7 6Erg== X-Gm-Message-State: APt69E2m58fMogOf2R9jYdYA55HQKZxrEtpbqj/ivaEPx83QfiVhCnjx QLEng1NDM7I74vy5XWYihEnEZ5kYZIY= X-Google-Smtp-Source: AAOMgpfaHdEroIjwo30Dw355w5I5Ujaud/eLwRqLdyg82MWWEp6rrvvMEvPOGYdfdpS+hYRAoE1a7Q== X-Received: by 2002:adf:b815:: with SMTP id h21-v6mr894966wrf.40.1530693692502; Wed, 04 Jul 2018 01:41:32 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id q14-v6sm6241200wmd.20.2018.07.04.01.41.31 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 04 Jul 2018 01:41:31 -0700 (PDT) Message-ID: From: Nikos Mavrogiannopoulos To: Ilari Liusvaara , Peter Gutmann Cc: "" Date: Wed, 04 Jul 2018 10:41:31 +0200 In-Reply-To: <20180704081519.GA20000@LK-Perkele-VII> References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.2 (3.28.2-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 08:41:37 -0000 On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote: > On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote: > > Ilari Liusvaara writes: > > > > > More serious problem is servers returning too small modulus due > > > lack of > > > negotiation. Which was the reason why Chrome disabled DHE. > > > > Why not reject the handshake if the modulus is too small, rather > > than > > disabling all DHE suites on the off chance that the server returns > > a value you > > don't like? > > Chrome initially did that. It caused quite a lot of bad feedback from > owners of various bad embedded stuff. The thread on relevant forums > was > quite something. Hundreds of messages blaming Google for breaking > stuff. We had similar experience when we required a minimum of 2048-bit modulus for all TLS connections in Fedora 28 beta irrespective of back- end lib. It broke connections to VPN servers and web internal web sites and we had to revert the change. The DHE ciphersuites under TLS1.2 seem doomed and rfc7919 couldn't save them. regards, Nikos From nobody Wed Jul 4 02:22:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1C2A130E48 for ; Wed, 4 Jul 2018 02:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6iG83x7uwM_h for ; Wed, 4 Jul 2018 02:22:46 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003: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 D9278130E42 for ; Wed, 4 Jul 2018 02:22:45 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id c6-v6so9501573oiy.0 for ; Wed, 04 Jul 2018 02:22:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yYRZsQEI5ZyXnBjSVQ1DJa0vy9QNGH3ZD2SCkpPhL/Y=; b=oLBVauFZ+zJIJtFYKajrR7eN64YPwRgBdaNL6kUwWVSjYfmwZBk+kZORTx9DNfWZK+ koMQG4mCKG0cnGkbR5TpEVADT2H20vVrAyNyJxZIbGpVqbqVO98hUcsvDCv/Cd2jWTV0 W2Ur5F3/UByctEiQqdx2C22uGQOfIixf7kigzK8mjlzGIOxmBcpaAGWpQX43vMmK6/eG CsCOT00b+Szu2mvnbbNovGAQFbWbeaWSmH7fcl3nGs2Gu+PE1afaSuTZk8D+KubuD3jV yAjAVJNR5ymlCnZeKD0saSZUH2LbXjm3yC5Momg/zXmfLbbnP6OpKl0Ylk+pvnKEIsdu irjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yYRZsQEI5ZyXnBjSVQ1DJa0vy9QNGH3ZD2SCkpPhL/Y=; b=EHJtjWJCP7vl4IPwdhIP9TLChNkG8JCcN5GGoVzRp/wWYG03SvsXWmHjOUQreBxvrI MjY27ersGOR83eqmpYfXJK4bAGrKb2K12vCCw/XnPeBkUgosMAtESH0C1+WUzZVqVQsT XuHJShFPFQmRplQa51R1Fz5Abdg6ZeGyPvcK2OsCJDF2Ok3ZRMgPwaE+jaaIKjmYu923 953qu8aevdeZHsSRnRgtQsgncRhUMhU7pAv4zA5vd/3AvLAqdUmuBL3MaUV1z9AWkx+a ok9NEiLqeRHKAhLQ4yYNqWBO/q0E9kTBavRgO3C5W2SiK9SGUvFG1E8BjUL1G2Nw/10g XMDw== X-Gm-Message-State: APt69E2j9sP+/jqPaKsZEebGO+lDzwlNOR4GLZDfOQZNdgtqZcJubkjJ lPZuT4gTOATe53LYTzcuVhgfaNLI4zvKxLR34/I= X-Google-Smtp-Source: AAOMgpcPB5E4buelyONiFQbzBXzJK8Bzn8v2hUyfx9Yak6D3GEokrRP2HS1hW/WCna6+QUFt7YHNvaMawJdJJF/PSxI= X-Received: by 2002:aca:745:: with SMTP id 66-v6mr1197299oih.295.1530696164890; Wed, 04 Jul 2018 02:22:44 -0700 (PDT) MIME-Version: 1.0 References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> In-Reply-To: From: Martin Thomson Date: Wed, 4 Jul 2018 19:22:33 +1000 Message-ID: To: Nikos Mavrogiannopoulos Cc: Ilari Liusvaara , Peter Gutmann , "" Content-Type: multipart/alternative; boundary="0000000000002adbd9057028f928" Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 09:22:48 -0000 --0000000000002adbd9057028f928 Content-Type: text/plain; charset="UTF-8" On Wed, 4 Jul. 2018, 18:42 Nikos Mavrogiannopoulos, wrote: > We had similar experience when we required a minimum of 2048-bit > modulus for all TLS connections in Fedora 28 beta irrespective of back- > end lib. It broke connections to VPN servers and web internal web sites > and we had to revert the change. The DHE ciphersuites under TLS1.2 seem > doomed and rfc7919 couldn't save them. > It has been suggested that 7919 makes things worse. We have minimum modulus size constraints and haven't had any reports of issues, but the limits are fairly low and we have a less diverse usage environment than Redhat. We're also unable to catch big values that aren't prime, or values with small subgroups. We end up trusting servers more than we might consider ok for a modern protocol. That isn't a massive problem in my view. Of course, our recommendations don't change. Right now, that is to use TLS 1.3, or at least the configuration of TLS 1.2 that most closely resembles 1.3. The rest is stuff we merely tolerate for the sake of interoperability. Soon, I hope, we might be able to get rid of TLS 1.0 and 1.1, and these questions will be somewhat less interesting. > --0000000000002adbd9057028f928 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On W= ed, 4 Jul. 2018, 18:42 Nikos Mavrogiannopoulos, <nmav@redhat.com> wrote:=C2=A0
We had similar experience when we required a minimum of 2048-bit
modulus for all TLS connections in Fedora 28 beta irrespective of back-
end lib. It broke connections to VPN servers and web internal web sites
and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
doomed and rfc7919 couldn't save them.

It has been suggested that 7919 m= akes things worse.

We ha= ve minimum modulus size constraints and haven't had any reports of issu= es, but the limits are fairly low and we have a less diverse usage environm= ent than Redhat.

We'= re also unable to catch big values that aren't prime, or values with sm= all subgroups. We end up trusting servers more than we might consider ok fo= r a modern protocol. That isn't a massive problem in my view.

Of course, our recommendations do= n't change. Right now, that is to use TLS 1.3, or at least the configur= ation of TLS 1.2 that most closely resembles 1.3. The rest is stuff we mere= ly tolerate for the sake of interoperability. Soon, I hope, we might be abl= e to get rid of TLS 1.0 and 1.1, and these questions will be somewhat less = interesting.=C2=A0
--0000000000002adbd9057028f928-- From nobody Wed Jul 4 02:54:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F88C130E40 for ; Wed, 4 Jul 2018 02:54:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iKRjXPhv7zxD for ; Wed, 4 Jul 2018 02:54:20 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3343A130E17 for ; Wed, 4 Jul 2018 02:54:20 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4AA28401C7E9 for ; Wed, 4 Jul 2018 09:54:19 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 069E9111AF00 for ; Wed, 4 Jul 2018 09:54:18 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 04 Jul 2018 11:54:17 +0200 Message-ID: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5610978.he5WgMdfr5"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 04 Jul 2018 09:54:19 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 04 Jul 2018 09:54:19 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: [TLS] Malformed Finished handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 09:54:23 -0000 --nextPart5610978.he5WgMdfr5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Despite this, is it correct to terminate a connection with "illegal_paramet= er"=20 upon receiving a Finished handshake message with a 100 byte payload? or a 2= 0=20 byte payload? My opinion is that it is not, "decode_error" is more specific= so=20 it should be used instead. Specification says the following on the matter: The draft 28 specifies the Finished message as having following structure: struct { opaque verify_data[Hash.length]; } Finished; At multiple places it also talks about handling messages that have sizes th= at=20 don't match their structure as requiring termination of connection with=20 "decode_error". The generic situation in Section 6:=20 Peers which receive a message which cannot be parsed according to the syntax (e.g., have a length extending beyond the message boundary or contain an out-of-range length) MUST terminate the connection with a "decode_error" alert. as description of the alert in Section 6.2: decode_error A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This alert is used for errors where the message does not conform to the formal protocol syntax. In specific about Client Hello, in Section 4.1.2: If negotiating a version of TLS prior to 1.3, a server MUST check that the message either contains no data after legacy_compression_methods or that it contains a valid extensions block with no data following. If not, then it MUST abort the handshake with a "decode_error" alert. And specific handling of Certificate from server in Section 4.4.2.4: If the server supplies an empty Certificate message, the client MUST abort the handshake with a "decode_error" alert. Description of "illegal_parameter" in Section 6: Peers which receive a message which is syntactically correct but semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) MUST terminate the connection with an "illegal_parameter" alert. Alert description in Section 6.2: illegal_parameter A field in the handshake was incorrect or inconsistent with other fields. This alert is used for errors which conform to the formal protocol syntax but are otherwise incorrect. (it's also mentioned in over a dozen places in the draft) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart5610978.he5WgMdfr5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAls8mUoACgkQkqjRuAHS 9fVg/A/8CfZ09Ks5pz7BfqPS/wDoIUoidGNtv9PB7AcW34qfswBk87Ir4aZUtxLl H88iGMKwrQ/piCYFfzn7jGJrAsQS1gCuIwX9uWGLMO3Lq6InVKATcUHkyQRrsauF NQYoX+Ohu01Ia76Mi2mqihRD1TxP93hACZgy6DhD4WA1ccPGCNz6D7xTQ4oSd+xn +Q43VL18/ShDUvqJdt/zWarLokk7wELma1TwQbwIshdYfnQwo2DkXGT1D8TeSNPb dZc7bceKC1O8uMPoOcQsF7ddOwqA+qQsu8NDzMHwiMychJqozUXgZneN2WSGir/k YIoF47d6UH/G0MEjLkUnQzHOT0jlCKmfVAVqt9UkYh6sdkCx3mh1Gm2lrL2qOgzV ILmHuDrzZYMBBYl3uALZRSYUHO6inyo0/EfX4Dwft6v7uqRrLoNio/IRMwaSV7qk OLA3r9ECh6lrFBfUhAGSIcvalu37Mxs1xuvlQMMMoUTga0a5Eqjgp9FMAYd/rkbA t48wAKeCDnxnqe4l6XJsxeblTkr5ykA2dGMt/8kZs+mGIUSPh469hsMbNMvk5UdB jD+K0Nkaom/fm74P56GvMLdVbBU6sEOpYmG/hb//1phFKV688BqTT1w9l7dzEDII GxWhRSkJLqA1mBecZdRU8jjJ4J03n4sP+ulsrCoxbNmjCy/4pA0= =JSF8 -----END PGP SIGNATURE----- --nextPart5610978.he5WgMdfr5-- From nobody Wed Jul 4 03:01:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0044C130E40 for ; Wed, 4 Jul 2018 03:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q81yFYERd6Oj for ; Wed, 4 Jul 2018 03:01:27 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70818130E17 for ; Wed, 4 Jul 2018 03:01:27 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B63F8DFC8; Wed, 4 Jul 2018 10:01:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id C52912156889; Wed, 4 Jul 2018 10:01:25 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 04 Jul 2018 12:01:18 +0200 Message-ID: <1673271.m6b9jqBoj9@pintsize.usersys.redhat.com> In-Reply-To: <1530690320155.99154@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <1530690320155.99154@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3436085.DXQCehljto"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 04 Jul 2018 10:01:26 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Wed, 04 Jul 2018 10:01:26 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 10:01:29 -0000 --nextPart3436085.DXQCehljto Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 4 July 2018 09:45:36 CEST Peter Gutmann wrote: > Martin Thomson writes: > >As of the latest version, things should be the same - extensions shouldn= 't > >affect whether connections work. >=20 > Sure, the only reason for mentioning the "last version with extensions" is > that apparently some of the systems require browser extensions, and they > aren't going to be rewritten for current versions of Firefox. So it was > whatever the last version with extensions was, either 52ESR or 56 (I didn= 't > ask, I'm on FF 56). what "browser extensions"? you can't really do a modern TLS 1.2 without=20 extensions, let alone TLS 1.3 (which is now enabled by default in NSS). I'm= =20 quite sure NSS didn't drop any consequential ones... =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3436085.DXQCehljto Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAls8mu4ACgkQkqjRuAHS 9fU53A/5AfrICLsAx6SKSb4qLz5fj27GOz0yB7vi2e5ABsrGQB+qp3Evid3o0O2g TUgVfk0eCnZU+hXZN4Lh6uFxZYXUDGu1LChtD9E6eGImplvKRTQtOtZ8Ee3iWWmI OXqgtG5z3Fn3XpVHSiiCqSyetmxZ/naUsuDdvuzHAOgRU7pvUF5BsZsl2qv4w5Ux 7PbsxdB1Px8PNQ/gyIQurekehBZ7AZ1q89D2AP9sc1Kpi//YZMB4qAFn/oA1vmjG rlufHElP//gWqrK94dSYTcvBlr9Cha6s3xaSBZtad27j0iSSPYDUUHr+z1tcYtrN 6z/kQCsBm7pHu2uBkOMh3jRf0NKGm7vy5J6dPNaOZXzvH9B7Si/ZK4+cC0p0+fzB jJz60VSPcLpiIb1tMdNFSx+UP38ZINBMpUgVxLctIkHUatGDFL43tNGIpLeLWGcg UubUWXIYZNpdqE6d5DMoscwbWPrOVYdqw+gkWiiezs/lcBUzY8EVQm5W6Ffcl4Jc qjQ0Lpywtyc4YeRXy2/OwijBtf+IA2TZqIp+Ho/OTRD8vAwXx2jbHjcH/i1IDuAN Yi4wENb48UhImm4hICJhRyY+BgAxyUfbqoQE0NMyneuk4aP+YERdrcNI3St4xPLC LsXp9vZwiOJC/UA8ECwtQc8tfGreVAK5ushWOO/mQ5cXDLWvQ5o= =4pEQ -----END PGP SIGNATURE----- --nextPart3436085.DXQCehljto-- From nobody Wed Jul 4 05:24:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C04130E89 for ; Wed, 4 Jul 2018 05:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikhdEMFdlCdf for ; Wed, 4 Jul 2018 05:24:11 -0700 (PDT) Received: from excelsior.roeckx.be (excelsior.roeckx.be [IPv6:2a01:70:ffff:1::3]) (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 4D0FE130E5C for ; Wed, 4 Jul 2018 05:24:11 -0700 (PDT) Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by excelsior.roeckx.be (Postfix) with ESMTP id 060A5A8A036D; Wed, 4 Jul 2018 12:24:08 +0000 (UTC) Received: by intrepid.roeckx.be (Postfix, from userid 1000) id D92F31FE0A25; Wed, 4 Jul 2018 14:24:07 +0200 (CEST) Date: Wed, 4 Jul 2018 14:24:07 +0200 From: Kurt Roeckx To: Hubert Kario Cc: tls@ietf.org Message-ID: <20180704122407.GA10998@roeckx.be> References: <1530687136897.97792@cs.auckland.ac.nz> <1530690320155.99154@cs.auckland.ac.nz> <1673271.m6b9jqBoj9@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1673271.m6b9jqBoj9@pintsize.usersys.redhat.com> User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 12:24:14 -0000 On Wed, Jul 04, 2018 at 12:01:18PM +0200, Hubert Kario wrote: > what "browser extensions"? you can't really do a modern TLS 1.2 without > extensions, let alone TLS 1.3 (which is now enabled by default in NSS). I'm > quite sure NSS didn't drop any consequential ones... The extensions are not related to TLS, but are extentions / add-ons of the browser itself. Firefox dropped support for the old way of doing extensions in version 57. They also added the WebExtensions API that is also implemented in other browsers. This required major rewrites of the extensions, and some were never changed to work with the new API. Kurt From nobody Wed Jul 4 05:42:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB47130E61 for ; Wed, 4 Jul 2018 05:42:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltLoBQdXC6FQ for ; Wed, 4 Jul 2018 05:42:54 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05E47130E5C for ; Wed, 4 Jul 2018 05:42:54 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0A39E81A4EA9 for ; Wed, 4 Jul 2018 12:42:53 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id BC00F2156889 for ; Wed, 4 Jul 2018 12:42:52 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 04 Jul 2018 14:42:51 +0200 Message-ID: <1857183.8Fq0dhFQ1N@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3572110.byc25XTUlz"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 04 Jul 2018 12:42:53 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 04 Jul 2018 12:42:53 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: [TLS] [PSA] 0-RTT tolerance is mandatory X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 12:42:57 -0000 --nextPart3572110.byc25XTUlz Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" All the implementations I deal with in my day-to-day work fail to handle th= e=20 0-RTT client hello correctly when the 0-RTT support is not enabled on the=20 server. I.e. they ignore the MUST clause from https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that th= e=20 server can handle an early_data extension (and following encrypted data) in= =20 only one of three ways, neither which allows for unconditional connection=20 abort. This also runs afoul the recommendation from https://tools.ietf.org/html/ draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility. Quick test can be performed by running the tlsfuzzer script. Start a server on port 4433 (or use the -p switch to the test case to chang= e=20 it) on localhost (or use -h switch to provide ip or hostname) with support = for=20 draft-28, a RSA server key, support for P-256 ECDH, AES-128-GCM cipher and= =20 SHA-256 signature hash. The server needs to be able to respond to a record= =20 with an HTTP GET query (i.e. either HTTP server or an echo server will work= ). Download the requirements: git clone https://github.com/tomato42/tlsfuzzer pushd tlsfuzzer # won't be needed after tlsfuzzer#423 PR is merged git checkout 0rtt-garbage-resumption git clone https://github.com/tomato42/tlslite-ng .tlslite-ng ln -s .tlslite-ng/tlslite tlslite git clone https://github.com/warner/python-ecdsa .python-ecdsa ln -s .python-ecdsa/ecdsa ecdsa Run the test case: PYTHONPATH=3D. python scripts/test-tls13-0rtt-garbage.py successful run will print Test end successful: 3 failed: 0 at the end the test case supports also --num-bytes switch to provide how big the early= =20 data should be (sends 2^14B by default). =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3572110.byc25XTUlz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAls8wMsACgkQkqjRuAHS 9fUXhw//QyfJR6j8L7OJEDBC2lAzHQvZZ86uE6EsQxA7rJdlUJcfVM7Gmhn3QTAd SIQpAXqqfprnqTlwZShxe9J/mGgpMC92ZR3JYwR2IXk2EBrmThabKdBL1YTqZFnI XbXTLDfA//MpcI6CQMN3wPSvcMWbsvTEKGCDheFCO5qUta5Qslbd5QfGpP53aKar LTCv886b/FYg9I0FuoCQ7+Ht2PL0y+uisX6SQCZxo16ID6i+xGX6nmEf5z7rCaTZ aOSFXsNbtuZrJkWbdBjJhlUdGNqPfl4bbHsTZeXSoCUPn8G4WwwD3dV/+csAx9LM NhCNP92eh8KbYjoK1aqgoDGiiGHbh9J7UeUoY7pVpuf8p63IZzPgZ5RDbCBLauP0 DcRijTNqPvzDmweLHY4MLx9Uu13QwF8nHgp/tjqY+zY14OEEg8qtjV7TV7lWoCcv h95Vkn/oxD2DyZTsQcEwmr/x3u0Ae/9RUcvYkVPjamn/YFmOa2FiWJoz80mqfChl eFjMGGFKMEc4hO6K3GdOOPIqs2Pq6IfJWxotSIYQetK6v8pgzj4CUe3jFb3xjU+R dzzx+EyRUk3d0hd/z2PPUCvVqWwoc/cgJ6UFsZda3BpeXS42kQiVz1kpyvtbbCaN lY5SSlntD1wOMBWcGe2M6mL1KWM9HBDq9EaomjOQmIoHD2zW/3w= =RSpc -----END PGP SIGNATURE----- --nextPart3572110.byc25XTUlz-- From nobody Wed Jul 4 05:56:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC826130E72 for ; Wed, 4 Jul 2018 05:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DnKlF0bb_CK for ; Wed, 4 Jul 2018 05:56:49 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07156130F63 for ; Wed, 4 Jul 2018 05:56:49 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id c135-v6so1905373ywa.0 for ; Wed, 04 Jul 2018 05:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=T2LSYiLaD4PD7vjbvoB0MomoMwrTWvs81r2grSPygaU=; b=dCvnu+4kcPC7CEdZnR0H1r1Hjxx3UluPzDF4SKePYPVyejgoZP/vy3FAqvpVLknuTf keBxIRzJ/SmgIG7SbU3ZadzFQKk0AQU1iuTyLHiKvUDiVmZDlbIWheTdpVeu69uRPA1D kLybDbgPzTGgSCrGTd+YAKW+eEcE+zgVPofT0FfHpdD1ITzgHTQvsK0zzPUd3kge8VnA RCVJGt5BUTLM0CuhjrDVjhKv1ds7gbbR64Q9e91RQchVIkKJ7sKUJJE54L3uZWeyARyP Rj1dSy60ysnpYMXFsDLVziE2/3tz78gkD8ljrtjJrB5hwippLQ3/8FjRBCUJk6r9GDhf 2Umg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=T2LSYiLaD4PD7vjbvoB0MomoMwrTWvs81r2grSPygaU=; b=QOLgKHNS7GOjFYlFXVYm/aa4EU3903EWXF+ggkohpHSw1P5ocHkExPvcjlkNgtP6lz NAjS+LDMP/2Ns2GmBKt9iAFGraRa7zaSF8B6BfBYgtoIqLkG1Fffdbqlc1zZw0kEbs1v 9lcP6tEOoUzrIdGGayH9BkL1LI7jX0SPWRy1H8Xv2/fSZaCPBxE9qZURMm8j7ZAP5R8u J+H68obvGxC+H5yYAVcGs4+2ONGBH2EFdH9qGYAeSlNnkLGxpMSpmES6LoyTuE/U8Yjn C2U34aGlLLZmrN885aAwMH9ILXq3RTbyXNRri5+4yjnfVFI00BSjeMVCp3ZfKLL6y57l h8uA== X-Gm-Message-State: APt69E2cA7foRMDGItgrxuE2nIA1Cu5ig4bgeVbg2xlnU4EWtGQyFmFG 1oDxzurCRzV4W2teEBcUGdahShVTabTrVrYr8lnlRg== X-Google-Smtp-Source: AAOMgpenMjomKviIKxscjH0AKlgvkZnNQ4rDIkhWU9yhILkm3nvADheD5a4n+1mk7NCTD4SpeCbgIS59Spdpzj+t8ws= X-Received: by 2002:a81:3e02:: with SMTP id l2-v6mr862852ywa.381.1530709008296; Wed, 04 Jul 2018 05:56:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 05:56:07 -0700 (PDT) In-Reply-To: <20180704044844.GB10665@LK-Perkele-VII> References: <20180704044844.GB10665@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 4 Jul 2018 05:56:07 -0700 Message-ID: To: Ilari Liusvaara Cc: "" Content-Type: multipart/alternative; boundary="000000000000b1c5f605702bf6ab" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 12:56:52 -0000 --000000000000b1c5f605702bf6ab Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara wrote: > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:= > > I am working on an implementation for NSS/Firefox and I know some > > others are working on their own implementations, so hopefully we can > > do some interop in Montreal. > > > > This is at a pretty early stage, so comments, questions, defect > > reports welcome. > > One thing I noticed: First there is this in evaluation: > > 7.2.4. Do not stick out > > By sending SNI and ESNI values (with illegitimate digests), or by > sending legitimate ESNI values for and "fake" SNI values, clients do > not display clear signals of ESNI intent to passive eavesdroppers. > > Is that suggesting to send fake ESNI values? If so, there is this in > endpoint behavior: > No, you would not send fake ESNI values. The idea here is that there is a group of IPs (associated with a big provider, then all ESNI-supporting clients will send ESNI to it. So the provider will stick out, but the use of site X versus site Y on the provider will not stick out. And the provider's IPs are reasonably well known through other mechanisms, so this doesn't tell you much. Of course, this does not help big sites that aren't using shared infrastructure (e.g., Facebook), but I don't know how to do that. -Ekr > > > -Ilari > --000000000000b1c5f605702bf6ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=3D<= br> > I am working on an implementation for NSS/Firefox and I know some
> others are working on their own implementations, so hopefully we can > do some interop in Montreal.
>
> This is at a pretty early stage, so comments, questions, defect
> reports welcome.

One thing I noticed: First there is this in evaluation:

7.2.4.=C2=A0 Do not stick out

=C2=A0 =C2=A0By sending SNI and ESNI values (with illegitimate digests), or= by
=C2=A0 =C2=A0sending legitimate ESNI values for and "fake" SNI va= lues, clients do
=C2=A0 =C2=A0not display clear signals of ESNI intent to passive eavesdropp= ers.

Is that suggesting to send fake ESNI values? If so, there is this in
endpoint behavior:

No, you would not se= nd fake ESNI values. The idea here is that there is a group of IPs (associa= ted with a big provider, then all ESNI-supporting clients will send ESNI to= it. So the provider will stick out, but the use of site X versus site Y on= the provider will not=C2=A0=C2=A0=C2=A0 stick out. And the provider's = IPs are reasonably well known through other mechanisms, so this doesn't= tell you much. Of course, this does not help big sites that aren't usi= ng shared infrastructure (e.g., Facebook), but I don't know how to do t= hat.

-Ekr




-Ilari

--000000000000b1c5f605702bf6ab-- From nobody Wed Jul 4 06:01:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4912A130E6E for ; Wed, 4 Jul 2018 06:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlKhmYVx8UV3 for ; Wed, 4 Jul 2018 06:01:00 -0700 (PDT) Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3E05127332 for ; Wed, 4 Jul 2018 06:00:59 -0700 (PDT) Received: by mail-yw0-x22c.google.com with SMTP id l189-v6so1897178ywb.10 for ; Wed, 04 Jul 2018 06:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/RRTedCLRAlo5VdsVuHKpR3VAQaZLOOaTaa8P7J21IE=; b=CFCchHKT1wOdz8+hhUQk2thi5LW/0+VvpDGbk9aZ7BefKitT/W13HBrh4WG6pQ+GIW VEjrTh+WISRBhAExZxtZuiDALZ9JaHKH39+L57x6ftNKZPURcIMeZzZCxm4c6/Fg5Qnd M90dylDypZ75DD8KJkyi0eFPD4mBG0Wk6h1j6mhvIaM/JP6uulCK91fqYzaHE9vWqccE FdYHKMPAOYdxgbDdRZKJyGGdZlt32+rgegFZaeqIV6zbRqoTDEUlHxF47KFFwG0+lPuj pLtYoHPh9ZflX6EYht7n/ITLl3ToamXHq1ravudmqSZhXsmNEZj14BfAEgiGqiVg4Gaw 61sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/RRTedCLRAlo5VdsVuHKpR3VAQaZLOOaTaa8P7J21IE=; b=ekM/XOGNVYkQ6tWHD30qLZbqxlWz8qQQ2fYzIUdia4puuETnWMSJXceyp5Lv9+M2g4 IxvthzowwO5/YZNutaA6zzUZCk53FnVrShfqqMwhejI115Fer5q8KrERHp4ORhDJpy/x Noum9AFsqY9PBSzg9oOuGjEEHft5UKNe01n63pmGTODXzrhKjtL2QKx1Z69UAqeVAKA5 fRnIni1WOpxVl2SYuRjmdGPo49hh8rKRe29pmg3kWy/MK2zyAqlSaLj2QlhPCR1raSk0 vTALtFKSj3wzYpwmaVPLCBPDZOZ5mF10sk3ap21uBSU0UO4uRRqSkCbWV17HUghvJreB vbYw== X-Gm-Message-State: APt69E3K3fprrZU4A7DkuBqRbemAUmKyStilzRRzC9DUHwkAfQ7JpzNB iaQK8cDbEAzrDi+SiixlhYLKP1ofut3n6dP/KzexUg== X-Google-Smtp-Source: AAOMgpcOdNJdrXP8bjtTYgz70grk6cnEC2q5FWyAic0c0Y2HaKJjDr06Qxn6k517vhEZoyQ3LqaEUO7XJjlMXe9lK6k= X-Received: by 2002:a0d:f286:: with SMTP id b128-v6mr817987ywf.489.1530709259125; Wed, 04 Jul 2018 06:00:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 06:00:18 -0700 (PDT) In-Reply-To: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 4 Jul 2018 06:00:18 -0700 Message-ID: To: Hubert Kario Cc: "" Content-Type: multipart/alternative; boundary="000000000000a51d3505702c051c" Archived-At: Subject: Re: [TLS] Malformed Finished handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 13:01:02 -0000 --000000000000a51d3505702c051c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think it's a close call, because the length is sort of external to the language. That's why, for instance, NSS sends "illegal_parameter". So, absent specific text about this value, I think this is something we can leave to the implementations. -Ekr On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario wrote: > Despite this, is it correct to terminate a connection with > "illegal_parameter" > upon receiving a Finished handshake message with a 100 byte payload? or a > 20 > byte payload? My opinion is that it is not, "decode_error" is more > specific so > it should be used instead. > > > Specification says the following on the matter: > > The draft 28 specifies the Finished message as having following structure= : > > struct { > opaque verify_data[Hash.length]; > } Finished; > > At multiple places it also talks about handling messages that have sizes > that > don't match their structure as requiring termination of connection with > "decode_error". > > The generic situation in Section 6: > > Peers which receive a message which > cannot be parsed according to the syntax (e.g., have a length > extending beyond the message boundary or contain an out-of-range > length) MUST terminate the connection with a "decode_error" alert. > > as description of the alert in Section 6.2: > > decode_error A message could not be decoded because some field was > out of the specified range or the length of the message was > incorrect. This alert is used for errors where the message does > not conform to the formal protocol syntax. > > In specific about Client Hello, in Section 4.1.2: > > If negotiating a version of TLS prior to 1.3, a server MUST check > that the message either contains no data after > legacy_compression_methods or that it contains a valid extensions > block with no data following. If not, then it MUST abort the > handshake with a "decode_error" alert. > > And specific handling of Certificate from server in Section 4.4.2.4: > > If the server supplies an empty Certificate message, the client MUST > abort the handshake with a "decode_error" alert. > > Description of "illegal_parameter" in Section 6: > > Peers which receive a message which is syntactically correct but > semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) > MUST terminate the connection with an "illegal_parameter" alert. > > Alert description in Section 6.2: > > illegal_parameter A field in the handshake was incorrect or > inconsistent with other fields. This alert is used for errors > which conform to the formal protocol syntax but are otherwise > incorrect. > > (it's also mentioned in over a dozen places in the draft) > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --000000000000a51d3505702c051c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think it's a close call, because the length is = sort of external to the language. That's why, for instance, NSS sends &= quot;illegal_parameter". So, absent specific text about this value, I = think this is something we can leave to the implementations.
=
-Ekr




On Wed, Jul 4, 2= 018 at 2:54 AM, Hubert Kario <hkario@redhat.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">Despite this, is it correct to terminate a co= nnection with "illegal_parameter"
upon receiving a Finished handshake message with a 100 byte payload? or a 2= 0
byte payload? My opinion is that it is not, "decode_error" is mor= e specific so
it should be used instead.


Specification says the following on the matter:

The draft 28 specifies the Finished message as having following structure:<= br>
=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque verify_data[Hash.length];
=C2=A0 =C2=A0 =C2=A0 } Finished;

At multiple places it also talks about handling messages that have sizes th= at
don't match their structure as requiring termination of connection with=
"decode_error".

The generic situation in Section 6:

=C2=A0 =C2=A0Peers which receive a message which
=C2=A0 =C2=A0cannot be parsed according to the syntax (e.g., have a length<= br> =C2=A0 =C2=A0extending beyond the message boundary or contain an out-of-ran= ge
=C2=A0 =C2=A0length) MUST terminate the connection with a "decode_erro= r" alert.

as description of the alert in Section 6.2:

=C2=A0 =C2=A0decode_error=C2=A0 A message could not be decoded because some= field was
=C2=A0 =C2=A0 =C2=A0 out of the specified range or the length of the messag= e was
=C2=A0 =C2=A0 =C2=A0 incorrect.=C2=A0 This alert is used for errors where t= he message does
=C2=A0 =C2=A0 =C2=A0 not conform to the formal protocol syntax.

In specific about Client Hello, in Section 4.1.2:

=C2=A0 =C2=A0If negotiating a version of TLS prior to 1.3, a server MUST ch= eck
=C2=A0 =C2=A0that the message either contains no data after
=C2=A0 =C2=A0legacy_compression_methods or that it contains a valid extensi= ons
=C2=A0 =C2=A0block with no data following.=C2=A0 If not, then it MUST abort= the
=C2=A0 =C2=A0handshake with a "decode_error" alert.

And specific handling of Certificate from server in Section 4.4.2.4:

=C2=A0 =C2=A0If the server supplies an empty Certificate message, the clien= t MUST
=C2=A0 =C2=A0abort the handshake with a "decode_error" alert.

Description of "illegal_parameter" in Section 6:

=C2=A0 =C2=A0Peers which receive a message which is syntactically correct b= ut
=C2=A0 =C2=A0semantically invalid (e.g., a DHE share of p - 1, or an invali= d enum)
=C2=A0 =C2=A0MUST terminate the connection with an "illegal_parameter&= quot; alert.

Alert description in Section 6.2:

=C2=A0 =C2=A0illegal_parameter=C2=A0 A field in the handshake was incorrect= or
=C2=A0 =C2=A0 =C2=A0 inconsistent with other fields.=C2=A0 This alert is us= ed for errors
=C2=A0 =C2=A0 =C2=A0 which conform to the formal protocol syntax but are ot= herwise
=C2=A0 =C2=A0 =C2=A0 incorrect.

(it's also mentioned in over a dozen places in the draft)
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--000000000000a51d3505702c051c-- From nobody Wed Jul 4 06:01:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948A9130F2D for ; Wed, 4 Jul 2018 06:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0LKx8vfxEZD for ; Wed, 4 Jul 2018 06:01:31 -0700 (PDT) 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 F060B130F75 for ; Wed, 4 Jul 2018 06:01:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id ACD8BBE38; Wed, 4 Jul 2018 14:01:28 +0100 (IST) 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 c8syP7dMQIME; Wed, 4 Jul 2018 14:01:28 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 68918BDD8; Wed, 4 Jul 2018 14:01:28 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1530709288; bh=lBKfHdiE6+pNTLx86q7gvsz6ZR5t4k6Qxh49zSWz3io=; h=To:References:From:Subject:Date:In-Reply-To:From; b=FVo3uBcIZ15OEwXifnxnPvN9vH1O/0ql2dlKoQvc3fQOV70Gc9/kI8mw/nxxnKdPf oZ5f+lajzuJ3tVis60K8xGzJOTqcHQkQQtuAhFPUbnRnsj/2snwo4uY/HmG+2BHvy8 rlxrnw9jV+f7WX5YqMekoWH7EhN4M/gHchfkCCUs= To: Eric Rescorla , "" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 4 Jul 2018 14:01:26 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="tEcC2NYhXAQEnuLjjafYoANri1R361fcG" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 13:01:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tEcC2NYhXAQEnuLjjafYoANri1R361fcG Content-Type: multipart/mixed; boundary="LNMiGtkt5ZRF506fS3UJOtNyalwVFfPfD"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla , "" Message-ID: Subject: Re: [TLS] DNS-based Encrypted SNI References: In-Reply-To: --LNMiGtkt5ZRF506fS3UJOtNyalwVFfPfD Content-Type: multipart/mixed; boundary="------------B741CBA82F03977B5E4CFBD9" Content-Language: en-GB This is a multi-part message in MIME format. --------------B741CBA82F03977B5E4CFBD9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 03/07/18 00:39, Eric Rescorla wrote: > Hi folks, >=20 > I just submitted: >=20 > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 Thanks for writing that up. I think it's an interesting addition to the set of potential solutions. >=20 > This draft describes a DNS-based approach to doing encrypted SNI. >=20 > Previously, we had thought this wouldn't work because only sites that > were particularly vulnerable would do it, and so the use of ESNI marks > you out. The idea behind this draft is that there are a lot of sites > which are hosted by -- and whose DNS is run by -- a large provider, > and that provider can shift many if not all of its sites to ESNI at > once, thus removing the "standing out" issue and making a DNS-based > approach practical. I'm not sure I fully understand how this approach would fit with others, nor to what extent it depends on the DNS and CDN providers co-operating, but it definitely seems worth exploring. >=20 > I am working on an implementation for NSS/Firefox and I know some > others are working on their own implementations, so hopefully we can > do some interop in Montreal. >=20 > This is at a pretty early stage, so comments, questions, defect > reports welcome. Quick comments after flicking through the draft: - I'm not that fussed myself as to whether this uses a TXT or new RRTYPE. But if the latter would work, it seems better. - I didn't quite get what "all the domains" in 3.2 means. I guess if a client uses non-encrypted sni for one of those, it should still work, but I'm not clear if supporting esni for any domain means that the provider has to decrypt esni and then deal with successful decrypted sni values as if the client had sent sni in clear. A concern is requiring "all the domains" might make it hard to roll this out. - I guess some form(s) of key rollover will be needed, ut I'm not sure that not_before/not_after is the best way to do that. - The ESNIKeys structure generally seems a bit complicated, it might be better to aim for simplifying that and maybe making it more "zonefile friendly" (whether in a TXT RR or not). - It might be interesting to think about how this'd work for e.g. the IETF web site (where ietf.org is hosted locally but www.ietf.org is not), and for STARTTLS and MX RRs. That's probably ok, but I've not gotten it straight in my little head yet:-) - Would it make sense to include the innocuous dummy sni in the published RR, so that all clients use the same one and stand out that bit less? - 7.1 probably needs more work - I'm not sure that it's that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE, or a client application that knows the ESNIKeys, are most likely needed, but there's probably also some work to do to analyse the recursive to authoritative interactions to get the ESNIKeys even with DPRIVE. Lastly, the topic of whether or not to try address this problem is something that the WG has debated quite a bit, and IIRC the consensus after that debate was to do work on this (hence Christian's draft). So I don't see any need to debate whether or not to work on this is needed, and trying to re-open such a debate seems somewhat disruptive to me. It is entirely reasonable to consider what, if anything, widespread use of esni or other approaches might break though. But going back to all this "privacy at any cost" and "we're the enterprises" hyperbole is not at all helpful IMO, so I hope we don't have to suffer more rounds of that. But maybe that's inevitable with every iteration of attempts to improve privacy sadly;-( Cheers, S. >=20 > -Ekr >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------B741CBA82F03977B5E4CFBD9 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------B741CBA82F03977B5E4CFBD9-- --LNMiGtkt5ZRF506fS3UJOtNyalwVFfPfD-- --tEcC2NYhXAQEnuLjjafYoANri1R361fcG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAls8xSYACgkQWrL68XsX K+rriA//We6HCsmj+7uY22R+be3sF6/T7KdFGqkOwV3cO2tbv83xEuoA8PbGabk4 r3kWQgrSyHM9QcjM2Pbo5Wgx/puqplBW0NgzgS1WVWGuGsgNT4wdhSyiX6aAaxJH rjpKihr5zCZkNvkijgiXJlhwEchsHt4SCwYdBaU+In+s4h1RozgSLlaDbSeLxtW6 /n0b5HE2CFUDgPNroObvy/ydXSwKwga5Wa9/8s8wkToJz3BiLYLOR2xLOyQfcxcf 9PJoOX7jCeQGafCmNGOvjAGQKoMF0dMbqw4e/1h1jVyVVQMbdi9w7Efh06PMWJ+I roMkHRdZPZajlV/9r4vQyI0z9XvpQZpjfElyZvQnrvK4iUJ766qnOD9FWlpZ3jaB /MhUT0OjugxMy6Tjte4aNgdMApFSCnYaFxGjgJRlBRj45Chi3kjAWX1/dWT9IvBQ HR+PCpXsfYNab7mP/6NhpF16FgEV/i2RyRnzDErzy5cKat3cP9wPq+WqEY1tYGpC OzaANU1dAACqddIWAtCd2cSYR0+kjCodRsZA3KxpUm0Hh2wl/dGab8EJkWwsRDnK /dG1SN6Y5qKexVskG6ObDvQR2/3KEiUkQq7edyKd501pav6uS6SVIAwbVF8/hodA 8c5spbu0TCbD/PivtStj2tsBKyrcW/oCmjd7A6r2iYy0jj+Ovkk= =P2Fu -----END PGP SIGNATURE----- --tEcC2NYhXAQEnuLjjafYoANri1R361fcG-- From nobody Wed Jul 4 06:08:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8562F130E7F for ; Wed, 4 Jul 2018 06:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nr6AUu0hVGPE for ; Wed, 4 Jul 2018 06:08:01 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021DB130E37 for ; Wed, 4 Jul 2018 06:07:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 4A37754861; Wed, 4 Jul 2018 16:07:58 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id m9zkpQJFH-7T; Wed, 4 Jul 2018 16:07:57 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 9A56B72; Wed, 4 Jul 2018 16:07:55 +0300 (EEST) Date: Wed, 4 Jul 2018 16:06:27 +0300 From: Ilari Liusvaara To: Hubert Kario Cc: tls@ietf.org Message-ID: <20180704130627.GA26089@LK-Perkele-VII> References: <1857183.8Fq0dhFQ1N@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1857183.8Fq0dhFQ1N@pintsize.usersys.redhat.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] [PSA] 0-RTT tolerance is mandatory X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 13:08:04 -0000 On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote: > All the implementations I deal with in my day-to-day work fail to handle the > 0-RTT client hello correctly when the 0-RTT support is not enabled on the > server. > > I.e. they ignore the MUST clause from > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that the > server can handle an early_data extension (and following encrypted data) in > only one of three ways, neither which allows for unconditional connection > abort. > > This also runs afoul the recommendation from https://tools.ietf.org/html/ > draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility. OTOH, such servers probably do not send out tickets allowing 0-RTT, so any client attempting 0-RTT with such server is very broken. -Ilari From nobody Wed Jul 4 06:10:12 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C69130E7F for ; Wed, 4 Jul 2018 06:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYeNX6Oa5XXz for ; Wed, 4 Jul 2018 06:10:07 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E7831277D2 for ; Wed, 4 Jul 2018 06:10:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 3AC2047C9D; Wed, 4 Jul 2018 16:10:05 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id YKQc6y-oGwXF; Wed, 4 Jul 2018 16:10:05 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id AB11072; Wed, 4 Jul 2018 16:10:02 +0300 (EEST) Date: Wed, 4 Jul 2018 16:08:34 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "" Message-ID: <20180704130834.GB26089@LK-Perkele-VII> References: <20180704044844.GB10665@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 13:10:10 -0000 On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote: > On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara > wrote: > > > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:= > > > I am working on an implementation for NSS/Firefox and I know some > > > others are working on their own implementations, so hopefully we can > > > do some interop in Montreal. > > > > > > This is at a pretty early stage, so comments, questions, defect > > > reports welcome. > > > > One thing I noticed: First there is this in evaluation: > > > > 7.2.4. Do not stick out > > > > By sending SNI and ESNI values (with illegitimate digests), or by > > sending legitimate ESNI values for and "fake" SNI values, clients do > > not display clear signals of ESNI intent to passive eavesdroppers. > > > > Is that suggesting to send fake ESNI values? If so, there is this in > > endpoint behavior: > > > > No, you would not send fake ESNI values. The idea here is that there is a > group of IPs (associated with a big provider, then all ESNI-supporting > clients will send ESNI to it. So the provider will stick out, but the use > of site X versus site Y on the provider will not stick out. And the > provider's IPs are reasonably well known through other mechanisms, so this > doesn't tell you much. Of course, this does not help big sites that aren't > using shared infrastructure (e.g., Facebook), but I don't know how to do > that. What does "with illegitimate digests" mean then? -Ilari From nobody Wed Jul 4 06:27:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAD7130E96 for ; Wed, 4 Jul 2018 06:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MFndzhfAReVB for ; Wed, 4 Jul 2018 06:27:16 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4E05130E65 for ; Wed, 4 Jul 2018 06:27:15 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0A1B5402242D; Wed, 4 Jul 2018 13:27:15 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8ADCA2156880; Wed, 4 Jul 2018 13:27:14 +0000 (UTC) From: Hubert Kario To: Ilari Liusvaara Cc: tls@ietf.org Date: Wed, 04 Jul 2018 15:27:08 +0200 Message-ID: <2034146.0jKBJLNyPE@pintsize.usersys.redhat.com> In-Reply-To: <20180704130627.GA26089@LK-Perkele-VII> References: <1857183.8Fq0dhFQ1N@pintsize.usersys.redhat.com> <20180704130627.GA26089@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1570771.YRYpNYo2HO"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 04 Jul 2018 13:27:15 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Wed, 04 Jul 2018 13:27:15 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] [PSA] 0-RTT tolerance is mandatory X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 13:27:19 -0000 --nextPart1570771.YRYpNYo2HO Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote: > On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote: > > All the implementations I deal with in my day-to-day work fail to handle > > the 0-RTT client hello correctly when the 0-RTT support is not enabled = on > > the server. > >=20 > > I.e. they ignore the MUST clause from > > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that > > the server can handle an early_data extension (and following encrypted > > data) in only one of three ways, neither which allows for unconditional > > connection abort. > >=20 > > This also runs afoul the recommendation from https://tools.ietf.org/htm= l/ > > draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility. >=20 > OTOH, such servers probably do not send out tickets allowing 0-RTT, so > any client attempting 0-RTT with such server is very broken. please read Section D.3, it is spelled out in detail there why that's not t= he=20 case the short of it: the client has no way of knowing if it is connecting to th= e=20 same server/instance/process it received the ticket from =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1570771.YRYpNYo2HO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAls8yywACgkQkqjRuAHS 9fX9MhAAnog7oNpfskKhR89eBVK3yq42pLt+9kMD6a01ZAlPf6kiawLQvLFXayHe NvZNjI4wOGnMzL4b5gQ0qplZ3d+2f//0i/LeQbPdpiBWNJFGosfxKEqr7GX6kAN1 13HITQy8SNJeiMdt2GgG5RmSyhpPGCWoOGPDVw1/kcikP8AnYqRBLrpkbQUV5F0u HVib8YAteALXqQX+EfleZIL2hRsQJ0nhlnEy9Y2N9Ue5XJqX5nLsj57OBlbYdjcY sRGwW3EmpG8d3mXCqxNAZEiT5GC+8kS7qWfmzn7pupQXKqpBJ5nK8bs2VfIC4Wvd FtNQEfa+LibWph3/xsk31Qa+uihE8/Y/eSolbMfDE+mt7ewpw93OF1EXBDQ0vGeo CevNUE9i9MzcD/x8SyAAiddKPtKWx0Q/3FDYuHe4b75qU15Vafij99bH0eJ+zE6e O098uZU2O8ebJ0g4mskKUYOEm//VWaNazYVI16sgUp6iyBVkaBf4URNh7iEyZ2uX SJDWSkZD4xkSKJYAYcOy9Yje+lSZzLz2oyEXghjBKS+gXvwi9Rzz+jVxHqFbVC32 VMtLWZEm2DhK3UEydvyrUFZjgNMg8FIVG29ZEqIQEH6RyRbbM9kYu+/ytktRM4x1 4lUguG12qcGkjJyhGe1MlA1SVwSdjNwpgHp+tZEAHm8XC6eRlmc= =mitu -----END PGP SIGNATURE----- --nextPart1570771.YRYpNYo2HO-- From nobody Wed Jul 4 06:36:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D33C6130F58 for ; Wed, 4 Jul 2018 06:36:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Op9jnsdHUS53 for ; Wed, 4 Jul 2018 06:36:21 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E22C130F49 for ; Wed, 4 Jul 2018 06:36:21 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DE34177890; Wed, 4 Jul 2018 13:36:20 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 6064C2166BA9; Wed, 4 Jul 2018 13:36:20 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: "" Date: Wed, 04 Jul 2018 15:36:19 +0200 Message-ID: <10346670.25GZR1XrEq@pintsize.usersys.redhat.com> In-Reply-To: References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3755769.mzyD5SKM1q"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 04 Jul 2018 13:36:20 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Wed, 04 Jul 2018 13:36:20 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Malformed Finished handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 13:36:25 -0000 --nextPart3755769.mzyD5SKM1q Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote: > I think it's a close call, because the length is sort of external to the > language. which language? the decode_error alert description literally says "length o= f=20 the message was incorrect." > That's why, for instance, NSS sends "illegal_parameter". So, > absent specific text about this value, I think this is something we can > leave to the implementations. but the text is explicit, if a message continues past message boundary, the= =20 correct response is decode_error. Decode_error is also consistent with the = way=20 above-expected length Client Hello MUST be handled. Just because the description of the message uses a single opaque array does= n't=20 make this message syntactically any different from other Handshake protocol= =20 message. if the interpretation of "I know this _message_ _length_ is wrong because o= f=20 some other values I negotiated before, so I'll send illegal_parameter" was= =20 correct, then overflow_error, decrypt_error and probably few others would a= lso=20 need to be replaced with illegal_parameter... =20 > -Ekr >=20 > On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario wrote: > > Despite this, is it correct to terminate a connection with > > "illegal_parameter" > > upon receiving a Finished handshake message with a 100 byte payload? or= a > > 20 > > byte payload? My opinion is that it is not, "decode_error" is more > > specific so > > it should be used instead. > >=20 > >=20 > > Specification says the following on the matter: > >=20 > > The draft 28 specifies the Finished message as having following structu= re: > > struct { > > =20 > > opaque verify_data[Hash.length]; > > =20 > > } Finished; > >=20 > > At multiple places it also talks about handling messages that have sizes > > that > > don't match their structure as requiring termination of connection with > > "decode_error". > >=20 > > The generic situation in Section 6: > > Peers which receive a message which > > cannot be parsed according to the syntax (e.g., have a length > > extending beyond the message boundary or contain an out-of-range > > length) MUST terminate the connection with a "decode_error" alert. > >=20 > > as description of the alert in Section 6.2: > > decode_error A message could not be decoded because some field was > > =20 > > out of the specified range or the length of the message was > > incorrect. This alert is used for errors where the message does > > not conform to the formal protocol syntax. > >=20 > > In specific about Client Hello, in Section 4.1.2: > > If negotiating a version of TLS prior to 1.3, a server MUST check > > that the message either contains no data after > > legacy_compression_methods or that it contains a valid extensions > > block with no data following. If not, then it MUST abort the > > handshake with a "decode_error" alert. > >=20 > > And specific handling of Certificate from server in Section 4.4.2.4: > > If the server supplies an empty Certificate message, the client MUST > > abort the handshake with a "decode_error" alert. > >=20 > > Description of "illegal_parameter" in Section 6: > > Peers which receive a message which is syntactically correct but > > semantically invalid (e.g., a DHE share of p - 1, or an invalid enum) > > MUST terminate the connection with an "illegal_parameter" alert. > >=20 > > Alert description in Section 6.2: > > illegal_parameter A field in the handshake was incorrect or > > =20 > > inconsistent with other fields. This alert is used for errors > > which conform to the formal protocol syntax but are otherwise > > incorrect. > >=20 > > (it's also mentioned in over a dozen places in the draft) > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart3755769.mzyD5SKM1q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAls8zVMACgkQkqjRuAHS 9fXFBA/+M640cJblqTsNfKCItiGj2qoDe71bapSsoNjqIlCR4pAW5avnA4Ntl65V NvK4Y+CLDpglm8JNSh39uhit99r1PMpQlG++warD2CXoxmiT28FRE6+XB2NqG+Nb 84Vm/Kqz4adNaiJk5hw9h5QbFr8dT2N7sMuLwzk6ShCBJP09oJTV05eDuPqcvT6+ p76L09uy4r9ly1a9yMWDsrxqVoJzsRfAlI2tt3GmGxQym/gEe9ogQq9feYen5YDB fnuFBjzl0Xv3EdAATGQumKpGC0LoOv4pl+DoIh8NlbVD7b2EaS+IgS8tzNjq2eqg WxibjMQRSeDsIjkrZ55UVjSW99PQRfFtQ5QpLDjsSk4K9nVlxnND6kCjseWr1Zc7 qPPd/7EYGWFseo0H3YSXkhUUk57WrO0mdr0mSYtnEHVCBcCCMA+lZytjf0AFlpLP bN+CcWZNQXFaSIhgrneQ60gXT+2tH66kmUzNawZNbL3pP87OWpXU/fLmuwKMsgEs ae1YtfHOoHa3GaQ6R1ewldrZEbOaAVhv2X1oag4uQJpVE2jePoFs4IRPsinsofov +ejSuHVFdSmwjcU0ilZ++uedwGQJ+yEzsgJ4SvbtkmAwg6OMdH2EZLx5lPqTisE0 GeJzl8oPnBU2zD+UB+ynyHV61TmZh2oPONoPLn/1/ybmtpw3aSI= =lC8I -----END PGP SIGNATURE----- --nextPart3755769.mzyD5SKM1q-- From nobody Wed Jul 4 06:46:35 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C74C5130FB7 for ; Wed, 4 Jul 2018 06:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gHGCFG67x7P for ; Wed, 4 Jul 2018 06:46:11 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FF84130FCE for ; Wed, 4 Jul 2018 06:46:07 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w64DhLMo004396; Wed, 4 Jul 2018 14:46:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=cio7n2Qbh4Vk3WK5UjXoLrMe1FZv+KUlBwG3ke+uSng=; b=CMbOqLFCA/JO99IL52nBUczGBX/jaT68nW9n2Ul5up3F7QRJebQm9IXQws/jqzPo6nET S09B7S1AoddR2DHYMs9TWfxiB0R11vQRFXc/X73DilvFngNz38CE+g0cATUHZ+T3xODf ekZGPaTyfzbsW+BsKX9dHM8gVAsFssDwR9YwX5ARXQsnXv/l0UDv+xBqOc7/IMOplMHC Riuza9a1/H71YBPMA/v/ClV3TslOC7ExC1BX7AuvnR0zwbsXbax4WoX9+m1E/3M9XbRK 2cu/KYKJ6pFFFQsa1deQO1pxxpjPp1l668SvRkuXTDK+xsCR/n8QsNg47e2HlhUIFPmK Iw== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2k0vcsrctm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Jul 2018 14:46:06 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w64DZH1m023039; Wed, 4 Jul 2018 09:46:06 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jx57bdjne-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Jul 2018 09:46:05 -0400 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.1365.1; Wed, 4 Jul 2018 08:46:05 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Wed, 4 Jul 2018 08:46:05 -0500 From: "Salz, Rich" To: Hubert Kario , Eric Rescorla CC: "" Thread-Topic: [TLS] Malformed Finished handling Thread-Index: AQHUE30KwjXcmqvy7UW082bZ8x4YGqR/WsEAgAAKEYD//7+rAA== Date: Wed, 4 Jul 2018 13:46:04 +0000 Message-ID: <76911F76-2FF1-4EAB-8BEA-784B805184F2@akamai.com> References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> <10346670.25GZR1XrEq@pintsize.usersys.redhat.com> In-Reply-To: <10346670.25GZR1XrEq@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.110] Content-Type: text/plain; charset="utf-8" Content-ID: <4CA68B3298825A4AA2EA11C6958CBC72@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-04_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=838 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807040157 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-04_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=755 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807040158 Archived-At: Subject: Re: [TLS] Malformed Finished handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 13:46:33 -0000 PiAgICBpZiB0aGUgaW50ZXJwcmV0YXRpb24gb2YgIkkga25vdyB0aGlzIF9tZXNzYWdlXyBfbGVu Z3RoXyBpcyB3cm9uZyBiZWNhdXNlIG9mIA0KICAgIHNvbWUgb3RoZXIgdmFsdWVzIEkgbmVnb3Rp YXRlZCBiZWZvcmUsIHNvIEknbGwgc2VuZCBpbGxlZ2FsX3BhcmFtZXRlciIgd2FzIA0KICAgIGNv cnJlY3QsIHRoZW4gb3ZlcmZsb3dfZXJyb3IsIGRlY3J5cHRfZXJyb3IgYW5kIHByb2JhYmx5IGZl dyBvdGhlcnMgd291bGQgYWxzbyANCiAgICBuZWVkIHRvIGJlIHJlcGxhY2VkIHdpdGggaWxsZWdh bF9wYXJhbWV0ZXIuLi4NCiAgDQpJIHRoaW5rIHRoZSByaWdvcm91c25lc3Mgb2YgZXJyb3IgY29k ZXMgaXMgbm90IGF0IHRoZSBzYW1lIGxldmVsIGFzIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudC4g IEknbSBmaW5lIHdpdGggdGhhdC4gIEkgY2FuIHVuZGVyc3RhbmQgd2h5IHBlb3BsZSBkZXZlbG9w aW5nIHRlc3Qgc3VpdGVzIGFyZSBmcnVzdHJhdGVkLiBUbyBtZSwgaXQncyBsaWtlIHBlb3BsZSBh cmd1aW5nIGFib3V0IHdoZXRoZXIgdGhlICJsaXN0IG9mIGVycm5vIHZhbHVlcyIgaW4gYSBzeXNj YWxsIG1hbnBhZ2UgbXVzdCBiZSBjb21wbGV0ZWx5IGNvbXByZWhlbnNpdmUgb3Igbm90LiAgT2xk LXRpbWVycyBtaWdodCByZW1lbWJlciB3aGVuIGRqYiB1c2VkIHRvIHJhaWwgYWdhaW5zdCB0aGUg ZmFjdCB0aGF0IGNsb3NlKDIpIGNvdWxkIHNldCBlcnJubyB0byBFTk9TUEFDRSB3aGVuIHVzaW5n IEFGUy4NCg0KVGhlIFdHIHNwYW5zIGEgd2lkZSB2YXJpZXR5IG9mIHZpZXdzIG9uIGVycm9ycyBh bmQgYWxlcnRzLiBTb21lIHdhbnQgdG8gaGF2ZSBvbmx5IG9uZSwgImJhZCBwYWNrZXQsIiBhbGVy dC4gU29tZSB3YW50IHRvIGFkZCBhIHRleHR1YWwgZXhwbGFuYXRpb24gb3B0aW9uLiAgV29vbGdh dGhlcmluZyBhc2lkZSwgSSB0aGluayB0aGUgZmlyc3Qgc2VudGVuY2UgSSB3cm90ZSBpcyAxMDAl IGFjY3VyYXRlLg0KDQoNCg0KDQo= From nobody Wed Jul 4 06:50:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764F8130F85 for ; Wed, 4 Jul 2018 06:49:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yHyep1jPtcs for ; Wed, 4 Jul 2018 06:49:57 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12BAE130F84 for ; Wed, 4 Jul 2018 06:49:57 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w64DlUfw017114; Wed, 4 Jul 2018 14:49:50 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=VMvZJ4Z/MThd54xSkCW8MBuIqgbNxFAk89a3uRfHvzQ=; b=EAeR7YBLZpvC71hqKpq4uV9j1rU1qgyZQYzjtN8UNtTaj76Am/0353g0OQcGMdCcn/2A C/P9jkpZ3qtA7auId8gUhIh1vZSiFjIkpcbkTuUmvkW0lboJpbolrfuvg6SfUftyXcAK NI7XaSdGB3A47xsosw6V+c8hqqA2bubCXg8VFB6wyfpj086n9m18ZevOsy7I7F+cSu5S tx4/olIbl0uVijAlBtKLn3NrbXbZA0uAFGKUYOiXj5qAY2eARCT8DMJi1QI8HqpjFA1R R4EHqZSxBMM9+AQ8EI5SdC5s7dYWc+b33S0A4EePquaVESXriDWugVN//6KmSo7o72Z5 fQ== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2jx2954557-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 04 Jul 2018 14:49:50 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w64DZHTx023046; Wed, 4 Jul 2018 09:49:49 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.32]) by prod-mail-ppoint3.akamai.com with ESMTP id 2jx57bdjxg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 04 Jul 2018 09:49:49 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 4 Jul 2018 06:49:48 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Wed, 4 Jul 2018 08:49:48 -0500 From: "Salz, Rich" To: Peter Gutmann , "" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE53fEGgXYKCP9EqF19k6tdX1YA== Date: Wed, 4 Jul 2018 13:49:48 +0000 Message-ID: <460E369B-E42D-4770-A713-8F564D2D5F72@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.110] Content-Type: text/plain; charset="utf-8" Content-ID: <22AA489FA7EDEB48A14B0707BBFE5583@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-04_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=777 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807040157 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-04_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=700 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807040159 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 13:49:59 -0000 PiAgICBUaGUgZm9sbG93aW5nIGlzIGFuIGF0dGVtcHQgdG8gY29uZGVuc2Ugc29tZSBvZmYtbGlz dCBkaXNjdXNzaW9ucyB3aXRoIFNDQURBDQogICAgZm9sa3MgYWJvdXQgdGhlIGJyb2tlbiBiZWhh dmlvdXIgb2Ygc29tZSBicm93c2VycyB3aGVuIGl0IGNvbWVzIHRvIGludGVyYWN0aW9uDQogIA0K DQpUaGFua3MgZm9yIGRvaW5nIHRoaXMuICBJdCdzIGFsd2F5cyB1c2VmdWwgdG8gZ2V0IHJlYWwt d29ybGQgdXNhZ2UgaW5mb3JtYXRpb24sIGVzcGVjaWFsbHkgaW4gdGhlIG5vbi1XZWIgd29ybGQu DQoNCg0K From nobody Wed Jul 4 08:16:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB586130E10 for ; Wed, 4 Jul 2018 08:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97EysSvegwUX for ; Wed, 4 Jul 2018 08:15:59 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBB61130E7C for ; Wed, 4 Jul 2018 08:15:58 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id o2-v6so3005028qkc.13 for ; Wed, 04 Jul 2018 08:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lvcQJQUaX1WlPrmTjPH7IEtashdXUwMp1Oqku7v55LA=; b=ZYO+Mg5FCYVUBG1XkPV4cvmVa9WCX8E6IYH7B626cOSROpjC/VjShiHaN27si0bNie 4FNcG5QQxM7B8L0FOUgv6Op5w5J8M5u4b8jQexmaZGFWN5S2GJwiqaM6+9sQ7H23SmwQ d3WaQ75KSJEBc9By38BLck1mP07+gvgjwdbpI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lvcQJQUaX1WlPrmTjPH7IEtashdXUwMp1Oqku7v55LA=; b=P+TmnyC5P5B4AHgLHWa4mwvzU79SVId7IVwtjmk05tP1JoE6IHfg/PzJPEqdDyuLzK +UprGhYK59HWAiaLiHQsvgKPj7ZunlF2oSsPcAodUB3b0B3cyMLHrwAFQtCY+pGaM8YP 1CYd7zQAoYOdq8QxGJisdnsmUa/m8UpCgB6OflKnToRLkoPsVW2QmXyugcEHLuf09e0m HjVQrbU4+YheKA8a4ynsvHyk6iaQCGRrHtzsOgPSHVB9fduMhha3GpxY4qqBhG1F+MGy evVwXR4uKX4ixzQIauSqnc+fn1odzhk5JinGt25X3jwxMtslYwE7bVXhewRRlIjlXaZm 3nLQ== X-Gm-Message-State: APt69E29FEzEKfhCCd54Th7yGGfnoCa8cKssWIatlixU1wzNaDCUPgna gD9flv4iwQJlqiwNJipZo4JuLCCo3vg2veaK9vHk X-Google-Smtp-Source: AAOMgpccJpAlyA7Z5jdJMl4v3iMeozWi4gDyxtDs9kjc4Cozmsc0wU+dQo2Z4z9hGuYEPHVlEtjMN6GT0g5CiDv/KUM= X-Received: by 2002:a37:7d87:: with SMTP id y129-v6mr1930919qkc.232.1530717357589; Wed, 04 Jul 2018 08:15:57 -0700 (PDT) MIME-Version: 1.0 References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> In-Reply-To: From: David Benjamin Date: Wed, 4 Jul 2018 11:15:45 -0400 Message-ID: To: Nikos Mavrogiannopoulos Cc: Ilari Liusvaara , Peter Gutmann , "" Content-Type: multipart/alternative; boundary="0000000000005a679e05702de887" Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 15:16:02 -0000 --0000000000005a679e05702de887 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos wrote: > On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote: > > On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote: > > > Ilari Liusvaara writes: > > > > > > > More serious problem is servers returning too small modulus due > > > > lack of > > > > negotiation. Which was the reason why Chrome disabled DHE. > > > > > > Why not reject the handshake if the modulus is too small, rather > > > than > > > disabling all DHE suites on the off chance that the server returns > > > a value you > > > don't like? > > > > Chrome initially did that. It caused quite a lot of bad feedback from > > owners of various bad embedded stuff. The thread on relevant forums > > was > > quite something. Hundreds of messages blaming Google for breaking > > stuff. > > We had similar experience when we required a minimum of 2048-bit > modulus for all TLS connections in Fedora 28 beta irrespective of back- > end lib. It broke connections to VPN servers and web internal web sites > and we had to revert the change. The DHE ciphersuites under TLS1.2 seem > doomed and rfc7919 couldn't save them. > Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we encountered a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum. See here for details: https://groups.google.com/a/chromium.org/d/msg/blink-dev/ShRaCsYx4lk/46rD81AsBwAJ I should add to that link that the "draft specification which fixes the negotiation problems", now rfc7919, did not fix the problem. This was pointed out here, but never incorporated to the document: https://www.ietf.org/mail-archive/web/tls/current/msg18697.html To the original email, it seems the second and third scenarios are identical. Configuring ECDHE+ECDSA ciphers is a no-op if using an RSA server key. The third and fourth scenarios are indeed unsurprising for a browser that doesn't support DHE. You should instruct these folks to configure ECDHE+RSA ciphers if they have RSA keys. Particularly in the second scenario, it seems they're already implemented, just the server was incorrectly configured to use the wrong ones. DHE at acceptable sizes is quite slow anyway, so their servers may well appreciate the speed boost. (Indeed, I often see DHE disabled in server deployments as otherwise the poor servers would melt.) --0000000000005a679e05702de887 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 4,= 2018 at 4:41 AM Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote:
> On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote:
> > Ilari Liusvaara <ilariliusvaara@welho.com> writes:
> >
> > > More serious problem is servers returning too small modulus = due
> > > lack of
> > > negotiation. Which was the reason why Chrome disabled DHE. > >
> > Why not reject the handshake if the modulus is too small, rather<= br> > > than
> > disabling all DHE suites on the off chance that the server return= s
> > a value you
> > don't like?
>
> Chrome initially did that. It caused quite a lot of bad feedback from<= br> > owners of various bad embedded stuff. The thread on relevant forums > was
> quite something. Hundreds of messages blaming Google for breaking
> stuff.

We had similar experience when we required a minimum of 2048-bit
modulus for all TLS connections in Fedora 28 beta irrespective of back-
end lib. It broke connections to VPN servers and web internal web sites
and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
doomed and rfc7919 couldn't save them.

<= div>Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere= 1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we = encountered a lot of this.) 2048-bit was completely hopeless. At the time o= f removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum. = See here for details:

I should add to that link that the "draft specificatio= n which fixes the negotiation problems", now rfc7919, did not fix the = problem. This was pointed out here, but never incorporated to the document:=

To the original email, it seems the second an= d third scenarios are identical. Configuring ECDHE+ECDSA ciphers is a no-op= if using an RSA server key. The third and fourth scenarios are indeed unsu= rprising for a browser that doesn't support DHE. You should instruct th= ese folks to configure ECDHE+RSA ciphers if they have RSA keys. Particularl= y in the second scenario, it seems they're already implemented, just th= e server was incorrectly configured to use the wrong ones.

DHE at acceptable sizes is quite slow anyway, so their servers may= well appreciate the speed boost. (Indeed, I often see DHE disabled in serv= er deployments as otherwise the poor servers would melt.)
--0000000000005a679e05702de887-- From nobody Wed Jul 4 08:37:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13828130E52 for ; Wed, 4 Jul 2018 08:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vo60G-8ut2ek for ; Wed, 4 Jul 2018 08:37:37 -0700 (PDT) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 89E8F127AC2 for ; Wed, 4 Jul 2018 08:37:37 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id v83-v6so8540418itc.3 for ; Wed, 04 Jul 2018 08:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oLprrGRQSLFuee466IZ3naEpUFzsRUZ/Qg1ZWPTu8H4=; b=Z+k1qFLy2BZ8DCuwRFHxEay7ogYk+muAop6bWhyZuQY6adD64efidIPYoZd2avsIXZ qOC0igBWJfxWZQE79q3DIkzUpG8zImBTtvmqnklcGNiE+hZ+y8p5TdStG+yScl4GNRGq LzGaHrhSEYon1i35xCNDzFCNy/xpDzEGcuJPB8/N9yi9dhoyo6b4NLf9jBw/gVSht5wH JbYVOXda1kRsclZkV/dYsiIcRfK5/uOP7Tftcfy0l9yg5rvNSCoFeoe/xdqKvnPihjIM FTo21Gx+iqpEISI/2/mBAhLgn0kbKUAfO8NtFXw2txsh/zZNbP8DDMGhIyBaQyWtAwm+ i8cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oLprrGRQSLFuee466IZ3naEpUFzsRUZ/Qg1ZWPTu8H4=; b=PtYgbvu8Rlxl3UPIezAhB+Qq8KO5bHB0CcvliB2C58E63TwUhhwi697S5pxpPJhDdo Mv/mDz2mZ4c6EX+rtAw6RLKwybNYn/aACXJZRecVptKVqMdbRA847FMXklS/2uzjIiwX J/9b8A6ac8+D1UKsVFcXkZ60kGAjjOPg/Y4eO15ITWgfKu21YGAFIflb7Ha0jkTQ0efH aqQBwFD8bN0QSV77HJzruXWfoqayBgQBnYfsLz0eMjGblsWiOWdekBL9fUQnDRkGjT5B ct10bjcBiVk1Q7CSCcvEqCxr0I9ngdhhw3FhwV+Nw65jj2eqemHrhYAoIDtM4roFI49n JTjw== X-Gm-Message-State: APt69E1/R0z8uXHluyKeMqm5GgrCOcEljBDp775SSUe41Mlsuxpi6W+N 6XTVs3Ca4OMsYvubvXuG83twWGid7/MlqGherg7gt/E/uJY= X-Google-Smtp-Source: AAOMgpfy29IQv2yaqaqWGHsrjD72vpwTnqfKkYeqqclV+Ras0eH6IECY8W4WoMTcc7J52stqTYHsdP1YebdmDIjswKE= X-Received: by 2002:a24:c903:: with SMTP id h3-v6mr2175217itg.87.1530718656438; Wed, 04 Jul 2018 08:37:36 -0700 (PDT) MIME-Version: 1.0 References: <20180703222414.17ee820c@computer.lan> In-Reply-To: From: Ben Schwartz Date: Wed, 4 Jul 2018 11:37:25 -0400 Message-ID: To: bsniffen=40akamai.com@dmarc.ietf.org Cc: hanno@hboeck.de, "" Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000ce52c905702e3525" Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 15:37:42 -0000 --000000000000ce52c905702e3525 Content-Type: multipart/alternative; boundary="000000000000c53e0505702e35fc" --000000000000c53e0505702e35fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 3, 2018 at 5:19 PM Brian Sniffen wrote: > Hanno B=C3=B6ck writes: > > > So-called "Enterprise" infrastructure has delayed the work of this grou= p > > for at least a year. Noone of the people creating that mess has reached > > out to this group to explain why they constantly break TLS - let alone > > apologize for it. > > > > I believe there's a large overlap of the actors breaking TLS with the > > actors who are worried about things like SNI encryption. I'm not sure I > > see any reason not to consider these actors as anything but opposed to > > the work of this group. > > Whoah! I've been involved for years specifically to ask for care about > encrypted SNI. I don't know whether I break TLS; maybe opinions vary. > But my concerns have been specific: > > First, at the engineering level, a requirement that servers do expensive > cryptographic work in response to a first packet *and* an inability to > charge that work to a user or application is a big problem. It makes it > too hard for users or applications to share a server, or leads to levels > of address waste expensive even with IPv6. > > If we're going to have 0RTT and 1RTT and TCP Fast Open and ECDHE... then > Encrypted SNI is a hard engineering problem! > > Second, at the architectural level, a serious question about whether > this actually helps anybody, and if so whom? I think the case of the > Amnesty International worker in an oppressive dictatorship is almost > certainly *not* helped by this work---see my questions about how many > bits of security this provides against an adaptive adversary from this > morning---and would like some clarity that this is about inhibiting the > ISPs, from cafes through enterprises up to Comcast-TWC, from monkeying > with user sessions. > > > My concerns at the engineering level have been welcomed, recognized, > validated, and addressed. Not always exactly the way I'd like, but > absolutely addressed in a way that's appropriate and sincere. I saw the > same with requests to re-insert RSA Kx late last year. The PATIENT > folks have gotten a fair hearing. > > My architectural concerns have been heard, somewhat less eagerly. Some > participants, including our colleagues who are vendors to enterprises > and folks like Ben Schwartz, have been clear that they will not bring > all their motivations and evidence to the table. It's always exciting to see your name in print. Is there something I can do to help here? I honestly have no idea who "folks like me" are, or what we did that gave you this impression. > I significantly > discount their arguments and expect others to do the same---but not to > zero. This is pretty disheartening. Always happy to discuss in person. I'll be at the meeting in Montreal. It means we need to check their work as we go, or actually trust > them as people, but it *can't* be harder than keeping NSA/IA people on > CFRG! > > Anyway, I think the PATIENT folks concerns about the engineering of TLS > 1.3 have been heard, have been taken seriously, and have been > addressed---same as mine or yours. What I've seen of the architectural > concerns leading to network-centric management and "tap" devices come > down to claims about changes in architecture being too expensive, > middleboxes being too expensive, changes to applications being too > expensive, and general citation of an architecture only a few years old > as immutable tradition. Those claims have also been heard, plenty of > folks have respectfully and diligently combed through them for evidence, > and we've moved on. > > I bet that's frustrating and frightening for the folks writing from a > world where those claims aren't faith-based---they're obvious. They > don't need citation any more than "China is a country"[1] needs > citation. Nonetheless, engineering conversations based on > data-supported arguments continue to be welcome. > > -Brian > > > Footnotes: > [1] > https://www.cia.gov/library/publications/the-world-factbook/geos/ch.html > but see also > https://www.cia.gov/library/publications/the-world-factbook/geos/tw.html > > -- > Brian Sniffen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000c53e0505702e35fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3,= 2018 at 5:19 PM Brian Sniffen <bsniffen=3D40akamai.com@dmarc.ietf.org> wro= te:
Hanno B=C3=B6ck <hanno@hboeck.de> writes:
> So-called "Enterprise" infrastructure has delayed the work o= f this group
> for at least a year. Noone of the people creating that mess has reache= d
> out to this group to explain why they constantly break TLS - let alone=
> apologize for it.
>
> I believe there's a large overlap of the actors breaking TLS with = the
> actors who are worried about things like SNI encryption. I'm not s= ure I
> see any reason not to consider these actors as anything but opposed to=
> the work of this group.

Whoah!=C2=A0 I've been involved for years specifically to ask for care = about
encrypted SNI.=C2=A0 I don't know whether I break TLS; maybe opinions v= ary.
But my concerns have been specific:

First, at the engineering level, a requirement that servers do expensive cryptographic work in response to a first packet *and* an inability to
charge that work to a user or application is a big problem.=C2=A0 It makes = it
too hard for users or applications to share a server, or leads to levels of address waste expensive even with IPv6.

If we're going to have 0RTT and 1RTT and TCP Fast Open and ECDHE... the= n
Encrypted SNI is a hard engineering problem!

Second, at the architectural level, a serious question about whether
this actually helps anybody, and if so whom?=C2=A0 I think the case of the<= br> Amnesty International worker in an oppressive dictatorship is almost
certainly *not* helped by this work---see my questions about how many
bits of security this provides against an adaptive adversary from this
morning---and would like some clarity that this is about inhibiting the
ISPs, from cafes through enterprises up to Comcast-TWC, from monkeying
with user sessions.=C2=A0


My concerns at the engineering level have been welcomed, recognized,
validated, and addressed.=C2=A0 Not always exactly the way I'd like, bu= t
absolutely addressed in a way that's appropriate and sincere.=C2=A0 I s= aw the
same with requests to re-insert RSA Kx late last year.=C2=A0 The PATIENT folks have gotten a fair hearing.

My architectural concerns have been heard, somewhat less eagerly.=C2=A0 Som= e
participants, including our colleagues who are vendors to enterprises
and folks like Ben Schwartz, have been clear that they will not bring
all their motivations and evidence to the table.

It's always exciting to see your name in print.=C2=A0 Is there so= mething I can do to help here?=C2=A0 I honestly have no idea who "folk= s like me" are, or what we did that gave you this impression.
=C2=A0
I significantly
discount their arguments and expect others to do the same---but not to
zero.

This is pretty disheartening.

Always happy to discuss in person.=C2=A0 I'll be at the meeting= in Montreal.

It means we nee= d to check their work as we go, or actually trust
them as people, but it *can't* be harder than keeping NSA/IA people on<= br> CFRG!

Anyway, I think the PATIENT folks concerns about the engineering of TLS
1.3 have been heard, have been taken seriously, and have been
addressed---same as mine or yours.=C2=A0 What I've seen of the architec= tural
concerns leading to network-centric management and "tap" devices = come
down to claims about changes in architecture being too expensive,
middleboxes being too expensive, changes to applications being too
expensive, and general citation of an architecture only a few years old
as immutable tradition.=C2=A0 Those claims have also been heard, plenty of<= br> folks have respectfully and diligently combed through them for evidence, and we've moved on.

I bet that's frustrating and frightening for the folks writing from a world where those claims aren't faith-based---they're obvious.=C2= =A0 They
don't need citation any more than "China is a country"[1] nee= ds
citation.=C2=A0 Nonetheless, engineering conversations based on
data-supported arguments continue to be welcome.

-Brian


Footnotes:
[1]=C2=A0 https://www.cia.go= v/library/publications/the-world-factbook/geos/ch.html
=C2=A0 =C2=A0 =C2=A0but see also https://www.cia.gov/library/publications/the-world-factbook/geos/tw.ht= ml

--
Brian Sniffen

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000c53e0505702e35fc-- --000000000000ce52c905702e3525 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMHPEBklWZfCvIVU8oMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE4MDUxNzA4MjIwNVoXDTE4MTEx MzA4MjIwNVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQDQRB850FBZJnK1k18RTKWAcnV8xzvvd+Eatm0/DGMYHYhqGriJ WRekNb6Te9Y/zCccceH4x4OjBzjaup2aBU/Lbeaj9I5AuCUQnn+xM+t6M+huTXv9pujltTAbaR/b IfiE9ilbhz6BrM09gtcDgGccpiyDw5np6PR8nn5dkbJ+1Hes0d9i5k0BkCQp1OQYDux0aAQKV0uq G43K/QIXth7qejm2JM1Gpzc2AKE9UJDlTHWVW7nmjdVf0JdzLbkZWHlQqpMU4cbaA/QBtWCddLOR YOVVmfL2G0kqi3I0DPR7IGxLHCRlfrVr9b1kRA+Wt5SkoiBsoqLZ7FGFNokuAwrfAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFPUT4TOHt/oKM2x0XyaENesy/GcRMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQCuK5XDeLIidLOebj/u 0+kt/1GjtDlRXEZNy6kLW2VPvzIQzpOFHz6Go02crZL1MkyvR1uWaZnGt6zRMIbNeEx0DKUMxitQ QsVU99JBOXhtipJ0CAR94SC9vPG6ecuVPzRM8rGyVCHhjwjQnuJ9pTsYTUYUDM+DCeCJRtDOrzGd RtcVP6W7prUn2qvDqC45qZEIEWdrLhDjdjPuWvgl0LkCKwxl9JRaUZePN8dDRRSA7X8sFr0FF8pn w83HwJizSB2EeQeSu/lvcvIBZzs0SwX+09qAvZYfiI+m2yuQfHSleDw0BBMROMB9S2yBFkP+2E3y BWurROrwi9IwxXqcQVLOMYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMHPEBklWZ fCvIVU8oMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBGMGYIuSJeRi+RCtEe1mXl NhJzMYDCh1uZqp6kKq/wQjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xODA3MDQxNTM3MzdaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAxb35KiRueeU2sp9i/HoQ8P3/MMjHBHp/EXYwDyn+ WklZbd9jm2Yk2/PwHCd0e/hnpKevI8sBiALpANDsZX2MXWgfnQw0QO0Lfm6SVsaAc+bBSPt4mX2Q wxJrP8uBMoFvDQyjbqDXD4FE+pHpN7uKvMPf36L14SOlNrHi/CJmLzUGmxrlsX76pQb+XfuJq3hp gxQF+SJEosjAzzryjs1V0aQSZmuk17oN5PmoKflhypy7btOjV0WD42LhIK9sUGXnl9M7W5OvR5rE MIsaPo3TNqWxB31pctCca/iQLYchdqI5h482G5oXI5tVhg2iNO+Ae/obSJjd1IgiwffHKjShJQ== --000000000000ce52c905702e3525-- From nobody Wed Jul 4 08:40:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BF5130E4F for ; Wed, 4 Jul 2018 08:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcN4geH5VuJU for ; Wed, 4 Jul 2018 08:40:27 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A73A4127AC2 for ; Wed, 4 Jul 2018 08:40:27 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id x10-v6so2210787ybl.10 for ; Wed, 04 Jul 2018 08:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xn/WB7w8U6PPE4eyjMqPnCKG0CJS1uqyaaT02qX45R8=; b=MV6uyhjqbAB/u0ACK5KrK3Z7AS40Vezmp5aEL+thpxhme2UoOCVyZbZL2DKwFfm0oK Bt4ULbMSZnXT9Y2fD2Mf5WN8tcw4Htt2s10Tp4pia/r3Ie/5LSmiiFMbS9ZJ7IjJHlxz A3AXHhMEHJIYgMA0OvVqab+Tx22DJhINmsF7s42cOKzNn9z9Ql2tBfAR4qYQetxN0aKI fhwvwV6Ti8kHW94e9/eyVXn2P9J1s/K5uhL44hWpQnWs/YNZ4nGMR/JZrLHfQaPbxv2i /SIrvPps+DqJVqUUX4D8gki5AoGHXuC6/HoiorG8NGTYVyFCEsJBFHW8am2Jz/wsmzHl kzbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xn/WB7w8U6PPE4eyjMqPnCKG0CJS1uqyaaT02qX45R8=; b=uQLiWi5oHGrZt7gDkP3gPJ2LY9VZey/wJYvpfFIMLYratkEwOEcVXzFbnd+pLbdyRd GmMFzxBgW7LejXo0SjhvM0nxvwF0+wyF+BbnPJnigqqkaFK2Zj3/LoDySWZVtxGOK4NE k/cszbbtQ3uFelSrVhva0qNOomyYaEt2rKvkZKSf2c2+hZkR4WTATenM1ZVJkJwJihNY iL+Jsq8kfEeO/frwAf6CCt5g24ovgZBvY79/07o8sjN5+ADS/IMwS695WrRehxdPONZO FB2pBgetNpR+MIcS1TpSfofmMV6gG/TOA0Iu8eQsmPYcPs2xtzKnxLGDFJiG22fabAnn k6Mg== X-Gm-Message-State: APt69E2y9iYUpp8ib30O5KeeuPTnOKE1JNX+u8VPE7Jb3qFS12iZkPWR F3nRmg4c3Y1eYUBn/g8KcOIDAguPlkP/x1xAixmMVA== X-Google-Smtp-Source: AAOMgpe1gzmxHob5h3Mmkz7fBI450h5tUjNW/Bs3u+iLIa8VVqSSu7QBL+cF5QahPEh9Trj+rlXJeAU5SaJHqvx1Wdc= X-Received: by 2002:a25:2d44:: with SMTP id s4-v6mr1282017ybe.284.1530718826857; Wed, 04 Jul 2018 08:40:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:241:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 08:40:26 -0700 (PDT) In-Reply-To: References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 4 Jul 2018 08:40:26 -0700 Message-ID: To: David Benjamin Cc: Nikos Mavrogiannopoulos , "" Content-Type: multipart/alternative; boundary="000000000000ed1cd405702e3f69" Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 15:40:31 -0000 --000000000000ed1cd405702e3f69 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 8:15 AM, David Benjamin wrote: > > Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere > 1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we > encountered a lot of this.) 2048-bit was completely hopeless. At the time > of removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum. > See here for details: > https://groups.google.com/a/chromium.org/d/msg/blink-dev/ > ShRaCsYx4lk/46rD81AsBwAJ > >From the server side: we found that enforcing a 2048-bit size was unworkable, it breaks clients that will negotiate DHE but then fail when the exchange happens, including versions of Java. Because the breakage happens post-handshake, there was little recourse to fix it. We did look at fingerprinting the clients and trying to use a different size for those, but even that led to too high an error rate. So we removed DHE in general and use ECDHE for FS. -- Colm --000000000000ed1cd405702e3f69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 8:15 AM, David Benjamin <davidben@chromium.= org> wrote:
Indeed. The bad feedback was not even at a 20= 48-bit minimum, but a mere 1024-bit minimum. (Chrome enabled far more DHE c= iphers than others, so we encountered a lot of this.) 2048-bit was complete= ly hopeless. At the time of removal, 95% of DHE negotiations made by Chrome= used a 1024-bit minimum. See here for details:

From the server side: we found that enforcing a 2048-bit si= ze was unworkable, it breaks clients that will negotiate DHE but then fail = when the exchange happens, including versions of Java. Because the breakage= happens post-handshake, there was little recourse to fix it. We did look a= t fingerprinting the clients and trying to use a different size for those, = but even that led to too high an error rate. So we removed DHE in general a= nd use ECDHE for FS.=C2=A0

--
Colm
--000000000000ed1cd405702e3f69-- From nobody Wed Jul 4 08:54:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF4C8130E19 for ; Wed, 4 Jul 2018 08:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3hJCL6reIoe for ; Wed, 4 Jul 2018 08:54:45 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7033712785F for ; Wed, 4 Jul 2018 08:54:45 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id d22-v6so3062770qkc.8 for ; Wed, 04 Jul 2018 08:54:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v1II+Au7UZ0tE7g7uWeE9KbN9ppj00B4ffpW2i0JUXQ=; b=Qd1MXZjE3raDb4sh2oKZq4B1ShCv2GGpGYUw9DhVLnqQeifrK/hGgHPbtGJmLJyw+O SEfVPiJy7YeTWkPWtPirbBV1SUS7tiqN1W244ySS3kVHVu1gKKt/rvtsuNo2Aw4ntqfO /XasMlNCdb3SOd5HrjUW6eEBbNO0rttza90yc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v1II+Au7UZ0tE7g7uWeE9KbN9ppj00B4ffpW2i0JUXQ=; b=gnG6jG+XD55mAjmIeKWcIwlFVQg8itmYI8QxT40dxtNMxrlV6biapkWYnJGLbKtwqU CAt8im6iTSDfkTzFjsCYH8CdvqKSvSrX9mcvK1h83cfDjxzB51ZHWpEvIo5oNKVL/Lx8 Bz6Z4tG2QAM4HwDSv0i3/7bb53m5c8On140S5249fsDY+YWxWYS4u1EJLddpR3vAhIIG rMHkrmcak7Omq9O30Ism36ixj6mtCgxcf+ikGivh1lbuPlSGcpbawp7F+jflux1s8S0N 7XlTvqUmg9FyfvLiyWbayInYo2rgecGDPogf3QMm+tlaBzxzMy0AS3FBtJlNLeovf16g u/Qg== X-Gm-Message-State: APt69E3OT2BBR6D00Axt/4hecgnC425yJhC9fWg2BYi0EEjPTKOS1zU3 4vHZz4nfN2FJZFyNHLy7uPQ3Z/T+7BcGT+qmIwkI X-Google-Smtp-Source: AAOMgpexZ985x/qb0N9jCpGz0Z8jm4XgSTq3lxbcV+Q/3WFJLHMG7x3ejox5B0fiA1xmnoiu3Da4kd4tCpGwj3QQ/o8= X-Received: by 2002:a37:4654:: with SMTP id t81-v6mr1995011qka.82.1530719684368; Wed, 04 Jul 2018 08:54:44 -0700 (PDT) MIME-Version: 1.0 References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> In-Reply-To: From: David Benjamin Date: Wed, 4 Jul 2018 11:54:31 -0400 Message-ID: To: Nikos Mavrogiannopoulos Cc: Ilari Liusvaara , Peter Gutmann , "" Content-Type: multipart/alternative; boundary="0000000000000a41ce05702e73ae" Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 15:54:48 -0000 --0000000000000a41ce05702e73ae Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 11:15 AM David Benjamin wrote: > On Wed, Jul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos > wrote: > >> On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara wrote: >> > On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote: >> > > Ilari Liusvaara writes: >> > > >> > > > More serious problem is servers returning too small modulus due >> > > > lack of >> > > > negotiation. Which was the reason why Chrome disabled DHE. >> > > >> > > Why not reject the handshake if the modulus is too small, rather >> > > than >> > > disabling all DHE suites on the off chance that the server returns >> > > a value you >> > > don't like? >> > >> > Chrome initially did that. It caused quite a lot of bad feedback from >> > owners of various bad embedded stuff. The thread on relevant forums >> > was >> > quite something. Hundreds of messages blaming Google for breaking >> > stuff. >> >> We had similar experience when we required a minimum of 2048-bit >> modulus for all TLS connections in Fedora 28 beta irrespective of back- >> end lib. It broke connections to VPN servers and web internal web sites >> and we had to revert the change. The DHE ciphersuites under TLS1.2 seem >> doomed and rfc7919 couldn't save them. >> > > Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere > 1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we > encountered a lot of this.) 2048-bit was completely hopeless. At the time > of removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum. > See here for details: > Oops, that sentence should have read: "At the time of removal, 95% of DHE negotiations made by Chrome used a 1024-bit *group*." That is, were we to have enforced a 2048-bit minimum, 95% of DHE connections would have broken. With 5% of it salvageable, the TLS DHE code points are not worth saving. > > https://groups.google.com/a/chromium.org/d/msg/blink-dev/ShRaCsYx4lk/46rD81AsBwAJ > > I should add to that link that the "draft specification which fixes the > negotiation problems", now rfc7919, did not fix the problem. This was > pointed out here, but never incorporated to the document: > https://www.ietf.org/mail-archive/web/tls/current/msg18697.html > > To the original email, it seems the second and third scenarios are > identical. Configuring ECDHE+ECDSA ciphers is a no-op if using an RSA > server key. The third and fourth scenarios are indeed unsurprising for a > browser that doesn't support DHE. You should instruct these folks to > configure ECDHE+RSA ciphers if they have RSA keys. Particularly in the > second scenario, it seems they're already implemented, just the server was > incorrectly configured to use the wrong ones. > > DHE at acceptable sizes is quite slow anyway, so their servers may well > appreciate the speed boost. (Indeed, I often see DHE disabled in server > deployments as otherwise the poor servers would melt.) > --0000000000000a41ce05702e73ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 4,= 2018 at 11:15 AM David Benjamin <davidben@chromium.org> wrote:
On Wed, J= ul 4, 2018 at 4:41 AM Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
On Wed, 2018-07-04 at 11:15 +0300, Ilari Liusvaara = wrote:
> On Wed, Jul 04, 2018 at 07:57:41AM +0000, Peter Gutmann wrote:
> > Ilari Liusvaara <ilariliusvaara@welho.com> writes:
> >
> > > More serious problem is servers returning too small modulus = due
> > > lack of
> > > negotiation. Which was the reason why Chrome disabled DHE. > >
> > Why not reject the handshake if the modulus is too small, rather<= br> > > than
> > disabling all DHE suites on the off chance that the server return= s
> > a value you
> > don't like?
>
> Chrome initially did that. It caused quite a lot of bad feedback from<= br> > owners of various bad embedded stuff. The thread on relevant forums > was
> quite something. Hundreds of messages blaming Google for breaking
> stuff.

We had similar experience when we required a minimum of 2048-bit
modulus for all TLS connections in Fedora 28 beta irrespective of back-
end lib. It broke connections to VPN servers and web internal web sites
and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
doomed and rfc7919 couldn't save them.

<= /div>
Indeed. The bad= feedback was not even at a 2048-bit minimum, but a mere 1024-bit minimum. = (Chrome enabled far more DHE ciphers than others, so we encountered a lot o= f this.) 2048-bit was completely hopeless. At the time of removal, 95% of D= HE negotiations made by Chrome used a 1024-bit minimum. See here for detail= s:

Oops, that sentence sh= ould have read:

"At the time of removal,=C2= =A095% of DHE negotiations made by Chrome used a 1024-bit *group*."

That is, were we to have enforced a 2048-bit minimum= , 95% of DHE connections would have broken. With 5% of it salvageable, the = TLS DHE code points are not worth saving.
=C2=A0

I sh= ould add to that link that the "draft specification which fixes the ne= gotiation problems", now rfc7919, did not fix the problem. This was po= inted out here, but never incorporated to the document:

To the original email, it seems the second an= d third scenarios are identical. Configuring ECDHE+ECDSA ciphers is a no-op= if using an RSA server key. The third and fourth scenarios are indeed unsu= rprising for a browser that doesn't support DHE. You should instruct th= ese folks to configure ECDHE+RSA ciphers if they have RSA keys. Particularl= y in the second scenario, it seems they're already implemented, just th= e server was incorrectly configured to use the wrong ones.

DHE at acceptable sizes is quite slow anyway, so their servers may= well appreciate the speed boost. (Indeed, I often see DHE disabled in serv= er deployments as otherwise the poor servers would melt.)
--0000000000000a41ce05702e73ae-- From nobody Wed Jul 4 09:31:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B9E130E18 for ; Wed, 4 Jul 2018 09:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URI_TRY_3LD=1.999] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zfjbta7PkNAN for ; Wed, 4 Jul 2018 09:31:03 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 DC01C130DE1 for ; Wed, 4 Jul 2018 09:31:02 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id d74-v6so3383473vke.10 for ; Wed, 04 Jul 2018 09:31:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=c8i2dN2EbWhgTi+vczX8Rhk6z11g3doMffkXdrX3mcU=; b=dhdAvCnwZqBp/OPrBGUvb1MsreTZbjPgNf5DuBtDJgfaQo6H40fJS3Wtv6P6A8BpkM RLdfhXMcnWzlIx6Qd/0IIzJnwzN71RoamBhqiL/bqd6PKhXWqpk965pQhov1MY4tbQJk KG+I+rNdGvrCCESFXiuzAlbvP/rH8xT66mN90aOAbzon0mwJxGyrWHKktlbmE+vtx9vx zKIEEgv/xASq+GHfO3K5nISxxgqFKsEmaa7Q6gVhTHwG1H9231yj81VAVpowj9aasZtp /TJlG4S6gTX25w+V/4yC4+MgIF8a7NaQ4VsOeeBrDV7pLexulOP5Ah+Ym6BMYjRGZdf8 3HxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=c8i2dN2EbWhgTi+vczX8Rhk6z11g3doMffkXdrX3mcU=; b=Z3VBXxFVrOXe2PH7EReZhFzftct4FLZlJKkWKOknM6QhkAGVV6A0YDMgd6sse/0R6L 4K7mFC4y6tsxIC3S+sdnjfmWbidLUZZj0QQOsEqo9Vgpb+jTNjJpBqyKlHQMImDq3nvN 3T//U8gpuXOYh3OCvlJ2Fd7ohsMioAmSwkdl+NiPr2/85XSqKNZ4EIVebKL4+xaEavli LXvKrMSLaWd/GvpWpaJh7OxBZs22EipTi9VWc/Brn35opumqLdskrVM7ZtXHrdd3U3Ho Woqf86CuJ4ACSFRcyjc1WQw0KSbv/s7VbF3hmJyhEode+us9yf4eaGxDjPQMlO3yz1O2 bIHw== X-Gm-Message-State: APt69E0tVzfTBndWZipnPOaTA9uQacWDO45jP2wgZrOpJckGk2gH2dRi xaf48aCKkjwUtGfIow2CznOn8YQEr63sfXc9vRs= X-Google-Smtp-Source: AAOMgpfh9pKjndoImU5rKzbCV67ZdWFvWZ36sQrGawkBxS7nHNFSqwwtSLdekjqWm5mgGRAPnCPUjrP1jZbmnbTpy9w= X-Received: by 2002:a1f:a38b:: with SMTP id m133-v6mr1483666vke.20.1530721861388; Wed, 04 Jul 2018 09:31:01 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tony Arcieri Date: Wed, 4 Jul 2018 09:30:50 -0700 Message-ID: To: jordan.ietf@gmail.com Cc: "" Content-Type: multipart/alternative; boundary="000000000000cc4f4405702ef400" Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 16:31:06 -0000 --000000000000cc4f4405702ef400 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 3, 2018 at 10:08 AM Bret Jordan wrote: > From my personal perspective, we need to be careful with all of these > efforts. It feels like the pendulum has swung so far to one side, the side > of privacy-at-any-cost, that we are unknowingly increasing the risk to > individuals and organizations by enabling threat actors and intrusions sets > to attack networks and clients without any level of protection from the > network. > Speaking as an industry practitioner and network security professional, don't trust the network. That is the entire purpose of TLS. As one of my present job capacities I micromanage Juniper SRX firewall rules. However, my personal view of the value provided is that it's a defense-in-depth measure at best. There are already many ways for attackers to take surprising and unexpected paths through the network which are much more interesting and useful than through a DNS+CDN's frontend terminator. Just as one example of such a path which is incredibly hard to block is Amazon S3, where you can attempt to whitelist a particular bucket by hostname, and even try to do NIDS to ensure that S3 requests only go to mybucket.s3.amazonaws.com by inspecting SNI and rejecting anything but a particular bucket in the SNI, but after TLS has been established an attacker can send a Host: header of attackerbucket.s3.amazonaws.com and S3 doesn't care what domain you used to get there or what SNI you sent. > It also feels like a lot of these initiatives are being done without > adequately involving and ensuring that enterprise networks and critical > infrastructure can work with these changes. Question, do we know how these > ideas and changes are going to impact an organizations ability to fulfill > their requirements for regulatory compliance? > I am a co-founder of a technology company, and was formerly on the information security team of a publicly traded next-gen fintech company. Speaking as a representative of industry, I would once again like to make it very clear that demands for "visibility" represent one perspective within industry as a whole. I think if it were possible to take a hum "from industry", you would find it quite divided on this topic, particularly between older larger companies and smaller, newer ones. Having aided (in some cases instrumentally) with PCI-DSS, HIPAA, and SOX audits in a modern fintech company with a card storage environment and massive cash flows to account for and safeguard, my professional opinion as someone on the information security team for that company is that the net effect of ESNI on any of the compliance strategies being used is 0. I think you might get a different perspective from someone whose compliance strategy is largely predicated on e.g. Blue Coat "Visibility" appliances who think things like passive SNI inspection are good indicators that traffic flows are legitimate. However, while I'm aware this approach is quite popular with e.g. older financial institutions, as noted above with the S3 example it's still leaky. As long as you have a "legitimate" frontend that can reach a backend which will honor the Host header over what's in SNI and can get to both "legitimate" and attacker-controlled resources, attackers can already bypass things passive SNI inspection. That said, I think there are very much legitimate enterprise use cases of this feature (see below). > If we continue down these paths, then I fear networks will be required to > wrap all traffic in some other less secure protocol, outright deny some of > these protocols, or be forced to fully proxy all traffic or take an > approach that Google has done with their BeyondCorp design. > In my opinion BeyondCorp-style designs are considered state-of-the-art by the security teams of companies I respect, including the public fintech company I formerly worked at which is presently in the process of migrating from VPN-based access to a BeyondCorp-style approach. As someone presently solving this problem for my company, I have recently deployed Google's Identity Aware Proxy (IAP) to provide "front door" authentication to internal web applications. IAP works by having you point DNS at Google's frontend web servers, which terminate HTTPS, check for a credential, and if it isn't present perform an OAuth flow. It integrates with the rest of Google's suite of "BeyondCorp" tools including things like Cloud Identity and Endpoint Verification to ensure all access to internal tools is both strongly authenticated and coming from a known healthy endpoint. The important point here is that everyone using IAP is pointing DNS at the Google frontend. In conjunction with e.g. Google Domains or GCP Cloud DNS, IAP could support this approach to ESNI. In a BeyondCorp architecture, ESNI would provide confidentiality for the DNS names of internal tools being accessed through IAP. Using something like DoH in conjunction with dns.google.com, we can completely reduce the parties who are able to determine which internal tools are being accessed to Google exclusively. Is there enterprise value to actually protecting this information? Well, like network security, it is (or at least should be) only defense-in-depth. But I still see value in defense-in-depth. As an industry practitioner, from the perspective of the sorts of companies I work at, I see no downsides of this approach. Instead see an interesting feature which I want to use. Framing things in terms of "privacy" versus "industry concerns" is a false dichotomy, and one we continue to see being perpetrated by the "visibility" camp, e.g. https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-enterprises (which had an awesome response from agl: https://www.imperialviolet.org/2018/03/10/tls13.html). They are using this as a rhetorical tactic to spin the "visibility" debate, when the reality is that the interests of individuals and enterprises are not at odds. What are at odds are improving Internet security for everyone versus the interests of e.g. Blue Coat's customers whose compliance story presently depends on their ability to break their own security from a single point of compromise. More modern techniques like endpoint agents, tracing frameworks, and other observability tools can tick the same compliance checkboxes and solve the same problems like debugging complicated service-oriented architectures. But it seems some people stuck on the Blue Coat model would rather make Internet security worse for everyone than invest in updating to a more modern approach. Enterprises can benefit from privacy just as much as individuals. However, not all enterprises within industry as a whole are ready to take advantage of it. When seeking out industry input for IETF, make sure you're not only paying attention to a particularly vocal segment whose views are not representative of industry as a whole. -- Tony Arcieri --000000000000cc4f4405702ef400 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 3,= 2018 at 10:08 AM Bret Jordan <= jordan.ietf@gmail.com> wrote:
From my perso= nal perspective, we need to be careful with all of these efforts. It feels = like the pendulum has swung so far to=C2=A0one side, the side of privacy-at= -any-cost, that we are unknowingly increasing the risk to individuals and o= rganizations by=C2=A0enabling threat actors and intrusions sets to attack n= etworks and clients without any level of protection from the network.

Speaking as an industry practiti= oner and network security professional, don't trust the network. That i= s the entire purpose of TLS.

As one of my present = job capacities I micromanage Juniper SRX firewall rules. However, my person= al view of the value provided is that it's a defense-in-depth measure a= t best.

There are already many ways for attackers = to take surprising and unexpected paths through the network which are much = more interesting and useful than through a DNS+CDN's frontend terminato= r. Just as one example of such a path which is incredibly hard to block is = Amazon S3, where you can attempt to whitelist a particular bucket by hostna= me, and even try to do NIDS to ensure that S3 requests only go to mybucket.s3.amazonaws.com by insp= ecting SNI and rejecting anything but a particular bucket in the SNI, but a= fter TLS has been established an attacker can send a Host: header of attackerbucket.s3.amazonaws.co= m and S3 doesn't care what domain you used to get there or what SNI= you sent.
=C2=A0
It also feels like a lot o= f these initiatives are being done without adequately involving and ensurin= g that enterprise networks and=C2=A0critical infrastructure can work with t= hese changes. Question, do we know how these ideas and changes are going to= impact an=C2=A0organizations ability to fulfill their requirements for reg= ulatory compliance?=C2=A0

<= div style=3D"background-color:rgb(255,255,255);text-decoration-style:initia= l;text-decoration-color:initial">I am a co-founder of a technology company,= and was formerly on the information security team of a publicly traded nex= t-gen fintech company. Speaking as a representative of industry, I would on= ce again like to make it very clear that demands for "visibility"= represent one perspective within industry as a whole. I think if it were p= ossible to take a hum "from industry", you would find it quite di= vided on this topic, particularly between older larger companies and smalle= r, newer ones.

Having aided (in some cases instrumentally) with PC= I-DSS, HIPAA, and SOX audits in a modern fintech company with a card storag= e environment and massive cash flows to account for and safeguard, my profe= ssional opinion as someone on the information security team for that compan= y is that the net effect of ESNI on any of the compliance strategies being = used is 0.

I think you might get a different perspective from someo= ne whose compliance strategy is largely predicated on e.g. Blue Coat "= Visibility" appliances who think things like passive SNI inspection ar= e good indicators that traffic flows are legitimate. However, while I'm= aware this approach is quite popular with e.g. older financial institution= s, as noted above with the S3 example it's still leaky. As long as you = have a "legitimate" frontend that can reach a backend which will = honor the Host header over what's in SNI and can get to both "legi= timate" and attacker-controlled resources, attackers can already bypas= s things passive SNI inspection.
That said, I think there are very = much legitimate enterprise use cases of this feature (see below).
=C2= =A0
If we continue down these paths, then I fear netwo= rks will be required to wrap all traffic in some other less secure protocol= ,=C2=A0outright deny some of these protocols, or be forced to fully proxy a= ll traffic or take an approach that Google has done with their=C2=A0BeyondC= orp design.

In my opinion Beyon= dCorp-style designs are considered state-of-the-art by the security teams o= f companies I respect, including the public fintech company I formerly work= ed at which is presently in the process of migrating from VPN-based access = to a BeyondCorp-style approach.

As someone present= ly solving this problem for my company, I have recently deployed Google'= ;s Identity Aware Proxy (IAP) to provide "front door" authenticat= ion to internal web applications. IAP works by having you point DNS at Goog= le's frontend web servers, which terminate HTTPS, check for a credentia= l, and if it isn't present perform an OAuth flow. It integrates with th= e rest of Google's suite of "BeyondCorp" tools including thin= gs like Cloud Identity and Endpoint Verification to ensure all access to in= ternal tools is both strongly authenticated and coming from a known healthy= endpoint.

The important point here is that everyo= ne using IAP is pointing DNS at the Google frontend. In conjunction with e.= g. Google Domains or GCP Cloud DNS, IAP could support this approach to ESNI= . In a BeyondCorp architecture, ESNI would provide confidentiality for the = DNS names of internal tools being accessed through IAP. Using something lik= e DoH in conjunction with dns.google.com<= /a>, we can completely reduce the parties who are able to determine which i= nternal tools are being accessed to Google exclusively.

Framing things in terms of "privacy" versus &quo= t;industry concerns" is a false dichotomy, and one we continue to see = being perpetrated by the "visibility" camp, e.g.=C2=A0https://www.ncsc.gov.uk/blog-post/tls-13-better-individuals-harder-ent= erprises (which had an awesome response from agl:=C2=A0https://www.imperialviolet= .org/2018/03/10/tls13.html). They are using this as a rhetorical tactic= to spin the "visibility" debate, when the reality is that the in= terests of individuals and enterprises are not at odds. What are at odds ar= e improving Internet security for everyone versus the interests of e.g. Blu= e Coat's customers whose compliance story presently depends on their ab= ility to break their own security from a single point of compromise. More m= odern techniques like endpoint agents, tracing frameworks, and other observ= ability tools can tick the same compliance checkboxes and solve the same pr= oblems like debugging complicated service-oriented architectures. But it se= ems some people stuck on the Blue Coat model would rather make Internet sec= urity worse for everyone than invest in updating to a more modern approach.=

Enter= prises can benefit from privacy just as much as individuals. However, not a= ll enterprises within industry as a whole are ready to take advantage of it= . When seeking out industry input for IETF, make sure you're not only p= aying attention to a particularly vocal segment whose views are not represe= ntative of industry as a whole.

--
Tony Arcieri
--000000000000cc4f4405702ef400-- From nobody Wed Jul 4 09:51:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BDF3130EA8 for ; Wed, 4 Jul 2018 09:50:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9jzO-EiqGLuH for ; Wed, 4 Jul 2018 09:50:56 -0700 (PDT) Received: from mail-yb0-x234.google.com (mail-yb0-x234.google.com [IPv6:2607:f8b0:4002:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FB312777C for ; Wed, 4 Jul 2018 09:50:56 -0700 (PDT) Received: by mail-yb0-x234.google.com with SMTP id c10-v6so544582ybf.9 for ; Wed, 04 Jul 2018 09:50:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EJdkv+10dnhS778nGeHuTvo/hd5OvBetWH3nwd3RBoE=; b=uHPJnMdy6OBjI9aDEvEhiuTZqBLZe6QptVYLYA4GC29QS/colYszgKCROIRyso2wyz Yhz6UNF9+fQGsnDHJqREaBeuxIFkJlhqFRneNuTLDJQYQalR7NCeqY9l4at+TYkbK1Xr UfskUVJoQ4XukTkv9a43OX6wrz0apIE9jhqh6EufnlHKTKLe6ZnsFbcF4z1eP4CnVY3H nJzxKJxZHwCHZv8PXjI2q93uaiJ64rWsb050IB23TE6I/9two5Q3zGj23Z27BXfPpyxy Zhymd69lLkbEyDWJ2QYHKIxYTIvpbB5lpSaa4PTO3gTSxoCx22xCNotqb399O1xcqONk Ns0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EJdkv+10dnhS778nGeHuTvo/hd5OvBetWH3nwd3RBoE=; b=LabeWQgY6NUXzUI0HMxcl0bXKXF1Ud+ri9W/q94Wp9AvmQoJx729/0MklkmAWi5k6i +nJKmq7eMrly/pyH/oq5OV8b2TDeIAkCuLgJZFtSDpeHSDP0LUwJGb51BO7PY6+dOnuC Bn0bCzeNsm2H+YqR7aYFJzNRb+IMVkqm0IAdhff/1z0jjLKa090gekw5rlx0MrW+Oz6l hpuAuE8ps4rW2+H/2CHahQBRH1uFQe6ejNenXHZym/p2/I2NVbLJubwoQOQG8bCwYwuR f3zyx9KIy9cGEzNuufk24sbB4A83ro73XkgfxO2ANbPZI+3F/lt+zS+9kQ+AQAPnLvaF /GmA== X-Gm-Message-State: APt69E3T3UhagjdmuyKKkIyRtW4y2OcWyGflmItWqVbSKZvqWu1gN7vX hexzfXAWqfKcdIajKpCs+i71WBs7U1nEoPY1DsmrYd9Y X-Google-Smtp-Source: AAOMgpdqh2g6nUnhOC095yEBqGx74uR5F0S+tHwSjdP+JXyKbDg8Sv43iLW6Hf9Y8yleO2qvtmyKeJAkfjYVPiZgQV0= X-Received: by 2002:a25:b1a0:: with SMTP id h32-v6mr1454150ybj.413.1530723055111; Wed, 04 Jul 2018 09:50:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 09:50:14 -0700 (PDT) In-Reply-To: <2034146.0jKBJLNyPE@pintsize.usersys.redhat.com> References: <1857183.8Fq0dhFQ1N@pintsize.usersys.redhat.com> <20180704130627.GA26089@LK-Perkele-VII> <2034146.0jKBJLNyPE@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 4 Jul 2018 09:50:14 -0700 Message-ID: To: Hubert Kario Cc: Ilari Liusvaara , "" Content-Type: multipart/alternative; boundary="000000000000f32c6205702f3b4b" Archived-At: Subject: Re: [TLS] [PSA] 0-RTT tolerance is mandatory X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 16:50:59 -0000 --000000000000f32c6205702f3b4b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 4, 2018 at 6:27 AM, Hubert Kario wrote: > On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote: > > On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote: > > > All the implementations I deal with in my day-to-day work fail to > handle > > > the 0-RTT client hello correctly when the 0-RTT support is not enable= d > on > > > the server. > > > > > > I.e. they ignore the MUST clause from > > > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating > that > > > the server can handle an early_data extension (and following encrypte= d > > > data) in only one of three ways, neither which allows for uncondition= al > > > connection abort. > > > > > > This also runs afoul the recommendation from > https://tools.ietf.org/html/ > > > draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibility. > > > > OTOH, such servers probably do not send out tickets allowing 0-RTT, so > > any client attempting 0-RTT with such server is very broken. > > please read Section D.3, it is spelled out in detail there why that's not > the > case > > > the short of it: the client has no way of knowing if it is connecting to > the > same server/instance/process it received the ticket from > That's true if you have some kind of mixed rollout, but if you never supported 0-RTT, then there is something wrong with the client. -Ekr > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --000000000000f32c6205702f3b4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 6:27 AM, Hubert Kario <hkario@redhat.com>= ; wrote:
On Wedne= sday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote:
> On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote:
> > All the implementations I deal with in my day-to-day work fail to= handle
> > the 0-RTT client hello correctly when the 0-RTT support is not en= abled on
> > the server.
> >
> > I.e. they ignore the MUST clause from
> > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating that
> > the server can handle an early_data extension (and following encr= ypted
> > data) in only one of three ways, neither which allows for uncondi= tional
> > connection abort.
> >
> > This also runs afoul the recommendation from https://tools.iet= f.org/html/
> > draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compa= tibility.
>
> OTOH, such servers probably do not send out tickets allowing 0-RTT, so=
> any client attempting 0-RTT with such server is very broken.

please read Section D.3, it is spelled out in detail there why that&= #39;s not the
case


the short of it: the client has no way of knowing if it is connecting to th= e
same server/instance/process it received the ticket from

That's true if you have some kind of mixed rollout, b= ut if you never supported
0-RTT, then there is something wrong wi= th the client.

-Ekr


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

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


--000000000000f32c6205702f3b4b-- From nobody Wed Jul 4 09:54:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4D5130F04 for ; Wed, 4 Jul 2018 09:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1eNxAWeoNOQz for ; Wed, 4 Jul 2018 09:54:14 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04DE7130E80 for ; Wed, 4 Jul 2018 09:54:12 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id x10-v6so2278993ybl.10 for ; Wed, 04 Jul 2018 09:54:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lRSFfqijJ+hz3BOumRCf8a+gCOmsLKId7GHm7yJ+zXA=; b=eYU1BBRsOeSMF6Utz1t01cI+9v4DFzD3RIoEnhlc5Nj90whW97N2KRuNU9oz5UQbcC EQGV7FZaZ19KPYkxFSgxQfi2bWcqoY+J2QHkDYPpMgedtpFEvVIBmXu2/zXSC8eAqsQP qcZ8+q5gpT6kBtiypoOGoFmSdk1/Td12Q35M8ULXec2c/BY5/gEV7810C8PP0zgphrnH mqq39tVDT6pYx9TOdwi9OLwoLCLSk2C2FOdHcMeKdcJY3U0nQ/cgg+r655iTY4OvTSuv QUffSyb1aGUkpi9IxeUStR0iXdW55gvleKwgnIZrYyil6teZt/oUcmKRTMgqDo2yItgU tR7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lRSFfqijJ+hz3BOumRCf8a+gCOmsLKId7GHm7yJ+zXA=; b=JkjDXxGXWvrN9j0BkrJe3GwcTy3faT77zDHRBryWNJmxyX8vbZWYAii0UWbU25i+CW TIkPIjlF5SBl+5SlSsWTOt9QFoyhu2n07sTi00HNOuObppqPogsev57azYUYRhepdXeh F0pqWXx9YAUVq8F2V62ZI7d4O82Q3zO6yX4EM9vZv/wnb/d2J6Gn8zgQP7gpehXHzY/Z MHHJKqttLoZQOFo6jcNZ3N2z5onINrVLPM2oWYq8Yffi3ZEapIVf0Et5CH70pvmDDFqr obbkoh85PAZ0+piGTRmCEx5bqbgEKB0eOJwX4gD/zylWoEQ7CAG/Wt+VJ//xEOZHJC9K H4Qw== X-Gm-Message-State: APt69E3H/crDW+98xMbYbe3aLMUHAIFyZ+EkRIRVuohwu1uR1AKEcmDG mEtKJIcQ9kjOb+rkVHQIB5vYLFnaHXSNX2aWXX0c5qBg X-Google-Smtp-Source: AAOMgpfwop9LhMKr3Lsi4N2szu942GIYbSDpKxPsEmzeAJROsinXlggdkFaD2Fnyj4s2d8hRrRqq3AYGmranAX9rz0s= X-Received: by 2002:a25:acd0:: with SMTP id x16-v6mr1503261ybd.407.1530723251286; Wed, 04 Jul 2018 09:54:11 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 09:53:30 -0700 (PDT) In-Reply-To: <20180704130834.GB26089@LK-Perkele-VII> References: <20180704044844.GB10665@LK-Perkele-VII> <20180704130834.GB26089@LK-Perkele-VII> From: Eric Rescorla Date: Wed, 4 Jul 2018 09:53:30 -0700 Message-ID: To: Ilari Liusvaara Cc: "" Content-Type: multipart/alternative; boundary="000000000000a4889105702f4734" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 16:54:24 -0000 --000000000000a4889105702f4734 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 6:08 AM, Ilari Liusvaara wrote: > On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote: > > On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:= > > > > I am working on an implementation for NSS/Firefox and I know some > > > > others are working on their own implementations, so hopefully we can > > > > do some interop in Montreal. > > > > > > > > This is at a pretty early stage, so comments, questions, defect > > > > reports welcome. > > > > > > One thing I noticed: First there is this in evaluation: > > > > > > 7.2.4. Do not stick out > > > > > > By sending SNI and ESNI values (with illegitimate digests), or by > > > sending legitimate ESNI values for and "fake" SNI values, clients do > > > not display clear signals of ESNI intent to passive eavesdroppers. > > > > > > Is that suggesting to send fake ESNI values? If so, there is this in > > > endpoint behavior: > > > > > > > No, you would not send fake ESNI values. The idea here is that there is a > > group of IPs (associated with a big provider, then all ESNI-supporting > > clients will send ESNI to it. So the provider will stick out, but the use > > of site X versus site Y on the provider will not stick out. And the > > provider's IPs are reasonably well known through other mechanisms, so > this > > doesn't tell you much. Of course, this does not help big sites that > aren't > > using shared infrastructure (e.g., Facebook), but I don't know how to do > > that. > > What does "with illegitimate digests" mean then? > I didn't write this text, but I agree that it's in conflict with the requirement that you abort with an unknown key. We went through some design variants and this looks like a remnant of a previous one. -Ekr > > -Ilari > --000000000000a4889105702f4734 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 6:08 AM, Ilari Liusvaara <<= a href=3D"mailto:ilariliusvaara@welho.com" target=3D"_blank">ilariliusvaara= @welho.com> wrote:
On Wed, Jul 04, 2018 at 05:56:07AM -0700, Eric Rescorla wrote:
> On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=3D=
> > > I am working on an implementation for NSS/Firefox and I know= some
> > > others are working on their own implementations, so hopefull= y we can
> > > do some interop in Montreal.
> > >
> > > This is at a pretty early stage, so comments, questions, def= ect
> > > reports welcome.
> >
> > One thing I noticed: First there is this in evaluation:
> >
> > 7.2.4.=C2=A0 Do not stick out
> >
> >=C2=A0 =C2=A0 By sending SNI and ESNI values (with illegitimate di= gests), or by
> >=C2=A0 =C2=A0 sending legitimate ESNI values for and "fake&qu= ot; SNI values, clients do
> >=C2=A0 =C2=A0 not display clear signals of ESNI intent to passive = eavesdroppers.
> >
> > Is that suggesting to send fake ESNI values? If so, there is this= in
> > endpoint behavior:
> >
>
> No, you would not send fake ESNI values. The idea here is that there i= s a
> group of IPs (associated with a big provider, then all ESNI-supporting=
> clients will send ESNI to it. So the provider will stick out, but the = use
> of site X versus site Y on the provider will not=C2=A0 =C2=A0 stick ou= t. And the
> provider's IPs are reasonably well known through other mechanisms,= so this
> doesn't tell you much. Of course, this does not help big sites tha= t aren't
> using shared infrastructure (e.g., Facebook), but I don't know how= to do
> that.

What does "with illegitimate digests" mean then?
I didn't write this text, but I agree that it's in con= flict with the requirement that
you abort with an unknown key. We= went through some design variants and
this looks like a remnant = of a previous one.

-Ekr



-Ilari

--000000000000a4889105702f4734-- From nobody Wed Jul 4 09:55:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BF2913103B for ; Wed, 4 Jul 2018 09:54:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qoDoUWAg6_d for ; Wed, 4 Jul 2018 09:54:52 -0700 (PDT) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EAA0130E80 for ; Wed, 4 Jul 2018 09:54:52 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id l189-v6so2111821ywb.10 for ; Wed, 04 Jul 2018 09:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pGYUSLesNrK7b4Jp/esbq1zYE8YzoDetPAqf0HcBxDs=; b=FlzjYIf+zbWOYFh5x/qMGCJHTFuMlyEXaX+zFCek9A8bEmyob/UBrIJHixSBGbzn3Z mdKQhTZjynA0m6Eifu8ugsDignPegfqPjKzIdvOEwz4ibee2T28ida4ALnePqzESZJbN BFhXsiEsKICE/V28v5riKglGauVack1pIfIn6kMLDKsLxx0JT7PghWi2ehzlIQCLTT6v tYKJhyhdltMSfrSXcwgeTKP8qMrYGGQxYfhklhPBFOAqXP1DLGpUFmAPsV2jfG8OAZTE cnsqQIPqMilvLKOrOakjJ14C2m9GXfCb56Gt9WPSYsVSsJnHOXMY/u03lJxhATew4e3/ 5OXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pGYUSLesNrK7b4Jp/esbq1zYE8YzoDetPAqf0HcBxDs=; b=tBDyGgILvYqgGTsCvbC0dngdcBqqFzEgkIqung2+uP8NAnt7pJN5U2+2urEo6hR/5S jH/7jxbCqcEhR0GQnv+RNkQMvO0rMiEQdJAOUCEpSOpNrIda9pV6HoyAVzkcm8rbUl1v suhN0VB5CbTm3OTGL4n5IWdIjylUP7yWaoE5Nz6gZ/OoiQgtjQBNC+fy3drlWk7P38VK F+x4BLb3jQstvOnr6Sj3NHWROX3Jj17XZTQobaJEyDQ8TbcVQ1vqi91jfag/odwr4a6C 99A29BBSf7i9JTFUEqdv+5ylsIFgfiqwn1Ike8MHhMipXvY3NOSOjch4voMTIbuA3KDp EbBg== X-Gm-Message-State: APt69E05dQ/Nbt/wkC7X/d2XL05/REOEYH1VcELgunYHBSar8hMtgi9G f7Nd+QXtDjbLI5RtZtoDDXzX43JqZ+LiatfYFm9XN2G2 X-Google-Smtp-Source: AAOMgpdlZrLzZERHdZysrU48PgBnnjuWY6WqjiPwLoboJl+7FwusH2gihO9XOXh9v7AwSQoWuX05SMyShQKGFql14wE= X-Received: by 2002:a0d:f286:: with SMTP id b128-v6mr1275546ywf.489.1530723291313; Wed, 04 Jul 2018 09:54:51 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 09:54:10 -0700 (PDT) In-Reply-To: <10346670.25GZR1XrEq@pintsize.usersys.redhat.com> References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> <10346670.25GZR1XrEq@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Wed, 4 Jul 2018 09:54:10 -0700 Message-ID: To: Hubert Kario Cc: "" Content-Type: multipart/alternative; boundary="00000000000007507405702f4a80" Archived-At: Subject: Re: [TLS] Malformed Finished handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 16:55:09 -0000 --00000000000007507405702f4a80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario wrote: > On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote: > > I think it's a close call, because the length is sort of external to th= e > > language. > > which language? the decode_error alert description literally says "length > of > the message was incorrect." > The protocol definition language. -Ekr > > That's why, for instance, NSS sends "illegal_parameter". So, > > absent specific text about this value, I think this is something we can > > leave to the implementations. > > but the text is explicit, if a message continues past message boundary, > the > correct response is decode_error. Decode_error is also consistent with th= e > way > above-expected length Client Hello MUST be handled. > > Just because the description of the message uses a single opaque array > doesn't > make this message syntactically any different from other Handshake > protocol > message. > > if the interpretation of "I know this _message_ _length_ is wrong because > of > some other values I negotiated before, so I'll send illegal_parameter" wa= s > correct, then overflow_error, decrypt_error and probably few others would > also > need to be replaced with illegal_parameter... > > > -Ekr > > > > On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario wrote: > > > Despite this, is it correct to terminate a connection with > > > "illegal_parameter" > > > upon receiving a Finished handshake message with a 100 byte payload? > or a > > > 20 > > > byte payload? My opinion is that it is not, "decode_error" is more > > > specific so > > > it should be used instead. > > > > > > > > > Specification says the following on the matter: > > > > > > The draft 28 specifies the Finished message as having following > structure: > > > struct { > > > > > > opaque verify_data[Hash.length]; > > > > > > } Finished; > > > > > > At multiple places it also talks about handling messages that have > sizes > > > that > > > don't match their structure as requiring termination of connection wi= th > > > "decode_error". > > > > > > The generic situation in Section 6: > > > Peers which receive a message which > > > cannot be parsed according to the syntax (e.g., have a length > > > extending beyond the message boundary or contain an out-of-range > > > length) MUST terminate the connection with a "decode_error" alert. > > > > > > as description of the alert in Section 6.2: > > > decode_error A message could not be decoded because some field wa= s > > > > > > out of the specified range or the length of the message was > > > incorrect. This alert is used for errors where the message doe= s > > > not conform to the formal protocol syntax. > > > > > > In specific about Client Hello, in Section 4.1.2: > > > If negotiating a version of TLS prior to 1.3, a server MUST check > > > that the message either contains no data after > > > legacy_compression_methods or that it contains a valid extensions > > > block with no data following. If not, then it MUST abort the > > > handshake with a "decode_error" alert. > > > > > > And specific handling of Certificate from server in Section 4.4.2.4: > > > If the server supplies an empty Certificate message, the client MU= ST > > > abort the handshake with a "decode_error" alert. > > > > > > Description of "illegal_parameter" in Section 6: > > > Peers which receive a message which is syntactically correct but > > > semantically invalid (e.g., a DHE share of p - 1, or an invalid > enum) > > > MUST terminate the connection with an "illegal_parameter" alert. > > > > > > Alert description in Section 6.2: > > > illegal_parameter A field in the handshake was incorrect or > > > > > > inconsistent with other fields. This alert is used for errors > > > which conform to the formal protocol syntax but are otherwise > > > incorrect. > > > > > > (it's also mentioned in over a dozen places in the draft) > > > -- > > > Regards, > > > Hubert Kario > > > Senior Quality Engineer, QE BaseOS Security team > > > Web: www.cz.redhat.com > > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republi= c > > > _______________________________________________ > > > TLS mailing list > > > TLS@ietf.org > > > https://www.ietf.org/mailman/listinfo/tls > > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > --00000000000007507405702f4a80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario <hkario@redhat.com>= ; wrote:
On Wedne= sday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote:
> I think it's a close call, because the length is sort of external = to the
> language.

which language? the decode_error alert description literally says &q= uot;length of
the message was incorrect."

The pr= otocol definition language.

-Ekr


> That's why, for instance, NSS sends "illegal_parameter".= So,
> absent specific text about this value, I think this is something we ca= n
> leave to the implementations.

but the text is explicit, if a message continues past message bounda= ry, the
correct response is decode_error. Decode_error is also consistent with the = way
above-expected length Client Hello MUST be handled.

Just because the description of the message uses a single opaque array does= n't
make this message syntactically any different from other Handshake protocol=
message.

if the interpretation of "I know this _message_ _length_ is wrong beca= use of
some other values I negotiated before, so I'll send illegal_parameter&q= uot; was
correct, then overflow_error, decrypt_error and probably few others would a= lso
need to be replaced with illegal_parameter...
=C2=A0
> -Ekr
>
> On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario <hkario@redhat.com> wrote:
> > Despite this, is it correct to terminate a connection with
> > "illegal_parameter"
> > upon receiving a Finished handshake message with a 100 byte paylo= ad? or a
> > 20
> > byte payload? My opinion is that it is not, "decode_error&qu= ot; is more
> > specific so
> > it should be used instead.
> >
> >
> > Specification says the following on the matter:
> >
> > The draft 28 specifies the Finished message as having following s= tructure:
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0struct {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0opaque verify_data[Hash.l= ength];
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0} Finished;
> >
> > At multiple places it also talks about handling messages that hav= e sizes
> > that
> > don't match their structure as requiring termination of conne= ction with
> > "decode_error".
> >
> > The generic situation in Section 6:
> >=C2=A0 =C2=A0 Peers which receive a message which
> >=C2=A0 =C2=A0 cannot be parsed according to the syntax (e.g., have= a length
> >=C2=A0 =C2=A0 extending beyond the message boundary or contain an = out-of-range
> >=C2=A0 =C2=A0 length) MUST terminate the connection with a "d= ecode_error" alert.
> >
> > as description of the alert in Section 6.2:
> >=C2=A0 =C2=A0 decode_error=C2=A0 A message could not be decoded be= cause some field was
> >=C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0out of the specified range or the lengt= h of the message was
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0incorrect.=C2=A0 This alert is used for= errors where the message does
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0not conform to the formal protocol synt= ax.
> >
> > In specific about Client Hello, in Section 4.1.2:
> >=C2=A0 =C2=A0 If negotiating a version of TLS prior to 1.3, a serv= er MUST check
> >=C2=A0 =C2=A0 that the message either contains no data after
> >=C2=A0 =C2=A0 legacy_compression_methods or that it contains a val= id extensions
> >=C2=A0 =C2=A0 block with no data following.=C2=A0 If not, then it = MUST abort the
> >=C2=A0 =C2=A0 handshake with a "decode_error" alert.
> >
> > And specific handling of Certificate from server in Section 4.4.2.4:
> >=C2=A0 =C2=A0 If the server supplies an empty Certificate message,= the client MUST
> >=C2=A0 =C2=A0 abort the handshake with a "decode_error" = alert.
> >
> > Description of "illegal_parameter" in Section 6:
> >=C2=A0 =C2=A0 Peers which receive a message which is syntactically= correct but
> >=C2=A0 =C2=A0 semantically invalid (e.g., a DHE share of p - 1, or= an invalid enum)
> >=C2=A0 =C2=A0 MUST terminate the connection with an "illegal_= parameter" alert.
> >
> > Alert description in Section 6.2:
> >=C2=A0 =C2=A0 illegal_parameter=C2=A0 A field in the handshake was= incorrect or
> >=C2=A0 =C2=A0
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0inconsistent with other fields.=C2=A0 T= his alert is used for errors
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0which conform to the formal protocol sy= ntax but are otherwise
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0incorrect.
> >
> > (it's also mentioned in over a dozen places in the draft)
> > --
> > Regards,
> > Hubert Kario
> > Senior Quality Engineer, QE BaseOS Security team
> > Web: www.cz.redhat.com
> > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czec= h Republic
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=

--00000000000007507405702f4a80-- From nobody Wed Jul 4 10:20:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D97C7130DE6 for ; Wed, 4 Jul 2018 10:20:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjtWk_sV19Lq for ; Wed, 4 Jul 2018 10:20:48 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3077130E67 for ; Wed, 4 Jul 2018 10:20:48 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id k127-v6so2306975ybk.6 for ; Wed, 04 Jul 2018 10:20:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zaOHZ8Id5xJoyBJwtHWE+AEIpD4HoqHr5Wq3QTxCKpE=; b=hez0pQOGWdy4tW2JSkp9cx7hmoaKaQ/em68wFrbQc5hT9z/nm8YENFakm+Suih7NCt 2Z6VFwxW96KhynQemlTzbO2zjQyHEU9zIkO5FVl1xyYDmX5K++FQJFno7MpK9bXHUuRk 2tgzGr5qOqxEChxQ8LfpaNnaq5GJNROl9UfaOfVhq0aI7VPLp6lqcpH33mbPiG7b2E6t jbJFasV/cpRsA7anGVFLQLiJG4vt3ICmpVOEXSvM2cmLNiFYhkxRffd8UP5FBEdaMz0n TjBnQ9qkig+OnbbXWk2rYs72mkCgYecemkzLglaLyF0fVKdcdY/hVFtplZT3LdNEc1Ol xlBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zaOHZ8Id5xJoyBJwtHWE+AEIpD4HoqHr5Wq3QTxCKpE=; b=OAaZ5T/OH3TIH26ujSAff4au5cpGIxN2cKHNB3LXJePs4fntUL/jCgIhqUWDFuODVd /ZONYQefxEz4mfqoaJnWbABk550s9pouCqI3p1oL8FFUW+OxX5raU5zEyQa6dxWpz4ZG lOo4u/MlXo6ykhA2GnRsfXCkc3wWXFrFIrouB5zBbItpAtxfLSTExQb9UfmGGOeiYoAQ MYM5hNZ0q+PmhxRvErBEp2r//+of9Lpago8iONTcg/4ZoAWWm39s42fjR3X//YCOqmFo 1V/Qvw05QeCz4N7HVrRhOu7O7Kf+4rmkmZxyd9ZaVPNgBSD6jX2Fn6M2Ja2PH84mQ8PP wGdA== X-Gm-Message-State: APt69E3B7WqGJjMlEKvgOki6fq5xtPL4WZeyd339QlIPE0+RiDm8JCfU EzpER/D9QjesdgE48qhzlHfnK7irtu39GZNWdhamPTMP X-Google-Smtp-Source: AAOMgpf14H6XygwyRy9n1GiM8p2M/xRJKdq5C0w7jeP5AWY+mCI886C8lPEuZmzhbiFusQgSaGnYab4OHWfe/t4HHYs= X-Received: by 2002:a25:3496:: with SMTP id b144-v6mr1534824yba.275.1530724847739; Wed, 04 Jul 2018 10:20:47 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 10:20:07 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 4 Jul 2018 10:20:07 -0700 Message-ID: To: Stephen Farrell Cc: "" Content-Type: multipart/alternative; boundary="000000000000cc7b7205702fa612" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 17:20:51 -0000 --000000000000cc7b7205702fa612 Content-Type: text/plain; charset="UTF-8" Stephen, Thanks for your comments. On Wed, Jul 4, 2018 at 6:01 AM, Stephen Farrell wrote: > > Hiya, > > On 03/07/18 00:39, Eric Rescorla wrote: > > Hi folks, > > > > I just submitted: > > > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 > > Thanks for writing that up. I think it's an interesting > addition to the set of potential solutions. > > > > > This draft describes a DNS-based approach to doing encrypted SNI. > > > > Previously, we had thought this wouldn't work because only sites that > > were particularly vulnerable would do it, and so the use of ESNI marks > > you out. The idea behind this draft is that there are a lot of sites > > which are hosted by -- and whose DNS is run by -- a large provider, > > and that provider can shift many if not all of its sites to ESNI at > > once, thus removing the "standing out" issue and making a DNS-based > > approach practical. > > I'm not sure I fully understand how this approach would fit > with others, nor to what extent it depends on the DNS and > CDN providers co-operating, but it definitely seems worth > exploring. > I think the answer is "a lot". Basically, the entire reasoning here is that you can convert a lot of people at once. If you can't, then I don't think this is a viable option. - I didn't quite get what "all the domains" in 3.2 means. I > guess if a client uses non-encrypted sni for one of those, > it should still work, but I'm not clear if supporting esni > for any domain means that the provider has to decrypt esni > and then deal with successful decrypted sni values as if > the client had sent sni in clear. A concern is requiring > "all the domains" might make it hard to roll this out. > Yeah, this is badly written. It just means "all the ESNI-supporting domains". But as I said, if you host 50 domains and you only turn on ESNI for one, it's kind of pointless. - I guess some form(s) of key rollover will be needed, ut > I'm not sure that not_before/not_after is the best way to > do that. > > - The ESNIKeys structure generally seems a bit complicated, > it might be better to aim for simplifying that and maybe > making it more "zonefile friendly" (whether in a TXT RR > or not). > The structure started a bit simpler and got new features to deal with new issues. Specifically: - The checksum is intended to deal with corruption - The keys and cipher suites seem kind of mandatory - The padded length is needed to tell the client how much to pad. Though I guess we could always pad to 260. If you don't pad at all, it doesn't work. - I think it's clear what not_before and not_after are for. If you have more concrete feedback about better ways to do that, we'd welcome this. - Extensions is just there because we're trying to be safe. FWIW, this actually is pretty friendly because we b64-encode (thus making the internal structure opaque to DNS). Removing things won't make it much smaller because a big chunk of the data is in the keys. For instance, in my implementation, the object is 70 bytes long and 34 bytes of that is key (X25519) and 8 bytes is cipher suite (each of these has 2 bytes of length). - It might be interesting to think about how this'd work > for e.g. the IETF web site (where ietf.org is hosted > locally but www.ietf.org is not), and for STARTTLS and > MX RRs. That's probably ok, but I've not gotten it > straight in my little head yet:-) > I don't think we're assuming it applies to subdomains. > - Would it make sense to include the innocuous dummy sni > in the published RR, so that all clients use the same > one and stand out that bit less? > We actually had an "alt-svc" thing in here for that and removed it at the last minute. I'd welcome input on the best thing here. > - 7.1 probably needs more work - The whole draft needs more work! I'm not sure that it's > that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE, > or a client application that knows the ESNIKeys, are most > likely needed, but there's probably also some work to do > to analyse the recursive to authoritative interactions to > get the ESNIKeys even with DPRIVE. > "OK" might not have been the best choice of words. I think this actually contains two arguments: 1. You don't need DNSSEC. 2. It doesn't make matters worse to do this over unencrypted DNS (i.e., you're already in trouble). That said, it also doesn't add much value to do ESNI if the attacker controls your DNS, and in Firefox we're looking initially at just doing it when DoH is in use. Lastly, the topic of whether or not to try address this > problem is something that the WG has debated quite a bit, > and IIRC the consensus after that debate was to do work > on this (hence Christian's draft). > Thanks for making this point. My understanding was that we had WG consensus to protect SNI. Of course, it may be the case that the WG doesn't like this solution for one reason or another -- including potentially that it has an especially bad impact on enterprise deployments compared to other approaches -- but that seems like a different thing than saying we shouldn't try to protect SNI at all. -Ekr > So I don't see any need to debate whether or not to work on > this is needed, and trying to re-open such a debate seems > somewhat disruptive to me. It is entirely reasonable to > consider what, if anything, widespread use of esni or other > approaches might break though. But going back to all this > "privacy at any cost" and "we're the enterprises" hyperbole > is not at all helpful IMO, so I hope we don't have to suffer > more rounds of that. But maybe that's inevitable with every > iteration of attempts to improve privacy sadly;-( > > Cheers, > S. > > > > > > -Ekr > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --000000000000cc7b7205702fa612 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stephen,

Thanks for your com= ments.

On Wed, Jul 4, 2018 at 6:01 AM, Stephen Farrell <<= a href=3D"mailto:stephen.farrell@cs.tcd.ie" target=3D"_blank">stephen.farre= ll@cs.tcd.ie> wrote:

Hiya,

On 03/07/18 00:39, Eric Rescorla wrote:
> Hi folks,
>
> I just submitted:
>
>=C2=A0 =C2=A0https://tools.ietf.org/html/d= raft-rescorla-tls-esni-00

Thanks for writing that up. I think it's an interesting
addition to the set of potential solutions.

>
> This draft describes a DNS-based approach to doing encrypted SNI.
>
> Previously, we had thought this wouldn't work because only sites t= hat
> were particularly vulnerable would do it, and so the use of ESNI marks=
> you out. The idea behind this draft is that there are a lot of sites > which are hosted by -- and whose DNS is run by -- a large provider, > and that provider can shift many if not all of its sites to ESNI at > once, thus removing the "standing out" issue and making a DN= S-based
> approach practical.

I'm not sure I fully understand how this approach would fit
with others, nor to what extent it depends on the DNS and
CDN providers co-operating, but it definitely seems worth
exploring.

I think the answer is "= a lot". Basically, the entire reasoning here is that
you can= convert a lot of people at once. If you can't, then I don't think<= /div>
this is a viable option.


- I didn't quite get what "all the domains" in 3.2 means. I guess if a client uses non-encrypted sni for one of those,
it should still work, but I'm not clear if supporting esni
for any domain means that the provider has to decrypt esni
and then deal with successful decrypted sni values as if
the client had sent sni in clear. A concern is requiring
"all the domains" might make it hard to roll this out.

Yeah, this is badly written. It just means "= all the ESNI-supporting
domains". But as I said, if you host= 50 domains and you only
turn on ESNI for one, it's kind of p= ointless.



- I guess some form(s) of key rollover will be needed, ut
I'm not sure that not_before/not_after is the best way to
do that.

- The ESNIKeys structure generally seems a bit complicated,
it might be better to aim for simplifying that and maybe
making it more "zonefile friendly" (whether in a TXT RR
or not).

The structure started a bit si= mpler and got new features to
deal with new issues. Specifically:=

- The checksum is intended to deal with corruptio= n
- The keys and cipher suites seem kind of mandatory
-= The padded length is needed to tell the client how much to
=C2= =A0 pad. Though I guess we could always pad to 260. If you don't
<= div>=C2=A0 pad at all, it doesn't work.
- I think it's cl= ear what not_before and not_after are for. If you have
=C2=A0 mor= e concrete feedback about better ways to do that, we'd welcome
=C2=A0 this.
- Extensions is just there because we're tryin= g to be safe.

FWIW, this actually is pretty friend= ly because we b64-encode
(thus making the internal structure opaq= ue to DNS). Removing
things won't make it much smaller becaus= e a big chunk of
the data is in the keys. For instance, in my imp= lementation,
the object is 70 bytes long and 34 bytes of that is = key (X25519)
and 8 bytes is cipher suite (each of these has 2 byt= es of length).



<= br>
- It might be interesting to think about how this'd work
for e.g. the IETF web site (where ietf.org is hosted
locally but www.ietf.org is not), and for STARTTLS and
MX RRs. That's probably ok, but I've not gotten it
straight in my little head yet:-)

I don= 't think we're assuming it applies to subdomains.

=C2=A0
- Would it make sense to include the innocuous dummy sni
in the published RR, so that all clients use the same
one and stand out that bit less?

We act= ually had an "alt-svc" thing in here for that and removed
it at the last minute. I'd welcome input on the best thing here.

=C2=A0
- 7.1 probably needs more work -

The whole= draft needs more work!


I'm not sure that it's
that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE,
or a client application that knows the ESNIKeys, are most
likely needed, but there's probably also some work to do
to analyse the recursive to authoritative interactions to
get the ESNIKeys even with DPRIVE.

&quo= t;OK" might not have been the best choice of words. I think this actua= lly
contains two arguments:

1. You don&#= 39;t need DNSSEC.
2. It doesn't make matters worse to do this= over unencrypted DNS (i.e., you're already
in trouble).

That said, it also doesn't add much value to do ES= NI if the attacker controls your DNS, and in Firefox we're looking init= ially at just doing it when DoH is in use.


Lastly, the topic of whether or not to try address this
problem is something that the WG has debated quite a bit,
and IIRC the consensus after that debate was to do work
on this (hence Christian's draft).

= Thanks for making this point. My understanding was that we had WG consensus= to protect SNI. Of course, it may be the case that the WG doesn't like= this solution for one reason or another -- including potentially that it h= as an especially bad impact on enterprise deployments compared to other app= roaches -- but that seems like a different thing than saying we shouldn'= ;t try to protect SNI at all.

-Ekr

<= /div>


So I don't see any need to debate whether or not to work on
this is needed, and trying to re-open such a debate seems
somewhat disruptive to me. It is entirely reasonable to
consider what, if anything, widespread use of esni or other
approaches might break though. But going back to all this
"privacy at any cost" and "we're the enterprises" h= yperbole
is not at all helpful IMO, so I hope we don't have to suffer
more rounds of that. But maybe that's inevitable with every
iteration of attempts to improve privacy sadly;-(

Cheers,
S.


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

--000000000000cc7b7205702fa612-- From nobody Wed Jul 4 11:07:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4EA3130E30 for ; Wed, 4 Jul 2018 11:07:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PwZwUxImhsO2 for ; Wed, 4 Jul 2018 11:07:50 -0700 (PDT) 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 07FCC130E09 for ; Wed, 4 Jul 2018 11:07:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3953BBE3E; Wed, 4 Jul 2018 19:07:48 +0100 (IST) 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 YiE-MMo0oKmr; Wed, 4 Jul 2018 19:07:46 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A46AEBE38; Wed, 4 Jul 2018 19:07:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1530727666; bh=PIDyuxeFa+3tf+f81eHdQ/Iy6YnVv9N7Tj1dPan60UE=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=w/ddwkxQ/ooNQB/6gUUwV0YyiDT9nssaBfmqHtlU/wEiF6OR7sykPQ4XWn6vzK/4h 69NnlzVY9tvD0IIIPns0r8p1eZsBhYaHiqEBFiWRsJ5cCa5h/d5VLxqWzM1UwO0M8I bxTaw+OI1iTWKtrZUeMoh1jx7gsStqmpUDHXFYLs= To: Eric Rescorla Cc: "" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <76cdb0b7-6a4a-018e-838d-ffce4d02dd7c@cs.tcd.ie> Date: Wed, 4 Jul 2018 19:07:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="P1IbAYR4eZrS4My20VyoIae7cMdeJMxLS" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 18:07:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P1IbAYR4eZrS4My20VyoIae7cMdeJMxLS Content-Type: multipart/mixed; boundary="G9ffeZesEogmCBTmmLrMSqpY8o32a3UKe"; protected-headers="v1" From: Stephen Farrell To: Eric Rescorla Cc: "" Message-ID: <76cdb0b7-6a4a-018e-838d-ffce4d02dd7c@cs.tcd.ie> Subject: Re: [TLS] DNS-based Encrypted SNI References: In-Reply-To: --G9ffeZesEogmCBTmmLrMSqpY8o32a3UKe Content-Type: multipart/mixed; boundary="------------70C73E805503F98BFDEDA884" Content-Language: en-GB This is a multi-part message in MIME format. --------------70C73E805503F98BFDEDA884 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Just on this bit... On 04/07/18 18:20, Eric Rescorla wrote: > The structure started a bit simpler and got new features to > deal with new issues. Specifically: >=20 > - The checksum is intended to deal with corruption I'm not sure I see why that's needed, but I believe you if you say it might help with some home routers. (Though I'd also be interested in information/citation about the details of the problems seen there.) > - The keys and cipher suites seem kind of mandatory Yep. OTOH, given we need to support >1 value for the RR, if mostly people just need one key+CS per-RR, it may be possible to use multiple RRs to provide additional keys/CSes. (If most uses would have a variable number of keys/CSes then I agree the current structure is better.) > - The padded length is needed to tell the client how much to > pad. Though I guess we could always pad to 260. If you don't > pad at all, it doesn't work. Sure. > - I think it's clear what not_before and not_after are for. If you have= > more concrete feedback about better ways to do that, we'd welcome > this. With not_before/not_after (and the TTL) there'll need to be some consideration of the various overlaps, which has been a source of bugs and ops screw-ups in other scenarios. I also don't like the forced expiry of not_after - people will just put in 2038 all over, or risk weird breakage. (X.509's mandatory notAfter was IMO an error for most uses of X.509 - an error inherited from the X.500 DAP user authentication use-case that initially motivated X.509.) I wonder would an incrementing counter (like SOA serial) maybe be easier where the client just uses the highest value? (There was some discussion on related topics during the work on MTA-STS, but I forget the details, might be worth checking with the folks involved.) > - Extensions is just there because we're trying to be safe. Sure, but I hope we consider dropping 'em if there's no need. New RRTYPEs could always be used for extensions (if new RRTYPEs are cheap, that is:-) >=20 > FWIW, this actually is pretty friendly because we b64-encode > (thus making the internal structure opaque to DNS). Removing > things won't make it much smaller because a big chunk of > the data is in the keys. For instance, in my implementation, > the object is 70 bytes long and 34 bytes of that is key (X25519) > and 8 bytes is cipher suite (each of these has 2 bytes of length). That's good. But I was more thinking about how friendly this would be for the DNS admin folks. One thing I like about TLSA and CAA is that (for my use-cases:-) I can just cut'n'paste the values into zone files and they'll be good until a CA root key or name changes, which is pretty rare and would be widely advertised ahead of time. With RRSIGs and similar, I can also easily inspect values by just looking at zonefiles and/or using dig, which is helpful for me at least. But I don't have to deal with large zones so that kind of inspection may not be of much use to larger operators. So, I'd defer to real DNS server folks on whether or not being able to directly view the internals of ESNIKeys encoding makes any difference. All that said, I did just suggest adding in the dummy sni value:-) So I mostly think if this goes ahead (as I hope it does), we spend a bit of time considering the above issues before we're done. Cheers, S. --------------70C73E805503F98BFDEDA884 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------70C73E805503F98BFDEDA884-- --G9ffeZesEogmCBTmmLrMSqpY8o32a3UKe-- --P1IbAYR4eZrS4My20VyoIae7cMdeJMxLS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAls9DPEACgkQWrL68XsX K+r9ow//anhpsFB8BhTjwjBtlx2sFJA/VuuLyTwl8jgYPL0REjjeuijD6EfxrbNo vLpPmKKrOHVXUQhQmqHGkAR3OGmk7SSZs6+50ECIr3X0ZTfxH8TTzeExEq/dHHCq 4lvT/YtTpbTHNL1f6ETe4lVcmE1YygPqjE4e6oJJDgjhqSJJYl3juQsZ8Sl5mOuf SALQcskZ11/cHNnYcmTcR8P0e0lA5RRj8+GOIn1rW8DSn43uMVROLxreKL4Lui5J CeT2ED51d+4rPArtmCKGXuf5TtNq1BAyQMwtjbAYq57IKI+wJGb9BUrGlEinhQLO 1fx168uNbEiNtDAgvLx+54HYcSwlgJIYR3UqsIOKV67qmpy9jNV8sVjvEGGJdzmB kDc6mWhiMXa9M+dY1BV/CKwNV2zjAAouAXaVZGDrkcQ0LE9xM9rlON1U34vNIFwV ycVWy4QFuouvCXT04soCE7Rt96GRdBXjOP1yNusUTwC99YuGdAKZafDrwVpjtNW7 +b2ASais094czB8+8kfMiP1RW8sZVJKoGbNLGclA5Wpm67YxM2udrFKfRVkUWRTR A41Pwl00HiM+/yhWk3e2uejdge9C3IQ1T6qQ3i3LEQ8oK/pbW5yAVn488cXuMRHs rigPS5FnIcA/dyGW9iu7xFYgp8olu2f9jQldr60B2UyQW2NpEhY= =jeLf -----END PGP SIGNATURE----- --P1IbAYR4eZrS4My20VyoIae7cMdeJMxLS-- From nobody Wed Jul 4 11:10:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01736130E09 for ; Wed, 4 Jul 2018 11:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9YYHzKiSTNw for ; Wed, 4 Jul 2018 11:10:21 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34116129619 for ; Wed, 4 Jul 2018 11:10:21 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id y31-v6so5152578qty.9 for ; Wed, 04 Jul 2018 11:10:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+LFSy2OLnj9fLymDpHmlZJOE6U1EV8u9W6llVccAx/c=; b=ik8zpJ35PjgticloIxUK2XiQAd2jL9bDDtFrlHNEcLi0jfTEDzTEHINeqfRa6iU9fZ wYj5n53Fhu5sK9i2XuHNXqDk7fpC73amS9e+CeIkA3dS6UGs3ZaIl7DBKBfFioN4+uQW WKlFWaPV4jXuz4piiT3V/AbDVKk3cph9j7GnnrqDcTMnELoqcsDwKnk/gwYcrq+vmSxQ dDMBzyAaR0CLJqovI7io86C9zq3JGDPSaG68WQ4w9Cs+vIuY/6pH+5ddWi916Q18FEFj ZeETMd+N+AKdWC5ELZTCqgWA7GZDIPonCFI5IuUE5UilCCm8QvSoIZWLFFF4bOXS5Bq8 4oMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+LFSy2OLnj9fLymDpHmlZJOE6U1EV8u9W6llVccAx/c=; b=J/KCARDm9K9PbogTjP0DBN1+kbifr+/aVe26G7FuyHcZR2WmAnrFxMmEak1HKNs5Dk cSvCeE16o/NFJCiqJw8PuVy86RNyWxdXgdctf8h70viF/OlzfzTGvviMOyTL++87tO24 /th+SrrGDPOoXH4w/NRuZwbAMuHRnD0RTWIDyw1wwO3zFS9qCLoiCItz1G63MdPImhba 4W3MQOUgM44GrVhPiBAxO3uPY1buef1TsVoCx51I9z7d34Htuz0pesMfex9YEGYgY98A 8h0g7vSRSiuFTjCurlK3WKNapkD580lGSHpy461QvFJHdzJS6U+66POiAoAOFW0GI+t9 eYZA== X-Gm-Message-State: APt69E3FxtZ6Nz5kjxj1i33fdjF2g6GnkJj2pt++ZicCUCI4Mel79mzO NHki1QA7VUAB99Ek7eVUveY= X-Google-Smtp-Source: AAOMgpcDjwkZOB1S82I/lygtXIvK92h5YyAMmiiRE4HhxfUldcWXL5fel8xvltcoCAC7V10Iy+pWGQ== X-Received: by 2002:ac8:38ac:: with SMTP id f41-v6mr2593164qtc.190.1530727820279; Wed, 04 Jul 2018 11:10:20 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id c9-v6sm2791780qtc.34.2018.07.04.11.10.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 11:10:19 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Wed, 4 Jul 2018 14:10:18 -0400 Cc: Eric Rescorla , "" Content-Transfer-Encoding: quoted-printable Message-Id: <4B10DA3C-9BCB-4546-B3F9-BCC8BA358BD9@gmail.com> References: To: Stephen Farrell Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 18:10:24 -0000 Sent from my mobile device > On Jul 4, 2018, at 9:01 AM, Stephen Farrell wr= ote: >=20 >=20 > Hiya, >=20 >> On 03/07/18 00:39, Eric Rescorla wrote: >> Hi folks, >>=20 >> I just submitted: >>=20 >> https://tools.ietf.org/html/draft-rescorla-tls-esni-00 >=20 > Thanks for writing that up. I think it's an interesting > addition to the set of potential solutions. >=20 >>=20 >> This draft describes a DNS-based approach to doing encrypted SNI. >>=20 >> Previously, we had thought this wouldn't work because only sites that >> were particularly vulnerable would do it, and so the use of ESNI marks >> you out. The idea behind this draft is that there are a lot of sites >> which are hosted by -- and whose DNS is run by -- a large provider, >> and that provider can shift many if not all of its sites to ESNI at >> once, thus removing the "standing out" issue and making a DNS-based >> approach practical. >=20 > I'm not sure I fully understand how this approach would fit > with others, nor to what extent it depends on the DNS and > CDN providers co-operating, but it definitely seems worth > exploring. >=20 >>=20 >> I am working on an implementation for NSS/Firefox and I know some >> others are working on their own implementations, so hopefully we can >> do some interop in Montreal. >>=20 >> This is at a pretty early stage, so comments, questions, defect >> reports welcome. >=20 > Quick comments after flicking through the draft: >=20 > - I'm not that fussed myself as to whether this uses a TXT > or new RRTYPE. But if the latter would work, it seems better. >=20 > - I didn't quite get what "all the domains" in 3.2 means. I > guess if a client uses non-encrypted sni for one of those, > it should still work, but I'm not clear if supporting esni > for any domain means that the provider has to decrypt esni > and then deal with successful decrypted sni values as if > the client had sent sni in clear. A concern is requiring > "all the domains" might make it hard to roll this out. >=20 > - I guess some form(s) of key rollover will be needed, ut > I'm not sure that not_before/not_after is the best way to > do that. >=20 > - The ESNIKeys structure generally seems a bit complicated, > it might be better to aim for simplifying that and maybe > making it more "zonefile friendly" (whether in a TXT RR > or not). >=20 > - It might be interesting to think about how this'd work > for e.g. the IETF web site (where ietf.org is hosted > locally but www.ietf.org is not), and for STARTTLS and > MX RRs. That's probably ok, but I've not gotten it > straight in my little head yet:-) >=20 > - Would it make sense to include the innocuous dummy sni > in the published RR, so that all clients use the same > one and stand out that bit less? >=20 > - 7.1 probably needs more work - I'm not sure that it's > that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE, > or a client application that knows the ESNIKeys, are most > likely needed, but there's probably also some work to do > to analyse the recursive to authoritative interactions to > get the ESNIKeys even with DPRIVE. >=20 > Lastly, the topic of whether or not to try address this > problem is something that the WG has debated quite a bit, > and IIRC the consensus after that debate was to do work > on this (hence Christian's draft). >=20 > So I don't see any need to debate whether or not to work on > this is needed, and trying to re-open such a debate seems > somewhat disruptive to me. It is entirely reasonable to > consider what, if anything, widespread use of esni or other > approaches might break though. But going back to all this > "privacy at any cost" and "we're the enterprises" hyperbole > is not at all helpful IMO, so I hope we don't have to suffer > more rounds of that. But maybe that's inevitable with every > iteration of attempts to improve privacy sadly;-( I=E2=80=99m also fine with the work going forward, however it was only in Ma= rch that EKR assured people concerned that they don=E2=80=99t need to worry a= bout SNI being encrypted repeating similar statements previously made to the= same effect. Meantime, he was working on such a solution. People need war= ning to prepare for changes, not to be surprised by them after being told no= t to worry. They may not have had a chance to think through how they might a= dapt. Kathleen=20 >=20 > Cheers, > S. >=20 >=20 >>=20 >> -Ekr >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 > <0x5AB2FAF17B172BEA.asc> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 4 11:20:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0532A130E30 for ; Wed, 4 Jul 2018 11:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vwSkWyOYQbIY for ; Wed, 4 Jul 2018 11:20:47 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16071294D0 for ; Wed, 4 Jul 2018 11:20:46 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id e23-v6so1671621ywe.13 for ; Wed, 04 Jul 2018 11:20:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=csjrJdckoI9UfvBHvdE9FU2k135+RodwwEgyeZas49Y=; b=EgkRlGUyQ48KNzPTR5GENr5Sg+47PDvcpluOB7qNC0eNeIpttGaqKKofAPCqU4LevM bMvZ5Pd/9URPQAA4HgOfuT2Rd/V/uuN4moNX0SkI7Jk+skfsQFUIFFaRLjxLPJe6suei +NC76olmI8zdTyn4aUh2gOZJ3t3h9pztL4flXG8vxNuAdExLu03lh9S4NEPibzKx1lFS dM8CjJu5Ym0I3MhkPwRgLzWaYMniIVDl0eN/upw465gU67xgTOiZFLNOv1sC7E8BRzh+ r5LuOe48AHLsF/qbcCEgFJ6U04mXWNphHUXGZYBMke8EyrQdivWhDOtaIWquz5tV+vhP XhvA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=csjrJdckoI9UfvBHvdE9FU2k135+RodwwEgyeZas49Y=; b=PiDV8TkhsPOZXhGSrw7ob8zdcixBC8n8b6V7UMHcpj1XMn7mDwr1fOuVFBdw2XKitH Zxkkhu1QhSYloVK3S2iCfVz3TVv9U0U1JpQUnoNh35VqS0EttwS6CIagIgP75R+KUY2c +NTDpTpC9SjKhJtfPHqB830b5EoqLFiocbw9JNi2BBrToMzo0U0+gMwtCacbK4wMEf0v K15t4DLIXOPnv802PPlMJCS38evtpgqtU46hPZ+xkQw9JWqDj2FoGdC/56HMKDhq4U2I fvttZ98OqaXa/x9qCIn3u7IfoKagVg9Xtf31uT/z5KIeapPXEkYzJd1p5uhdOry+8NNi RWAg== X-Gm-Message-State: APt69E1iAZtiTL/jw0hqDJooIQAzJGrZ45G9q6H60BnGwe7vZsTNLseS 9Qvv2ApTlksWPiTSL5dMIoi1n+4KoiUohmfkUAYv/0giqqE= X-Google-Smtp-Source: AAOMgpdVCWKYojOMpYCC1i0WuKp/UxzKlAWMCsrgIsOOG/01w3Z+ewX6l+Q6TmXnu4OPzCHaJQZCATFpAWrx9f/ulsA= X-Received: by 2002:a81:3e02:: with SMTP id l2-v6mr1509249ywa.381.1530728446141; Wed, 04 Jul 2018 11:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 11:20:05 -0700 (PDT) In-Reply-To: <4B10DA3C-9BCB-4546-B3F9-BCC8BA358BD9@gmail.com> References: <4B10DA3C-9BCB-4546-B3F9-BCC8BA358BD9@gmail.com> From: Eric Rescorla Date: Wed, 4 Jul 2018 11:20:05 -0700 Message-ID: To: Kathleen Moriarty Cc: Stephen Farrell , "" Content-Type: multipart/alternative; boundary="00000000000047bbce0570307de7" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 18:20:49 -0000 --00000000000047bbce0570307de7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Kathleen, On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > I=E2=80=99m also fine with the work going forward, however it was only in= March > that EKR assured people concerned that they don=E2=80=99t need to worry a= bout SNI > being encrypted repeating similar statements previously made to the same > effect. Meantime, he was working on such a solution. This is not really correct. As of March, I had basically given up on how to do ESNI in TLS the near future and wasn't really working on it [0] and then in May, prompted by suggestions by Matthew Prince and Nick Sullivan, I realized that the proposal in this document could work. Moreover, I think I've been pretty clear that I wanted to do ESNI and it was just that we didn't know how. For instance, here's what I said in PATIENT: My evaluation of the current state of SNI encryption is that given the current technical state, it will not see particularly wide deployment, with the primary scenario being "at-risk" sites who are subject to censorship who either hide behind or co-tenant with sites which are not subject to censorship. That probably isn't going to be incredibly common right now. Of course, this is regrettable from the perspective of people designing these protocols, but I think that's the situation. As I said the other day, predictions are hard, especially about the future, and this turns out not to have been totally right (though I also don't think it's really accurate to characterize it as my saying that people don't need to worry). I'm sorry if people people are surprised now. That wasn't my intent, but as I said above, I was surprised too! -Ekr [0] Just to be completely clear, there was and is ongoing work on protecting SNI via HTTP connection coalescence (see Mike Bishop's presentation in London), but that's a different flavor of approach, and it's not like it's any secret it's happening. > Kathleen > > > > > Cheers, > > S. > > > > > >> > >> -Ekr > >> > >> > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > >> > > <0x5AB2FAF17B172BEA.asc> > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > --00000000000047bbce0570307de7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Kathleen,

On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> wrote:
I=E2=80=99m also fine with t= he work going forward, however it was only in March that EKR assured people= concerned that they don=E2=80=99t need to worry about SNI being encrypted = repeating similar statements previously made to the same effect.=C2=A0 Mean= time, he was working on such a solution.=C2=A0

<= div>This is not really correct. As of March, I had basically given up on ho= w to do ESNI in TLS the near future and wasn't really working on it [0]= and then in May, prompted by suggestions by Matthew Prince and Nick Sulliv= an, I realized that the proposal in this document could work.

Moreover, I think I've been pretty clear that I wanted = to do ESNI and it was just that we didn't know how. For instance, here&= #39;s what I said in PATIENT:

=C2=A0=C2=A0 My eval= uation of the current state of SNI encryption is that given the
=C2=A0= =C2=A0 current technical state, it will not see particularly wide deploymen= t, with
=C2=A0=C2=A0 the primary scenario being "at-risk" site= s who are subject to censorship who
=C2=A0=C2=A0 either hide behind or c= o-tenant with sites which are not subject to
=C2=A0=C2=A0 censorship. Th= at probably isn't going to be incredibly common right now. Of
=C2=A0= =C2=A0 course, this is regrettable from the perspective of people designing= these
=C2=A0=C2=A0 protocols, but I think that's the situation.
=

As I said the other day, predictions are hard, es= pecially about the future, and this turns out not to have been totally righ= t (though I also don't think it's really accurate to characterize i= t as my saying that people don't need to worry). I'm sorry if peopl= e people are surprised now. That wasn't my intent, but as I said above,= I was surprised too!

-Ekr

[0] Just to be completely clear, there was and is ongoing work on protect= ing SNI via HTTP connection coalescence (see Mike Bishop's presentation= in London), but that's a different flavor of approach, and it's no= t like it's any secret it's happening.


=C2=A0
Kathleen

>
> Cheers,
> S.
>
>
>>
>> -Ekr
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls=
>>
> <0x5AB2FAF17B172BEA.asc>
> __________________= _____________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--00000000000047bbce0570307de7-- From nobody Wed Jul 4 11:24:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8FDE130E07 for ; Wed, 4 Jul 2018 11:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6A4W09Sf5ClO for ; Wed, 4 Jul 2018 11:24:23 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D64AA129619 for ; Wed, 4 Jul 2018 11:24:22 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id p129-v6so2182399ywg.7 for ; Wed, 04 Jul 2018 11:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=86XKBPFIy2GlKsBdlVU36OICcsBJaVP2t+Awskzix88=; b=009+Bp98UiUX/jcRUqGIMKHhRxAEOabGqSopnh3DLIOC/fRvZlurjcdk1x4afumhKb +9onZw9dZgRy48cSeSLi7jL9oCszhmQUSUXJeeDFTpZvdkboes33W25VHQjf82R6vJtR wxTrG5kgwNxbFap+FflGo4IkH2JDQnh06QOInJCEw/6Nfmf1j4y+8e60t0ot3uG5fuMW 8c5ULm33EaNfHIhRJ+hE74bvDvHQs8e5/EgNsdN17bp5V8FADQA15uY672KjMdkhiZvP GrcSKROkn5zVqFURw35REQJCXbQ0Ons57lFfIPIdVmQyvVYThbfWD1hv0ZxjaeP9N3PX 6LiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=86XKBPFIy2GlKsBdlVU36OICcsBJaVP2t+Awskzix88=; b=dMNBu4QDu8skoxWgYOcxZlCoXD86Z2XHsTns0AbwgRAGbYHrmEp0ZFv4kD5JYTOpps dH7tpbQ7PB4a0ZwkuhHOjF8x4hpgkDAdrxm+kK8SigCnH0SI1xK5YiyCtOgmY48kLOOr 5JBt49eyUJpZtFtHfV4IuMs2wx3Zb5qjNcxFUijBDuz7lTOF6QcU/VTwgTIU+vSpyPgH vdF8AKmU6MVTk8HKp7auuZ/u8ypv4qt/x3e7HLcidxVXQqaCg7pNToXdQz94gYMf1lp/ Hs94N1qLPCL6xoN33pVvp9go/2Ceh5ZSAdSOTRgJLV6i1agqOczQKuELwKTQT7/fxmtz deQA== X-Gm-Message-State: APt69E3KqntoAx6BkaM9BLVF5XGsveA3I+VcDWKWbje5kpFSzdscN0jF uTPOFG+ptc+IK/uEcwbEYs0+/o3K/ReGYqRTtyeW6w== X-Google-Smtp-Source: AAOMgpc94ucgWeOsdM9kwAS/qCRCBjhyXs3Rf75gZXXCHRl9R7OTMqtbjLI+7WVxt8mWKRODiDxPebs5AmMbdX5iF74= X-Received: by 2002:a0d:fe07:: with SMTP id o7-v6mr1415447ywf.167.1530728662122; Wed, 04 Jul 2018 11:24:22 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 11:23:41 -0700 (PDT) In-Reply-To: <76cdb0b7-6a4a-018e-838d-ffce4d02dd7c@cs.tcd.ie> References: <76cdb0b7-6a4a-018e-838d-ffce4d02dd7c@cs.tcd.ie> From: Eric Rescorla Date: Wed, 4 Jul 2018 11:23:41 -0700 Message-ID: To: Stephen Farrell Cc: "" Content-Type: multipart/alternative; boundary="000000000000275c7b0570308a89" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 18:24:25 -0000 --000000000000275c7b0570308a89 Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 11:07 AM, Stephen Farrell wrote: > > Hiya, > > Just on this bit... > > On 04/07/18 18:20, Eric Rescorla wrote: > > The structure started a bit simpler and got new features to > > deal with new issues. Specifically: > > > > - The checksum is intended to deal with corruption > > I'm not sure I see why that's needed, but I believe you if > you say it might help with some home routers. (Though I'd > also be interested in information/citation about the > details of the problems seen there.) > Sure. that's a fair question. Kazuho proposed this, so I'd be interested in his view. > > > - The keys and cipher suites seem kind of mandatory > > Yep. OTOH, given we need to support >1 value for the RR, if > mostly people just need one key+CS per-RR, it may be possible > to use multiple RRs to provide additional keys/CSes. (If most > uses would have a variable number of keys/CSes then I agree > the current structure is better.) > I think it's bad to provide multiple options that aren't coupled together. Moreover, from the perspective of the TLS stack, it's actually easier to have them all bundled. > - I think it's clear what not_before and not_after are for. If you have > > more concrete feedback about better ways to do that, we'd welcome > > this. > > With not_before/not_after (and the TTL) there'll need to be some > consideration of the various overlaps, which has been a source of > bugs and ops screw-ups in other scenarios. I also don't like the > forced expiry of not_after - people will just put in 2038 all over, > Note that this is 64 bits, so you can go far past 2038 :) > - Extensions is just there because we're trying to be safe. > > Sure, but I hope we consider dropping 'em if there's no need. > New RRTYPEs could always be used for extensions (if new RRTYPEs > are cheap, that is:-) > I would not be in favor of this. It's trivial to parse and ignore. > (thus making the internal structure opaque to DNS). Removing > > things won't make it much smaller because a big chunk of > > the data is in the keys. For instance, in my implementation, > > the object is 70 bytes long and 34 bytes of that is key (X25519) > > and 8 bytes is cipher suite (each of these has 2 bytes of length). > > That's good. But I was more thinking about how friendly this > would be for the DNS admin folks. One thing I like about TLSA > and CAA is that (for my use-cases:-) I can just cut'n'paste > the values into zone files and they'll be good until a CA root > key or name changes, which is pretty rare and would be widely > advertised ahead of time. > > With RRSIGs and similar, I can also easily inspect values by > just looking at zonefiles and/or using dig, which is helpful > for me at least. But I don't have to deal with large zones so > that kind of inspection may not be of much use to larger > operators. So, I'd defer to real DNS server folks on whether > or not being able to directly view the internals of ESNIKeys > encoding makes any difference. > > All that said, I did just suggest adding in the dummy sni > value:-) So I mostly think if this goes ahead (as I hope it > does), we spend a bit of time considering the above issues > before we're done. > Sure, that seems reasonable. I think you are getting to something important here: my philosophy here is that this should be a more or less opaque blob which you provide to the TLS stack. So I'm optimizing for what's convenient for that. I can understand that others might feel differently. -Ekr > Cheers, > S. > > --000000000000275c7b0570308a89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 11:07 AM, Stephen Farrell <= stephen.farr= ell@cs.tcd.ie> wrote:

Hiya,

Just on this bit...

On 04/07/18 18:20, Eric Rescorla wrote:
> The structure started a bit simpler and got new features to
> deal with new issues. Specifically:
>
> - The checksum is intended to deal with corruption

I'm not sure I see why that's needed, but I believe you if you say it might help with some home routers. (Though I'd
also be interested in information/citation about the
details of the problems seen there.)

Su= re. that's a fair question. Kazuho proposed this, so I'd be interes= ted in his view.

> - The keys and cipher suites seem kind of mandatory

Yep. OTOH, given we need to support >1 value for the RR, if
mostly people just need one key+CS per-RR, it may be possible
to use multiple RRs to provide additional keys/CSes. (If most
uses would have a variable number of keys/CSes then I agree
the current structure is better.)

I thi= nk it's bad to provide multiple options that aren't coupled togethe= r.
Moreover, from the perspective of the TLS sta= ck, it's actually easier
to have them= all bundled.


<= span class=3D"">

= > - I think it's clear what not_before and not_after are for. If you= have
>=C2=A0 =C2=A0more concrete feedback about better ways to do that, we= 9;d welcome
>=C2=A0 =C2=A0this.

With not_before/not_after (and the TTL) there'll need to be some=
consideration of the various overlaps, which has been a source of
bugs and ops screw-ups in other scenarios. I also don't like the
forced expiry of not_after - people will just put in 2038 all over,

Note that this is 64 bits, so you can go far p= ast 2038 :)


> - Extensions is just there because we're trying to be safe.

Sure, but I hope we consider dropping 'em if there's no need= .
New RRTYPEs could always be used for extensions (if new RRTYPEs
are cheap, that is:-)

I would not be in= favor of this. It's trivial to parse and ignore.


<= /div>
> (thus making the internal structure opaque to DNS). Removing
> things won't make it much smaller because a big chunk of
> the data is in the keys. For instance, in my implementation,
> the object is 70 bytes long and 34 bytes of that is key (X25519)
> and 8 bytes is cipher suite (each of these has 2 bytes of length).

That's good. But I was more thinking about how friendly this
would be for the DNS admin folks. One thing I like about TLSA
and CAA is that (for my use-cases:-) I can just cut'n'paste
the values into zone files and they'll be good until a CA root
key or name changes, which is pretty rare and would be widely
advertised ahead of time.

With RRSIGs and similar, I can also easily inspect values by
just looking at zonefiles and/or using dig, which is helpful
for me at least. But I don't have to deal with large zones so
that kind of inspection may not be of much use to larger
operators. So, I'd defer to real DNS server folks on whether
or not being able to directly view the internals of ESNIKeys
encoding makes any difference.

All that said, I did just suggest adding in the dummy sni
value:-) So I mostly think if this goes ahead (as I hope it
does), we spend a bit of time considering the above issues
before we're done.

Sure, that seems= reasonable. I think you are getting to something
important here:= my philosophy here is that this should be a more
or less opaque = blob which you provide to the TLS stack. So I'm
optimizing fo= r what's convenient for that. I can understand that
others mi= ght feel differently.

-Ekr


Cheers,
S.


--000000000000275c7b0570308a89-- From nobody Wed Jul 4 14:25:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E93A4130E03 for ; Wed, 4 Jul 2018 14:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bnKTlT6jGMG7 for ; Wed, 4 Jul 2018 14:25:54 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23C8E124BE5 for ; Wed, 4 Jul 2018 14:25:54 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id c192-v6so3485256qkg.12 for ; Wed, 04 Jul 2018 14:25:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=trXHVJmuPJW5G14YiB2HKEzOkTF0s7Zu9sF4KmDl9EI=; b=VjaWrEJi9pD5JFligGbLCQ4PwbqiKNqJLqsbOa11HNikcI50rmbK8TB7TgikZTDbwO esaiuds5TKI/02tfMtC0ts+uoA4TQPpDnKqzkIIUuZNw27fuMB5c3jh4QKQRGoKHdFdw Bb5jCmEjCaTmBVCioz1nQvNXTurj+2Tf3YNXEdF58k87mdlXh10DcO4Ylhhozr0UKsPe QBN6BZvAMuu1IXZB/TEoFLilBDQoRuc09juG4VlP4ZweoHPlFTQ7s5tABoubKNAyFKUL GQb70UDvmjLKuCKk+MqzTQmEQbIvKAKzEIR73BAvKoxefeJn3dzCtCxWwzbu01DVeKlh /DIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=trXHVJmuPJW5G14YiB2HKEzOkTF0s7Zu9sF4KmDl9EI=; b=mpDXLJMOUEkn0FN8vLcBvzyRWwX+9DJSTvEpQvaQTCvrjhEIiWtQave9joVMNmOBCI x9/Siv0RMl/IA7brSq11jbUU8kStxKxYyU3rlhN/9u42u1/WL+eWMJqN3Jb34eF1SDDt yBn148Z7tNFx3pPLWivn5dFqqXCbvgzWxdh3rDzkOXAHczZZxg1k1trn4ltSx3pe6jeb JUaewEQVuwUGcHLCTPShUknGCo9ljVsKi0+4mqyqNOTYrjr/mXaTMnwuHbO35qhMGopP rye3y1IqkBWBypfDFJDtL2cVhBX14UQ5RbEMn96NSPeRWzgDAk8OlfYFR5ocm2QbAVpM n/bQ== X-Gm-Message-State: APt69E0+pdKH6j+fFwkZLBvHzuXRlXKsXnPOuHnoUQ6PrHLjPOho348L cwPbkWYzczTKi/5spguhOQsMNBtj X-Google-Smtp-Source: AAOMgpcMI4lOg93qU+B55eIJMWA7GKVzVIE4KF7CV+UuLxUW1g5ZfjsOov6zmdzInMFRPL4W3eoY9g== X-Received: by 2002:a37:6e82:: with SMTP id j124-v6mr3020945qkc.179.1530739552994; Wed, 04 Jul 2018 14:25:52 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id c127-v6sm2979684qkd.40.2018.07.04.14.25.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 14:25:52 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-322D5B88-98EC-4EF4-B67B-3F3ED377C546 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Wed, 4 Jul 2018 17:25:51 -0400 Cc: Stephen Farrell , "" Content-Transfer-Encoding: 7bit Message-Id: References: <4B10DA3C-9BCB-4546-B3F9-BCC8BA358BD9@gmail.com> To: Eric Rescorla Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 04 Jul 2018 21:25:57 -0000 --Apple-Mail-322D5B88-98EC-4EF4-B67B-3F3ED377C546 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sent from my mobile device > On Jul 4, 2018, at 2:20 PM, Eric Rescorla wrote: >=20 > Hi Kathleen, >=20 >> On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty wrote: >> I=E2=80=99m also fine with the work going forward, however it was only in= March that EKR assured people concerned that they don=E2=80=99t need to wor= ry about SNI being encrypted repeating similar statements previously made to= the same effect. Meantime, he was working on such a solution.=20 >=20 > This is not really correct. As of March, I had basically given up on how t= o do ESNI in TLS the near future and wasn't really working on it [0] and the= n in May, prompted by suggestions by Matthew Prince and Nick Sullivan, I rea= lized that the proposal in this document could work. >=20 > Moreover, I think I've been pretty clear that I wanted to do ESNI and it w= as just that we didn't know how. For instance, here's what I said in PATIENT= : >=20 > My evaluation of the current state of SNI encryption is that given the > current technical state, it will not see particularly wide deployment, w= ith > the primary scenario being "at-risk" sites who are subject to censorshi= p who > either hide behind or co-tenant with sites which are not subject to > censorship. That probably isn't going to be incredibly common right now= . Of > course, this is regrettable from the perspective of people designing th= ese > protocols, but I think that's the situation. >=20 > As I said the other day, predictions are hard, especially about the future= , and this turns out not to have been totally right (though I also don't thi= nk it's really accurate to characterize it as my saying that people don't ne= ed to worry). I'm sorry if people people are surprised now. That wasn't my i= ntent, but as I said above, I was surprised too! >=20 Well, the messages on the Effects of Pervasive Encryption for Operators also= factored into my response. You wanted that text removed and we refused (ri= ghtly so). You also had someone write a blog to have a reference that talke= d about it=E2=80=99s wide deployment. The perception is from multiple inter= actions and I favor transparency. Best, Kathleen=20 > -Ekr >=20 > [0] Just to be completely clear, there was and is ongoing work on protecti= ng SNI via HTTP connection coalescence (see Mike Bishop's presentation in Lo= ndon), but that's a different flavor of approach, and it's not like it's any= secret it's happening. >=20 >=20 > =20 >> Kathleen=20 >>=20 >> >=20 >> > Cheers, >> > S. >> >=20 >> >=20 >> >>=20 >> >> -Ekr >> >>=20 >> >>=20 >> >>=20 >> >> _______________________________________________ >> >> TLS mailing list >> >> TLS@ietf.org >> >> https://www.ietf.org/mailman/listinfo/tls >> >>=20 >> > <0x5AB2FAF17B172BEA.asc> >> > _______________________________________________ >> > TLS mailing list >> > TLS@ietf.org >> > https://www.ietf.org/mailman/listinfo/tls >=20 --Apple-Mail-322D5B88-98EC-4EF4-B67B-3F3ED377C546 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Sent= from my mobile device

On Jul 4, 2018, at 2:20 PM, Eric Rescor= la <ekr@rtfm.com> wrote:

Hi Kathleen,

On Wed, Jul 4, 2018 a= t 11:10 AM, Kathleen Moriarty <kathleen.moriarty.ietf@gmail.c= om> wrote:
I=E2=80=99m also fine with the work going forward, however it was only in M= arch that EKR assured people concerned that they don=E2=80=99t need to worry= about SNI being encrypted repeating similar statements previously made to t= he same effect.  Meantime, he was working on such a solution. 

This is not really correct. As of March, I had b= asically given up on how to do ESNI in TLS the near future and wasn't really= working on it [0] and then in May, prompted by suggestions by Matthew Princ= e and Nick Sullivan, I realized that the proposal in this document could wor= k.

Moreover, I think I've been pretty clear tha= t I wanted to do ESNI and it was just that we didn't know how. For instance,= here's what I said in PATIENT:

   My eva= luation of the current state of SNI encryption is that given the
 &n= bsp; current technical state, it will not see particularly wide deployment, w= ith
   the primary scenario being "at-risk" sites who are subje= ct to censorship who
   either hide behind or co-tenant with si= tes which are not subject to
   censorship. That probably isn't= going to be incredibly common right now. Of
   course, this is= regrettable from the perspective of people designing these
   p= rotocols, but I think that's the situation.

As I= said the other day, predictions are hard, especially about the future, and t= his turns out not to have been totally right (though I also don't think it's= really accurate to characterize it as my saying that people don't need to w= orry). I'm sorry if people people are surprised now. That wasn't my intent, b= ut as I said above, I was surprised too!


Well, the messages on the Effects= of Pervasive Encryption for Operators also factored into my response.  = ;You wanted that text removed and we refused (rightly so).  You also ha= d someone write a blog to have a reference that talked about it=E2=80=99s wi= de deployment.  The perception is from multiple interactions and I favo= r transparency.

Best,
Kathleen 
=
-Ekr

[0] Ju= st to be completely clear, there was and is ongoing work on protecting SNI v= ia HTTP connection coalescence (see Mike Bishop's presentation in London), b= ut that's a different flavor of approach, and it's not like it's any secret i= t's happening.


 
Kathleen

>
> Cheers,
> S.
>
>
>>
>> -Ekr
>>
>>
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls >>
> <0x5AB2FAF17B172BEA.asc>
> ___________________= ____________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail-322D5B88-98EC-4EF4-B67B-3F3ED377C546-- From nobody Wed Jul 4 17:07:02 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C23130E75 for ; Wed, 4 Jul 2018 17:06:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsEMbS05FatE for ; Wed, 4 Jul 2018 17:06:58 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54754130E6B for ; Wed, 4 Jul 2018 17:06:58 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id c6-v6so13507888oiy.0 for ; Wed, 04 Jul 2018 17:06:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kd9+3+IG9DIXBJz+R7FpZqnnLeF5usO+2ieK53Sib7c=; b=GjfxYr5k+D1k+vr+60ha1LSgnlQ8hwMlPPmm2sQ3JkW6vnUoZ6Gs9AR6yGPjYvJMrD 8caYT2uW06aa3UIYOIRllwMBPKU3EKOLKZBe3df+VjoVxH8Qdn284moHG7I1VI+fI+Cc ezLG64NdcZNUVr5G9rXCGQazlf9TlYO/A4Mdkw8+cxDJ/ckCybt0CAtMuHBAfQ0ouqok P2ixQyBP9p37qxiC+CVRkaQ3ua0lCD27UUb/4htMz55WckiG7t8SUCmNbDUR91S6aQji JrfiXHgRGloBHxNG2G0K4bhkIvoxul/f8X3onPeMHAs45z/b8WwX+Di8NIeiwUTHgWTo XITA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kd9+3+IG9DIXBJz+R7FpZqnnLeF5usO+2ieK53Sib7c=; b=b+vOt/gnWCJpPprUWFLtB4KbIDMLR8FVLSPht2tayUAogZcRC/sc/eZ743xsqPkWIe 4QxriuD7TDtvqtw1jCR2WHbkmQhzd/8R+uMDfau6WmT2wEOd2Hmrj10zhcK2tP4UwlLi DPnGVgkwQienZ4S4RC+miZICr9KM4iZB7cwtKKGRh8k+oqLCtteflhVygMQv7Wf0NmGu yz+mFAK4iRVJKAG+HW4+OqQeW2+eNaGRoyOW5ibva/FjN1T1WE4Dh5BrmgtIs27sfcjj xJfBItSLRIHQiV9hYlwKS1BseCc+AHAUjAifVhW61elJ/EEX/BupAAAVcx4QVMv1ltIw xA0w== X-Gm-Message-State: APt69E2jCZgEgq9mN7M/+tY9hsSKR7Y3FVBofksrseIZ5P3s2KvErBSE 9ufCXpZNH3jzeuEefUoLHjVPcNhbjfIf2k1UjtM= X-Google-Smtp-Source: AAOMgpfqRhyB2ndJpOcGo0fuJJW3yFOKtdPPM30Dn+6lP53qdT/Si7arN4PL3ARxsRt7ot+phgKbgv7D+FP7D52aQU8= X-Received: by 2002:aca:3954:: with SMTP id g81-v6mr4638530oia.215.1530749217534; Wed, 04 Jul 2018 17:06:57 -0700 (PDT) MIME-Version: 1.0 References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> In-Reply-To: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> From: Martin Thomson Date: Thu, 5 Jul 2018 10:06:45 +1000 Message-ID: To: Hubert Kario Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Malformed Finished handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 00:07:00 -0000 On Wed, Jul 4, 2018 at 7:55 PM Hubert Kario wrote: > Despite this, is it correct to terminate a connection with "illegal_parameter" > upon receiving a Finished handshake message with a 100 byte payload? or a 20 > byte payload? My opinion is that it is not, "decode_error" is more specific so > it should be used instead. When there are multiple problems with a message, why do we need to accept just one of the possible alerts? That assumes either a very particular order of processing, or a strict precedence order for errors. Like Rich says, there is a degree of imprecision in our error reporting, but - for me - that's OK. From nobody Wed Jul 4 18:29:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FFA7130E77 for ; Wed, 4 Jul 2018 18:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niCEdESlE-MO for ; Wed, 4 Jul 2018 18:29:10 -0700 (PDT) Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::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 C16C01292F1 for ; Wed, 4 Jul 2018 18:29:09 -0700 (PDT) Received: by mail-lj1-x22f.google.com with SMTP id c12-v6so5424318ljj.1 for ; Wed, 04 Jul 2018 18:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VkrJb6DAv7O7K2FIkjHqRK5dUeXEq7nMyRuq527FG/g=; b=Fhbomd1cACIvgcgdFBwKtTIx9DcHZz/jPCgVkISTfYA12k8a+JxR5qzbAk+RlZ1ezq wBo/j78HgRSfhanDSugBhkev2rSjMWqWQCodi3KCX0WU3PwEZ/4aR13auTfqBhpcnsq0 jDQJK9KJjeScdQcOpTDCFVDGI9NyTbvv9lYq3uY+dsQJdwn8b5VQHNvrOnqaMQmM86+C efmia8ri6fAokES5uwu8wYVjAUCUSasERIeW74+bgItK3VRyHRZsPT6GCM/fwJe6ta+E 39Wyr8iBHPm2uGlh/aI8bL3dXUv5NWa8EsSG80uUoGvTaBGeyGQqfZUp6i1tPSJpne9H PWMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VkrJb6DAv7O7K2FIkjHqRK5dUeXEq7nMyRuq527FG/g=; b=Lrt6o7U8p2R9U730ozGWMSAtfBJyXH+wNGpItCA1iiR4QlIel2jqykgRtMlfp5/3J5 U/z9SbpkH2mXqNXmbo+wYsV4uWUXjUU4IhHAcUP9olRL1I7DnmEToZp7LLwOC0+DKf8y lcIYFb2bpJiU2tbKmPSkd8y0mStJ4TKwCWt+PPkdiIoDb42WqJUyAJO+rrBVuZgncEN5 7kQyTfK5fSuaWeQJut0tk5quTfo02z5pNMXOeFUJqAAtfoO96J0NG9aKCjfsZ2QB0NSz qxSYlBS7rymUeERqv23x6sFO1RiUQNqYNoFuvQngLQKnkirHRNfqrQjRfI5BeSFa67+6 btzg== X-Gm-Message-State: APt69E1ElAwn48BEXCCFxJOlhH94/x30L4HZyhiNHspcLpMlQwPyCElb z7G/65YHa7At6S0OMyjzN2Rm7XansQespegLB4U= X-Google-Smtp-Source: AAOMgpdulzNNUM0Wy9UvN+Atcjd/kTDWfqnQDDHWjDA4HjpBbrWe0kQsHYMuEFqf/tigEgJKCXOWLx5lwz7bgNP2ozw= X-Received: by 2002:a2e:944e:: with SMTP id o14-v6mr2687646ljh.118.1530754147906; Wed, 04 Jul 2018 18:29:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 18:29:06 -0700 (PDT) In-Reply-To: References: <76cdb0b7-6a4a-018e-838d-ffce4d02dd7c@cs.tcd.ie> From: Kazuho Oku Date: Thu, 5 Jul 2018 10:29:06 +0900 Message-ID: To: Eric Rescorla Cc: Stephen Farrell , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 01:29:13 -0000 2018-07-05 3:23 GMT+09:00 Eric Rescorla : > > > On Wed, Jul 4, 2018 at 11:07 AM, Stephen Farrell > wrote: >> >> >> Hiya, >> >> Just on this bit... >> >> On 04/07/18 18:20, Eric Rescorla wrote: >> > The structure started a bit simpler and got new features to >> > deal with new issues. Specifically: >> > >> > - The checksum is intended to deal with corruption >> >> I'm not sure I see why that's needed, but I believe you if >> you say it might help with some home routers. (Though I'd >> also be interested in information/citation about the >> details of the problems seen there.) > > > Sure. that's a fair question. Kazuho proposed this, so I'd be interested in > his view. IMO, when used, ESNIKeys is part of the handshake, and therefore deserves (at least) the same level of end-to-end integrity protection as what is provided by TCP. ESNIKeys becomes part of the handshake in the following sense: * a corrupt ESNIKeys will cause the handshake to fail * ENSIKeys is used to negotiate the use of a TLS extension * the value of ESNIKeys is part of the handshake transcript though `EncryptedSNI.record_digest` which is a full digest of ESNIKeys, much like the 1st CH when HRR is involved TLS records (even the non-encrypted ones) are resistant to accidental corruption thanks to the integrity check provided by TCP. OTOH, ESNIKeys is transmitted though DNS authoritative server (by setting up the DNS record either automatically or by hand), then a recursive resolver, then a stub resolver, before reaching the client. As Stephen says, some resolvers (e.g. home routers) could be the source of corruption of DNS records. But even if we bypass them by using DoH or DNS over TLS, the lack of end-to-end integrity check will still be an issue. Corruption could for example happen when the record is installed to the authoritative server, or when they are stored (or cached) within the resolvers. Considering the varying degree of the reliability provided by the multiple parties involved in forwarding the ESNIKeys as DNS records, my perception has been that it is a good idea to have end-to-end integrity protection. >> > - The keys and cipher suites seem kind of mandatory >> >> Yep. OTOH, given we need to support >1 value for the RR, if >> mostly people just need one key+CS per-RR, it may be possible >> to use multiple RRs to provide additional keys/CSes. (If most >> uses would have a variable number of keys/CSes then I agree >> the current structure is better.) > > > I think it's bad to provide multiple options that aren't coupled together. > Moreover, from the perspective of the TLS stack, it's actually easier > to have them all bundled. I also prefer them to be bundled, because it makes us easier and faster to detect downgrade attacks. Current draft uses a full digest of ENSIKeys (i.e. `EncryptedSNI.record_digest`) to identify the ESNIKeys being used. If a middlebox drops some key-share from ESNIKeys, the server will fail to identify the ESNIKeys being used, and the handshake fails. This would be the case even when DNSSEC is _not_ used. If we use different DNS record for every key-share being negotiated, the client will be required to wait for the response of all the queries it has sent (more likely to suffer from delays), and there will be no protection against a downgrade attack when DNSSEC is not used. >> > - I think it's clear what not_before and not_after are for. If you have >> > more concrete feedback about better ways to do that, we'd welcome >> > this. >> >> With not_before/not_after (and the TTL) there'll need to be some >> consideration of the various overlaps, which has been a source of >> bugs and ops screw-ups in other scenarios. I also don't like the >> forced expiry of not_after - people will just put in 2038 all over, > > > Note that this is 64 bits, so you can go far past 2038 :) FWIW, the intent of having not_after in the draft is to avoid issues when a DNS authoritative server and the TLS server (i.e. the entity that generates the ESNIKeys) get out-of-sync [1]. When the TLS server rotates the ESNIKeys (which should happen frequently), it needs to make sure that all the authoritative servers receive the update. If that attempt fails, we'd rather fallback to plaintext SNI rather than seeing handshake failures. Minimizing (or nullifying) the increased chance of seeing handshake failures is important for ESNI, because we want as many domains as possible (even those that are not strongly interested in having their SNI protected) to participate in the effort; otherwise, the domains using ESNI will "stick out" [2]. However, DNS as a standard does not provide a way to set absolute expiration dates. Not only the responses to queries but also AFXR carries only the TTL. Therefore, an out-of-sync authoritative server will continue to respond with the outdated ESNIKeys. The fact makes it harder for server administrators to manage the keys. To summarize, what we want is consistency (stop sending valid ESNIKeys when authoritative servers get out-of-sync) over availability (continue sending ESNIKeys when out-of-sync), which is contrary to what DNS tries to provide. Considering that and also the fact that we might want to distribute ESNIKeys using methods other than DNS, I think it is a good idea to have not_after (and not_before) in the specification. [1] https://github.com/ekr/draft-rescorla-tls-esni/pull/23 [2] https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03#section-3.4 > > >> > - Extensions is just there because we're trying to be safe. >> >> Sure, but I hope we consider dropping 'em if there's no need.. >> New RRTYPEs could always be used for extensions (if new RRTYPEs >> are cheap, that is:-) > > > I would not be in favor of this. It's trivial to parse and ignore. > > >> > (thus making the internal structure opaque to DNS). Removing >> > things won't make it much smaller because a big chunk of >> > the data is in the keys. For instance, in my implementation, >> > the object is 70 bytes long and 34 bytes of that is key (X25519) >> > and 8 bytes is cipher suite (each of these has 2 bytes of length). >> >> That's good. But I was more thinking about how friendly this >> would be for the DNS admin folks. One thing I like about TLSA >> and CAA is that (for my use-cases:-) I can just cut'n'paste >> the values into zone files and they'll be good until a CA root >> key or name changes, which is pretty rare and would be widely >> advertised ahead of time. >> >> With RRSIGs and similar, I can also easily inspect values by >> just looking at zonefiles and/or using dig, which is helpful >> for me at least. But I don't have to deal with large zones so >> that kind of inspection may not be of much use to larger >> operators. So, I'd defer to real DNS server folks on whether >> or not being able to directly view the internals of ESNIKeys >> encoding makes any difference. >> >> All that said, I did just suggest adding in the dummy sni >> value:-) So I mostly think if this goes ahead (as I hope it >> does), we spend a bit of time considering the above issues >> before we're done. > > > Sure, that seems reasonable. I think you are getting to something > important here: my philosophy here is that this should be a more > or less opaque blob which you provide to the TLS stack. So I'm > optimizing for what's convenient for that. I can understand that > others might feel differently. > > -Ekr > >> >> Cheers, >> S. >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Kazuho Oku From nobody Wed Jul 4 18:35:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874CF130E59 for ; Wed, 4 Jul 2018 18:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FrQa-bjWx_32 for ; Wed, 4 Jul 2018 18:35:26 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B242F130E68 for ; Wed, 4 Jul 2018 18:35:26 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id e23-v6so1921292ywe.13 for ; Wed, 04 Jul 2018 18:35:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mq1p9wWtxns87HUKgYQv266otGNy+A8DmYYtgRXITwI=; b=mtp9Gt5mqNPKd/nrzrCqq3W22243COLx0KmKNlXa2jnhhbogxqOEHI3+9nrWebc8x5 9xisIedROkS1gj50FwCWc+qtJAdnXvdQ8ColtOF2Ay782sezuuMf/bYmnGIa2w45qK+u 2C39733iDktj4s9Tj7uRwQuZF61Lfr08JJgbCQsthAsoLUcFoe7hjAkMeP8RUEv1Ocav 3jcTWEFZdy1Lr8M9dFUYaLil/QQXcx2BzrQata5eOHjl0J8/0140gA6YdHd06cMSNQyC mBtNSjTfpv7+4TdOzxgA2CZ6Z3UMTCKtI3YTSfa4Ox3yv76N9syNyW0rSS6tEsU8xuXk 12hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mq1p9wWtxns87HUKgYQv266otGNy+A8DmYYtgRXITwI=; b=oF6OeRa32VcCMhVMpX8gD6jnewxCUFsPMkCvTnEYEV+DBRq+zrCUTT/ylwZ2GNCWew zRLFwFQk1oPQ7r4Up2VbQ+uy0WmDTucq9UfGwMqGKbmaul8vfmFG+tUU2+4yTYdrinBe 1sNvAyJwCQa8cxjOTfVOp4h76enQP7mKVVsKOGtooo+txkJf05xajPJtqL5BnQq8sPc5 KQDUPR5QXfH6f+FXfGWhmfeqLTDSUGAVrntJpR4/8DvFJ3QQ9psZYQ0SdFMaF6qWZexn jx1iGiiIYI2bvVsPnKy3KUrtHphKalL2gRjmNvkoGuTZ9uHsL2fx1ScltQM3R56yYAnA vb/w== X-Gm-Message-State: APt69E0sfleP8cajCUE4AbZbS0XtSL4Mepr3cEk6lDWXKI7jl2ArDRCE iF0OBaU1Xd+cBtcgk3psbROaE8X6j7tiFtPQTCUeNg== X-Google-Smtp-Source: AAOMgpfN41VY6K/6F4YYWzeL0Ibpjp2W8DRskfFqADTxqH9A3xJBKm57aobEZobAwGMX9+dgX4/In94119cEdrYwe74= X-Received: by 2002:a0d:fe07:: with SMTP id o7-v6mr1890300ywf.167.1530754525471; Wed, 04 Jul 2018 18:35:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 18:34:44 -0700 (PDT) In-Reply-To: References: <20180604203947.GW13834@akamai.com> From: Eric Rescorla Date: Wed, 4 Jul 2018 18:34:44 -0700 Message-ID: To: Joseph Salowey Cc: Paul Wouters , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000bac2b60570368f2e" Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 01:35:31 -0000 --000000000000bac2b60570368f2e Content-Type: text/plain; charset="UTF-8" On Mon, Jun 25, 2018 at 9:20 PM, Joseph Salowey wrote: > Hi Folks, > > There has been some discussion with a small group of folks on github - > https://github.com/tlswg/dnssec-chain-extension/pull/19. I want to make > sure there is consensus in the working group to take on the pinning work > and see if there is consensus for modifications in the revision. Please > respond to the following questions on the list by July 10, 2018. > > 1. Do you support the working group taking on future work on a pinning > mechanism (based on the modifications or another approach)? > Unsure. I'd like to see some real evidence that it will be widely consumed. Do we have a count of major implementors who say they will do so? 2. Do you support the reserved bytes in the revision for a future pinning > mechanism? > No. I'm undecided on whether we should have an extension point here, but I'm strongly against having it just be opaque reserved bytes. Everywhere else we have decided to put extension points, we've had them as Extensions, not just "here are some bytes". Aside from this being general TLS practice, it is good futureproofing because one can grease Extensions, whereas you cannot grease opaque bytes. 3. Do you support the proof of denial of existence text in the revision? > The mechanism seems fine, but it doesn't seem to me that the specification is clear on what the semantics are. I think what they are is that you can configure the client to be in some "DNSSEC required" mode which will requires that the extension be returned and that it either (a) contain DNSSEC-signed records for the domain or (b) contain authenticated denial of existence. Is this correct? If so, I would be happy to have the text merged and then wordsmith this explanation. 4. Do you support the new and improved security considerations? > They seem like a good start. I'd be happy to have them merged and wordsmith them. -Ekr > Thanks, > > Joe > > > > On Tue, Jun 5, 2018 at 6:51 AM, Paul Wouters wrote: > >> On Mon, 4 Jun 2018, Benjamin Kaduk wrote: >> >> Hi Ben, >> >> I've taken a stab at putting together some security considerations text >>> for >>> draft-ietf-tls-dnssec-chain-extension that reflects my understanding of >>> the >>> current state of affairs. It's in a pull request at >>> https://github.com/tlswg/dnssec-chain-extension/pull/19 , along with >>> Viktor's >>> commit to update the text about the actual DNS records involved (which as >>> far as I can tell seems to improve the technical accuracy of the text), >>> and >>> also inserting a variable-length array that's reserved for future >>> attempts >>> to mitigate the (now-)documented security considerations. >>> >> >> Thanks for writing the proposed text. The new opaque Reserved field >> along with the denial of existence changes you propose addresses all >> my concerns. >> >> One corner case that might be worth mentioning with the proposed DoE text >> is the odd corner case of hitting a server with a Host header for which >> it is not configured. You will hit the "default vhost" but you have no >> appropriate extension data to populate for that hostname. So either the >> server will return the (cached) TLSA/DoA data of the 'wrong' hostname, >> or it could just omit the extension. I'd mostly like to say something to >> prevent an implementation of forgetting this corner case and causing >> some vulnerability in their code later on by pointing to bogus memory or >> crashing on dereferencing a NULL. >> >> Some nits: >> >> If the server supports this extension it performs the appropriate >> DNS queries, >> >> In my PR I had changed this into "obtains the appropriate DNS RRsets", >> because I envision that TLS servers might not do DNS lookups themselves, >> but just read this via a file or other method. Eg a cron job that >> regenerates these hourly for all the hosted domains. It also reduces >> some fear that all TLS servers suddenly could need to link against >> a DNSSEC library. They don't if they can just reload a blob from disk >> regularly to serve up. >> >> Similarly: >> >> it will need to rebuild >> >> is better written as "it will need rebuilt data" >> >> >> "authenticates the chain" >> >> That should probably be "validate the chain", but the document has more >> mixups of validate vs authenticate. In my PR request I had not corrected >> them in an effort to keep the diff as small as possible. >> >> I had modified the examples slightly, so the NSEC example would show a >> simpler NSEC chain (from www to zzz) instead of the one wrapping around >> from www to the zone apex. The example quoted is the wrong NSEC record >> (the one from apex to www.example.com does not show that the >> _443._tcp.www.example.com does not exist, you need the one from >> www..example.com to the apex at the end of the >> zone) >> >> >> I'm not sure what you mean with: >> >> validated negative TTL >> >> I guess you mean to say the shortest TTL of any data in the chain? But >> sometimes the negative cache time is larger then the TTL (eg if TTL = 0) >> Since this is just generic DNS handling, I would probably just write >> something like "up to the appropriate lifetime" and leave it out of >> this document. >> >> denial of existence RRset >> >> Technically that should be "RRsets" since you usually will need more then >> one RRset to prove this (to disprove existence of the wildcard record) >> >> - DNSSEC authentication chain extension from a server, >> SHOULD use this >> + DNSSEC authentication chain extension from a server, uses >> this >> >> I'm not sure why the SHOULD was removed here? Since it is describing TLS >> client behaviour the "uses this" confuses me as I dont know if that >> means MAY, SHOULD or MUST. >> >> + Specifically, the relevant DANE records are included >> + in the TLS handshake transcript hash, so both sides >> + possess identical records; >> >> I'm not sure why you suggest to add this text. A TLS client might still >> have cached a valid TLSA records from a previous connection 1 second >> ago and might decide to not use this information at all. Also, it seems >> to suggest that the transscript hash protects this data, but it is >> "protection" using the webpki or proof of lack of MITM, but the data >> does not need this protecting as it is protected by DNSSEC signatures. >> >> + the client remains responsible >> + for actually performing the domain name validation of >> + the DANE records. >> >> Well, if it just fired up a previous TLS connection, perhaps it will be >> content with the same pubkey used and skip re-validating this data? I >> guess we sort of say the same thing due to the lack of a MUST ? >> >> + The Reserved field is reserved for future updates to this >> + document; in particular it is hoped that the issues discussed >> + in can be addressed. >> + Implementations of this specification MUST send a zero-length >> vector >> >> Perhaps that last line can be clarified a bit: >> >> Implementation not implementing any updates to this document >> MUST send a zero-length vector >> >> This sentence does not parse: >> >> "whether or not to the exclusion" >> >> This text is a little confusing to me: >> >> + certified by the DNS key hierarchy, that the >> + server does not support DANE authentication >> >> The TLS server itself might support "DANE authentication", but there is >> simply no data. Perhaps say that the server's configured hostname does >> not support DANE authentication? >> >> Thanks again for the write up! >> >> Paul >> >> >> _______________________________________________ >> 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 > > --000000000000bac2b60570368f2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 25, 2018 at 9:20 PM, Joseph Salowey <<= a href=3D"mailto:joe@salowey.net" target=3D"_blank">joe@salowey.net>= wrote:
Hi Folks,

There has been some discussion with a small group of fo= lks on github -=C2=A0https://gith= ub.com/tlswg/dnssec-chain-extension/pull/19.=C2=A0 =C2=A0I want to= make sure there is consensus in the working group to take on the pinning w= ork and see if there is consensus for modifications in the revision.=C2=A0 = Please respond to the following questions on the list by July 10, 2018.=C2= =A0

1.=C2=A0 Do you suppor= t the working group taking on future work on a pinning mechanism (based on = the modifications or another approach)?

Unsure. I'd like to see some real evidence that it will be wid= ely consumed. Do we have a count of major implementors who say they will do= so?


=
2.=C2=A0 Do you support the reserved byte= s in the revision for a future pinning mechanism?
<= div>
No. I'm undecided on whether we should have an exten= sion point here, but I'm strongly against having it just be opaque rese= rved bytes. Everywhere else we have decided to put extension points, we'= ;ve had them as Extensions, not just "here are some bytes".=C2=A0= Aside from this being general TLS practice, it is good futureproofing beca= use one can grease Extensions, whereas you cannot grease opaque bytes.
<= /div>


3.=C2=A0 Do you support the proof of denial of ex= istence text in the revision?

T= he mechanism seems fine, but it doesn't seem to me that the specificati= on is clear on what the semantics are. I think what they are is that you ca= n configure the client to be in some "DNSSEC required" mode which= will requires that the extension be returned and that it either (a) contai= n DNSSEC-signed records for the domain or (b) contain authenticated denial = of existence. Is this correct? If so, I would be happy to have the text mer= ged and then wordsmith this explanation.


<= /div>
4.=C2= =A0 Do you support the new and improved security considerations?=C2=A0

They seem like a good start. I'= d be happy to have them merged and wordsmith them.

-Ekr

<= div style=3D"font-size:12.8px;text-decoration-style:initial;text-decoration= -color:initial">
Thanks,
Joe



<= div class=3D"gmail_quote">
On Tue, Jun 5, 2018 at 6:5= 1 AM, Paul Wouters <paul@nohats.ca> wrote:
On Mon, 4 Jun 2018, Benjam= in Kaduk wrote:

Hi Ben,

I've taken a stab at putting together some security considerations text= for
draft-ietf-tls-dnssec-chain-extension that reflects my understanding o= f the
current state of affairs.=C2=A0 It's in a pull request at
https://github.com/tlswg/dnssec-chain-ex= tension/pull/19 , along with Viktor's
commit to update the text about the actual DNS records involved (which as far as I can tell seems to improve the technical accuracy of the text), and=
also inserting a variable-length array that's reserved for future attem= pts
to mitigate the (now-)documented security considerations.

 Thanks for writing the proposed text. The new opaque Reserved field
along with the denial of existence changes you propose addresses all
my concerns.

One corner case that might be worth mentioning with the proposed DoE text is the odd corner case of hitting a server with a Host header for which
it is not configured. You will hit the "default vhost" but you ha= ve no
appropriate extension data to populate for that hostname. So either the
server will return the (cached) TLSA/DoA data of the 'wrong' hostna= me,
or it could just omit the extension. I'd mostly like to say something t= o
prevent an implementation of forgetting this corner case and causing
some vulnerability in their code later on by pointing to bogus memory or crashing on dereferencing a NULL.

Some nits:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 If the server supports this extension it perfor= ms the appropriate DNS queries,

In my PR I had changed this into "obtains the appropriate DNS RRsets&q= uot;,
because I envision that TLS servers might not do DNS lookups themselves, but just read this via a file or other method. Eg a cron job that
regenerates these hourly for all the hosted domains. It also reduces
some fear that all TLS servers suddenly could need to link against
a DNSSEC library. They don't if they can just reload a blob from disk regularly to serve up.

Similarly:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 it will need to rebuild

is better written as "it will need rebuilt data"


=C2=A0 =C2=A0 =C2=A0 =C2=A0 "authenticates the chain"

That should probably be "validate the chain", but the document ha= s more
mixups of validate vs authenticate. In my PR request I had not corrected them in an effort to keep the diff as small as possible.

I had modified the examples slightly, so the NSEC example would show a
simpler NSEC chain (from www to zzz) instead of the one wrapping around
from www to the zone apex. The example quoted is the wrong NSEC record
(the one from apex to www.example.com does not show that the
_443._tcp.www.example.com does not exist, you need the one from
www..example.com to the apex at the end of the zone)


I'm not sure what you mean with:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 validated negative TTL

I guess you mean to say the shortest TTL of any data in the chain? But
sometimes the negative cache time is larger then the TTL (eg if TTL =3D 0)<= br> Since this is just generic DNS handling, I would probably just write
something like "up to the appropriate lifetime" and leave it out = of
this document.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 denial of existence RRset

Technically that should be "RRsets" since you usually will need m= ore then
one RRset to prove this (to disprove existence of the wildcard record)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -=C2=A0 =C2=A0 =C2=A0 DNSSEC authentication cha= in extension from a server, SHOULD use this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 +=C2=A0 =C2=A0 =C2=A0 DNSSEC authentication cha= in extension from a server, uses this

I'm not sure why the SHOULD was removed here? Since it is describing TL= S
client behaviour the "uses this" confuses me as I dont know if th= at
means MAY, SHOULD or MUST.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + Specifically, the relevant DANE records are i= ncluded
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + in the TLS handshake transcript hash, so both= sides
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + possess identical records;

I'm not sure why you suggest to add this text. A TLS client might still=
have cached a valid TLSA records from a previous connection 1 second
ago and might decide to not use this information at all. Also, it seems
to suggest that the transscript hash protects this data, but it is
"protection" using the webpki or proof of lack of MITM, but the d= ata
does not need this protecting as it is protected by DNSSEC signatures.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + the client remains responsible
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + for actually performing the domain name valid= ation of
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + the DANE records.

Well, if it just fired up a previous TLS connection, perhaps it will be
content with the same pubkey used and skip re-validating this data? I
guess we sort of say the same thing due to the lack of a MUST ?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + The Reserved field is reserved for future upd= ates to this
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + document; in particular it is hoped that the = issues discussed
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + in <xref target=3D"increasing-trust&q= uot; /> can be addressed.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 + Implementations of this specification MUST se= nd a zero-length vector

Perhaps that last line can be clarified a bit:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Implementation not implementing any updates to = this document
=C2=A0 =C2=A0 =C2=A0 =C2=A0 MUST send a zero-length vector

This sentence does not parse:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 "whether or not to the exclusion"

This text is a little confusing to me:

=C2=A0 =C2=A0 =C2=A0 =C2=A0 + certified by the DNS key hierarchy, that the<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 + server does not support DANE authentication
The TLS server itself might support "DANE authentication", but th= ere is
simply no data.=C2=A0 Perhaps say that the server's configured hostname= does
not support DANE authentication?

Thanks again for the write up!<= font color=3D"#888888">

Paul


_______________________________________________
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


--000000000000bac2b60570368f2e-- From nobody Wed Jul 4 19:02:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59F64130E79 for ; Wed, 4 Jul 2018 19:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PtLLZ0xVWu7s for ; Wed, 4 Jul 2018 19:02:12 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 DE385130E1B for ; Wed, 4 Jul 2018 19:02:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530756132; x=1562292132; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=2+TGs7HawegAwV3Orz/SZr2amH55dlAWNNAdwB/Og+M=; b=xoyw7et8EEDet3sYkG8mmsf1SrnvvQyTWzfH4FLpoU0QJVzOUH9dIBwq oR0PL+RUpDM4kcCe3Sumrzgh8kX4vuyHsSbQYkxV6qX97qSZ2h0ayhaQB O2FYunAOPPyQcLDfyibt68hU6VX0KJ3LbUnhr3qDKvKw0NbsHzfsLep30 m3wHmd/UKpYjZWifKgKbWpyMn/NuYNW7xtTqCfS9D3wxAVkMNfvlqQl9j SE01CkrLIev4jzH3jhJlIbmcORi8OL19hBVtqcpKvjpwZfNODYuQ0iA+R PRx5Yfv1qQ93WbEGSvYD/PkVD8x2A5hw0DL4KsGSeylWHSx7HeuA7iTE3 Q==; X-IronPort-AV: E=Sophos;i="5.51,309,1526299200"; d="scan'208";a="19680616" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-c.UoA.auckland.ac.nz) ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Jul 2018 14:02:05 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 5 Jul 2018 14:02:05 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Thu, 5 Jul 2018 14:02:05 +1200 From: Peter Gutmann To: Ilari Liusvaara CC: "" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAHzICU= Date: Thu, 5 Jul 2018 02:02:04 +0000 Message-ID: <1530756106390.98539@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz>, <20180704081519.GA20000@LK-Perkele-VII> In-Reply-To: <20180704081519.GA20000@LK-Perkele-VII> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:02:16 -0000 Ilari Liusvaara writes:=0A= =0A= >Chrome initially did that. It caused quite a lot of bad feedback from owne= rs=0A= >of various bad embedded stuff. The thread on relevant forums was quite=0A= >something. Hundreds of messages blaming Google for breaking stuff.=0A= =0A= If there were "hundreds of messages" doesn't that indicate that it's Chrome= =0A= that's the problem, and not everyone else?=0A= =0A= Peter.=0A= From nobody Wed Jul 4 19:05:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91111130E60 for ; Wed, 4 Jul 2018 19:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljsUNYLWe4BF for ; Wed, 4 Jul 2018 19:05:52 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 D3D46130E1B for ; Wed, 4 Jul 2018 19:05:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530756352; x=1562292352; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=z6ddPk7NIuRcBzEtfJtkj6/mc3l6fWJIeF5AKiyhfhs=; b=Kk14pbq4UmBY7GBXvzzCuXG+MXJaO8iH3U/xEZarnzSt8w6r+4DIvoDQ dsg7gdv/j8/8UnG/3abI7G11hSTf9auLAk2VL7+6hGLuF3DY2xkUTmBag 150Dclm5XXHEuxikzZNDjw5zfygdXO06JbaTxg1zokSor8g0GUIVZzEuz R3riSWNAPdjYjASrS7LpD1vvKBPolhXFv2m3UlsBaxECCr9sjlkqCSnnQ DJst6wOA24+uDFKbU+GW+Zq0uetHK3P7DB0xBSKJTsXJHRzNdEEd6oZcx je3hlQ6Od1eLYdCp+ENawnCD5ONf3RMTBq/QMu92zntmSbeZ5opPXLy4/ Q==; X-IronPort-AV: E=Sophos;i="5.51,309,1526299200"; d="scan'208";a="19681255" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Jul 2018 14:05:50 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 5 Jul 2018 14:05:49 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Thu, 5 Jul 2018 14:05:49 +1200 From: Peter Gutmann To: Kurt Roeckx , Hubert Kario CC: "tls@ietf.org" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgADQEJ///2EpAIAAJ+eAgAGuV0c= Date: Thu, 5 Jul 2018 02:05:48 +0000 Message-ID: <1530756330644.68072@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <1530690320155.99154@cs.auckland.ac.nz> <1673271.m6b9jqBoj9@pintsize.usersys.redhat.com>, <20180704122407.GA10998@roeckx.be> In-Reply-To: <20180704122407.GA10998@roeckx.be> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:05:54 -0000 Kurt Roeckx writes:=0A= =0A= >The extensions are not related to TLS, but are extentions / add-ons of the= =0A= >browser itself. Firefox dropped support for the old way of doing extension= s=0A= >in version 57. They also added the WebExtensions API that is also implemen= ted=0A= >in other browsers. This required major rewrites of the extensions, and som= e=0A= >were never changed to work with the new API.=0A= =0A= As I understand it (E&OE), the flow was that a bunch of SCADA stuff used=0A= browser extensions, presumably to talk things like IEC 61850. When the=0A= existing extensions broke, there was a general exodus from Firefox to Chrom= e,=0A= however when Chrome broke at the TLS level there was indecision about what = to=0A= do. There are also IE plugins, I assume the advice going forwards will be = to=0A= use IE.=0A= =0A= (I have no idea about the prevalence of IE vs. others, but since it's the= =0A= default browser for Windows I assume this will be the easiest/recommended p= ath=0A= fowards, and until Windows 10 MS had a long history of being excruciatingly= =0A= careful about backwards compatibility so it seems the safest bet).=0A= =0A= Peter.=0A= From nobody Wed Jul 4 19:08:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7723E130E79 for ; Wed, 4 Jul 2018 19:08:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pJV5S_dXWVKT for ; Wed, 4 Jul 2018 19:08:53 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B82C130E60 for ; Wed, 4 Jul 2018 19:08:53 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 8C73629A1D4; Wed, 4 Jul 2018 22:08:52 -0400 (EDT) Date: Wed, 4 Jul 2018 22:08:52 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180705020852.GK85096@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20180604203947.GW13834@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:08:58 -0000 On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote: > 3. Do you support the proof of denial of existence text in the revision? > > The mechanism seems fine, but it doesn't seem to me that the specification > is clear on what the semantics are. I think what they are is that you can > configure the client to be in some "DNSSEC required" mode which will > requires that the extension be returned and that it either (a) contain > DNSSEC-signed records for the domain or (b) contain authenticated denial of > existence. Is this correct? If so, I would be happy to have the text merged > and then wordsmith this explanation. More precisely, you can configure the client to require the extension, and yet still interoperate with servers that (support the extension, but) live in an unsigned zone, or live in a signed zone with no TLSA records for the service in question. The server just needs to be able to return a denial of existence proof for the DS records of a delegated containing domain or its TLSA records, respectively. Agree that merging the text for further polish is a logical next step. > 4. Do you support the new and improved security considerations? > > They seem like a good start. I'd be happy to have them merged and wordsmith > them. Ditto. -- Viktor. From nobody Wed Jul 4 19:31:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5312130D7A for ; Wed, 4 Jul 2018 19:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2_xKIgOmiTI for ; Wed, 4 Jul 2018 19:31:16 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31F76130E1D for ; Wed, 4 Jul 2018 19:31:16 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id v8-v6so13922055oie.5 for ; Wed, 04 Jul 2018 19:31:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7M7NkSZ+yMJ9xwcfzqM+CNnqDrTZRiLYWMR/FWi+8d4=; b=YWSM/wKcM+g4z8TVsPqkp8DM8N51rgbJldBDWMHHe6Yz3wSFQKMW7RJ1ZfGGARXbYe 86RcXbojIA/1JaLy2D9caJa213R3xtl+3LEt5+C2rX2PcKDCkUmtlu2JvnjG+YFocge7 MpHjlbRKj1BtYeq7FYOJmzlFKCi8d00alb/Kg796iJqq/kC5aYWIXIS12uuTHSx1GeZk kSmT+2nI1uEydfj/X4GcmrQAGUKobi+cmJSe+y8W0AcDP0qnZ4pnGZ7zna1903uhoaXK WADpGD661TGG2fVuKC+mc3UcDICcKjeLbQi3lihXdvLpyGEMtkRv8+jr0N7QiZ3jZtIN Bp4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7M7NkSZ+yMJ9xwcfzqM+CNnqDrTZRiLYWMR/FWi+8d4=; b=K4j/c51JZmYaq1odwrK7L3UU+lZ13MXN/lhpS8jvNTe0muq//QV7U+Qel3cYVMW7BT EoxgbwqOejRP+Beoi3J6oO2c2FJX1qasZ3uCnQdbpDZ1sRNzXkSs0eLmjt/3mD/cv1DF 0qsm7fy8YCIwmFAX+/r6VomNHID36veuoBB7VHtDCZhDxzgxKAMkPm2tN/JZk9KBLeC/ L28idLvYbvuwLZ/JE0HgYvQpQRd/RXBVwU9gdD57gZ0+/qQmqx/ZU/v2sJr3u7E6roRH THef4nrs8oRRBEJ+Qlhjjxpn4Lh9KIgyKk4iZynqkQfRep61pB9PVQcWQPHdK/Jblrkz Q5Bg== X-Gm-Message-State: APt69E00U1nR/AZw3CV/ALtKCOw5y6xI6SZTfrCpVC6zewidPmTb2ujQ bSYBXF0cOCfgPporE0PRIVZRhbYYP/DDOJD4xVkLvQ== X-Google-Smtp-Source: AAOMgpdQAsdiyuMdVn3rdU5FZ+ArLMYgnf7dvTKTefI/mSB697A5U5mXBe68X2501JMuHCJ/gm4H2z60hkREKfm0aWE= X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr4361072oib.254.1530757875185; Wed, 04 Jul 2018 19:31:15 -0700 (PDT) MIME-Version: 1.0 References: <20180604203947.GW13834@akamai.com> In-Reply-To: From: Martin Thomson Date: Thu, 5 Jul 2018 12:31:02 +1000 Message-ID: To: Joseph Salowey Cc: Paul Wouters , "" , bkaduk=40akamai.com@dmarc.ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:31:19 -0000 On Tue, Jun 26, 2018 at 2:21 PM Joseph Salowey wrote: > 1. Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)? I don't think that pinning is a good idea. We've experience that suggests that it's more of a footgun than a useful mechanism. That isn't to say that there isn't a domain where it makes sense. > 2. Do you support the reserved bytes in the revision for a future pinning mechanism? No. We need fewer extension points, not more. It's already hard enough to ensure that the ones we have remain usable. ekr's suggestion to reduce the number of *types* of extension point would be a compromise position here, but I don't think that's the best outcome. If we mess this one up, we can make another extension, or use another extension to fix it if that makes more sense. Yes, that's messy, but the above assessment supports the notion that we won't need v2. > 3. Do you support the proof of denial of existence text in the revision? Allowing denial of existence in the extension is fine. It somewhat depends on having a prior expectation of having some form of DNSSEC record there, which hits all the concerns above, so I'm not sure what concrete value it provides. I see no harm in allowing it though. > 4. Do you support the new and improved security considerations? I have to confess, I had a lot of trouble reading the new text. It's good, and contains much of what is needed, but it's very wordy. I think another iteration or two would help. If I can summarize: We consider the case where DANE is considered stronger than PKIX or a valuable addition to PKIX, because this extension is only of use in those circumstances. If an attacker can compromise PKIX, then they can just not send the DANE extension. With prior knowledge, a relying party might know to expect DANE, but that isn't always possible, especially when this mechanism is introduced into a PKIX-only ecosystem. A relying party can't assume that use of DANE with one connection implies that other connections to the same peer will also be secured with DANE. There's a lot of extra words around that message, and I fear that the message will be lost as a result. From nobody Wed Jul 4 19:32:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA3AB130D7A for ; Wed, 4 Jul 2018 19:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxFK_KiHaebL for ; Wed, 4 Jul 2018 19:32:16 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 81ED6130E1D for ; Wed, 4 Jul 2018 19:32:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530757935; x=1562293935; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VyurFvnrqi3fX5nj6w2aDe0NwoAFij0NTuyMc/l9NgU=; b=UVR7+RsKlU67AdUcObsKSiivNiolYWDYkRhcJ8Q6gnuaP6bgg8qxgY1r g9t54vIAo/sNgZ1CB0XBrvJDTBipr3D5IPYZbkjISPWiHNRlhG6lOCg+B IClOn3nJ4IPRtsZy3BFhPCDy28z8suRGEjIf5Uj50ihbxcvJVQzX+85w6 HX5vgcSvRe48FCSuUBXanM+o+m9r3/PnzRFD4za49JwRBZ73wRr5scv8+ sQDF8I2/Op0YwAbVyrRY6HjEYGd4qEVo1XpZ3lCk1CKy9TPCM7APqoQ31 aeR17vF/ijbI1+OC+jTrx7I0XNTwE0dOfwaRNOT1hRVHDBfDlrMubvbbU g==; X-IronPort-AV: E=Sophos;i="5.51,310,1526299200"; d="scan'208";a="19685623" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 05 Jul 2018 14:32:09 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 5 Jul 2018 14:32:08 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Thu, 5 Jul 2018 14:32:08 +1200 From: Peter Gutmann To: David Benjamin , Nikos Mavrogiannopoulos CC: Ilari Liusvaara , "" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAAHUoCAAG4mgIABhdII Date: Thu, 5 Jul 2018 02:32:08 +0000 Message-ID: <1530757910178.45400@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:32:19 -0000 RGF2aWQgQmVuamFtaW4gPGRhdmlkYmVuQGNocm9taXVtLm9yZz7igIsgd3JpdGVzOgoKPlRoZSBi YWQgZmVlZGJhY2sgd2FzIG5vdCBldmVuIGF0IGEgMjA0OC1iaXQgbWluaW11bSwgYnV0IGEgbWVy ZSAxMDI0LWJpdAo+bWluaW11bS4gKENocm9tZSBlbmFibGVkIGZhciBtb3JlIERIRSBjaXBoZXJz IHRoYW4gb3RoZXJzLCBzbyB3ZSBlbmNvdW50ZXJlZAo+YSBsb3Qgb2YgdGhpcy4pIDIwNDgtYml0 IHdhcyBjb21wbGV0ZWx5IGhvcGVsZXNzLiBBdCB0aGUgdGltZSBvZiByZW1vdmFsLCA5NSUKPm9m IERIRSBuZWdvdGlhdGlvbnMgbWFkZSBieSBDaHJvbWUgdXNlZCBhIDEwMjQtYml0IG1pbmltdW0u CgpIb3cgZG9lcyBHb29nbGUsIHJhdGhlciB0aGFuIHRoZSBwZW9wbGUgcnVubmluZyB0aGUgc3lz dGVtcyBiZWluZyBjb25uZWN0ZWQKdG8sIGtub3cgdGhhdCAxMDI0LWJpdCBESCBpc24ndCBzZWN1 cmUgZW5vdWdoIGZvciBhIGdpdmVuIGVudmlyb25tZW50PyAgVGhlCm1ham9yaXR5IG9mIHRoaXMg c3R1ZmYgaXMgcnVubmluZyBvbiBpc29sYXRlZCwgcHJpdmF0ZSBuZXR3b3JrcyBvciBpbnNpZGUg VlBOCnR1bm5lbHMgZm9yIHdoaWNoIHByZXR0eSBtdWNoIGFueXRoaW5nLCBpbmNsdWRpbmcgNTEy LWJpdCBrZXlzLCBhcmUgZmluZS4KCkl0J3MgYWxzbyBzb21ld2hhdCBkaXN0dXJiaW5nIHRoYXQg Q2hyb21lIG5vdyB3YWxrcyBzdHJhaWdodCBwYXN0IGEgcGVyZmVjdGx5Cmdvb2QgUEZTIERIRSBz dWl0ZSBhbmQgaW5zdGVhZCBnb2VzIHRvIGEgcHJvYmxlbWF0aWMgcHVyZS1SU0Egb25lIGluc3Rl YWQuCgo+WW91IHNob3VsZCBpbnN0cnVjdCB0aGVzZSBmb2xrcyB0byBjb25maWd1cmUgRUNESEUr UlNBIGNpcGhlcnMgaWYgdGhleSBoYXZlCj5SU0Ega2V5cy4gCgpUaGUgZGV2aWNlcyBkb24ndCBk byBFQ0RIRSwgYW5kIHRoZXkgcHJvYmFibHkgbmV2ZXIgd2lsbCAoYXQgbGVhc3QgdW50aWwgdGhl Cm5leHQgdXBncmFkZSBjeWNsZSwgd2hpY2ggY291bGQgdGFrZSBhIGRlY2FkZSBvciBtb3JlKSwg c28gdGhlcmUncyBub3RoaW5nIHRvCmNvbmZpZ3VyZS4KCj5yZmM3OTE5LCBkaWQgbm90IGZpeCB0 aGUgcHJvYmxlbS4gVGhpcyB3YXMgcG9pbnRlZCBvdXQgaGVyZSwgYnV0IG5ldmVyCj5pbmNvcnBv cmF0ZWQgdG8gdGhlIGRvY3VtZW50OgoKWWVwLiAgVGhlIGlzc3VlcyB3ZXJlIHBvaW50ZWQgb3V0 IGJ5IHNldmVyYWwgcGVvcGxlIGJlZm9yZSBpdCB3YXMgcHVibGlzaGVkLApidXQgZ290IHB1Ymxp c2hlZCBhbnl3YXkuLi4gd2l0aCB0aGUgcmVzdWx0IGJlaW5nIHRoYXQgYSBudW1iZXIgb2YKaW1w bGVtZW50YXRpb25zIGNob3NlIG5vdCB0byBzdXBwb3J0IGl0IGJlY2F1c2Ugb2YgdGhlIHByb2Js ZW1zIHRoYXQgaXQKY2F1c2VzLgoKPlBhcnRpY3VsYXJseSBpbiB0aGUgc2Vjb25kIHNjZW5hcmlv LCBpdCBzZWVtcyB0aGV5J3JlIGFscmVhZHkgaW1wbGVtZW50ZWQsCj5qdXN0IHRoZSBzZXJ2ZXIg d2FzIGluY29ycmVjdGx5IGNvbmZpZ3VyZWQgdG8gdXNlIHRoZSB3cm9uZyBvbmVzLgoKVGhhdCB3 YXMgaW4gbXkgdGVzdGluZywgbm90IHVzaW5nIGEgUExDIGNvbnRyb2wgY2VudHJlIG9yIHNpbWls YXIsIGluIG90aGVyCndvcmRzIHRoZSBhY3R1YWwgZGV2aWNlcyBiZWluZyB1c2VkIGluIHRoZSBm aWVsZC4gIERvaW5nIHRoYXQgd291bGQgaGF2ZQpyZXF1aXJlZCBhIGZpcm13YXJlIHJlbG9hZCBm b3IgZWFjaCB0ZXN0LCB3aGljaCBpcyB3YXkgdG9vIHBhaW5mdWwgdG8gdGhpbmsKYWJvdXQuICBG b3IgInNlcnZlciBpbmNvcnJlY3RseSBjb25maWd1cmVkIiwgc2VlIGFib3ZlLCB0aGV5IHdlcmUg b2ZmZXJpbmcgYWxsCnRoZSBzdWl0ZXMgdGhlIGZpcm13YXJlIGFuZCBoYXJkd2FyZSBzdXBwb3J0 ZWQuCgpQZXRlci4KCgo= From nobody Wed Jul 4 19:33:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6498D130E60 for ; Wed, 4 Jul 2018 19:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KldhiuZUpRPL for ; Wed, 4 Jul 2018 19:33:11 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 031FD130E1D for ; Wed, 4 Jul 2018 19:33:11 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 61ADA29A1EA; Wed, 4 Jul 2018 22:33:10 -0400 (EDT) Date: Wed, 4 Jul 2018 22:33:10 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180705023310.GL85096@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20180604203947.GW13834@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:33:12 -0000 On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote: > > 1. Do you support the working group taking on future work on a pinning > > mechanism (based on the modifications or another approach)? > > Unsure. I'd like to see some real evidence that it will be widely consumed. > Do we have a count of major implementors who say they will do so? Well, what is a "major implementation"? TLS is not just browsers, and adoption does not always begin the day the RFC is published. DANE adoption only started 2+ years after RFC6698, and is still ramping up. The important thing here is to not *preclude* adoption by needlessly limiting the scope to just "greenfield" applications. It is rather clear that the present draft is only compatible with applications that mandate the extension. Some form of "STS-lite" pinning is needed to support incremental adoption by existing applications. > 2. Do you support the reserved bytes in the revision for a future pinning > > mechanism? > > No. I'm undecided on whether we should have an extension point here, but > I'm strongly against having it just be opaque reserved bytes. Everywhere > else we have decided to put extension points, we've had them as Extensions, > not just "here are some bytes". Aside from this being general TLS > practice, it is good futureproofing because one can grease Extensions, > whereas you cannot grease opaque bytes. It is far from clear why "grease" is applicable here, or what "grease barriers" either proposed form of the reserved field presents. * With the 16-bit field, servers set it to zero until non-zero values are specified. * With the <0..255> byte value, servers send an empty value until non-empty values are specified. * In either case clients ignore either non-zero or non-empty values, until they implement the specification, and must not employ pinning until such time. I thought the authors wanted this done quickly, but lately they seem to be in no rush to get the document finished. If we're no longer in a hurry to get this out the door before all the issues are sorted out, we can specify the downgrade protection now, in which case there's no need for reserved fields, we can define the pinning approach now. -- Viktor. From nobody Wed Jul 4 19:39:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DCE130E79 for ; Wed, 4 Jul 2018 19:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u4BngxD_sYNB for ; Wed, 4 Jul 2018 19:39:19 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2936130D7A for ; Wed, 4 Jul 2018 19:39:19 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 0AE7B29A1F6; Wed, 4 Jul 2018 22:39:19 -0400 (EDT) Date: Wed, 4 Jul 2018 22:39:19 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180705023918.GM85096@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20180604203947.GW13834@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:39:22 -0000 On Thu, Jul 05, 2018 at 12:31:02PM +1000, Martin Thomson wrote: > On Tue, Jun 26, 2018 at 2:21 PM Joseph Salowey wrote: > > 1. Do you support the working group taking on future work on a pinning mechanism (based on the modifications or another approach)? > > I don't think that pinning is a good idea. We've experience that > suggests that it's more of a footgun than a useful mechanism. That > isn't to say that there isn't a domain where it makes sense. Did you oppose MTA-STS? The proposed "pinning" is very much like a simpler form of MTA-STS, and nothing unlike HPKP. Perhaps it would be much less confusing if we stopped calling it "pinning" (which seems to be a traumatic memory trigger for the HTTP community). We can call this "strict TLS DANE chain" or some such, which is a much better analogy in any case. -- Viktor. From nobody Wed Jul 4 19:46:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CCCE130E79 for ; Wed, 4 Jul 2018 19:46:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u18yLq2swcZ7 for ; Wed, 4 Jul 2018 19:46:55 -0700 (PDT) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAAD0130D7A for ; Wed, 4 Jul 2018 19:46:54 -0700 (PDT) Received: by mail-yb0-x235.google.com with SMTP id e84-v6so2684668ybb.0 for ; Wed, 04 Jul 2018 19:46:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=IMRjQk12YesSxA0vxXtvwU9qteInYgztvxACUxhggGU=; b=owIhrAC54Di0pbZeoiAqohnh+u38slLiS34N0kWaz1VBYOuqbRlPXYZnV6AfUiIFNq esKmcRs4GwPmx6du3rAUGWFV8YInsw8CxqhF5QRVxlo+qwexNyWgoSaOsJzKKxqqRDnP liO9Hl+/4K3EpUDoudHy0CvFMme9JL19roHNc/RxvtGeQsEJgKAesGcxRx5x6bMgyhJ/ Q5SMsBZR+1SQs3w7ebqFGlhUpNN9tZoYfcEj9VQ+5LWO8zL6GItHqUJWenJIAN8L2WLJ cu+T9CVENVUzTgTx0VYXuQOvWsH6b2pIhfOykEQtm0xjZQa7ec7v7zqmoP/hfHBLNKZ5 51ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=IMRjQk12YesSxA0vxXtvwU9qteInYgztvxACUxhggGU=; b=aHt/TFM+hqIQnOBBAbDt0Zaxbpz/LEQsg3b6kxrGY/qbXxkR27SkKLUMqsXWYK5g20 FLfX4kykFeLs350BfHuy/ZkF+QEyRtC4frfEP6eU+1u2W3jHKKw4QJrGIidSbrK3OZVv mqAYYUPnIOAuDo492jg1uFVjAAEbi34WwQji+5EPp6u45h90Y44wD4p0XUdn7k/6AlQQ XjhwIpaHUMkAEAABVphlLOCl4PZ5cZrAk/WgNyBga1M8Rg90uvSO2GryyYC3+pBGxt9U gqvO7rTU3y2YyIPrlkl6rz4EcH5dgaebSVHn4ERDsEGEUBzLQoGCXhenfSBzKxo4kxYB H6XQ== X-Gm-Message-State: APt69E2r+iUwqOKO1ZWY1dYM+DLKuCGnZXlq4oNqli5o9CLqpjwyUoIa N48JB0gGUkIxOaqJHw4cNwWRe5cuFKCcI2SyD4X2gcSx X-Google-Smtp-Source: AAOMgpeF4wXFNk+LBYwvilDPQ2fvhojKtmz5O/7XDFumBYw/gkTlYfSulOVK6N2wImsoaifV9JxSac8/vRYo8/3g3ak= X-Received: by 2002:a25:adcb:: with SMTP id d11-v6mr2319734ybe.73.1530758813671; Wed, 04 Jul 2018 19:46:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 19:46:13 -0700 (PDT) In-Reply-To: <20180705023310.GL85096@straasha.imrryr.org> References: <20180604203947.GW13834@akamai.com> <20180705023310.GL85096@straasha.imrryr.org> From: Eric Rescorla Date: Wed, 4 Jul 2018 19:46:13 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000005379520570378f5f" Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:46:57 -0000 --0000000000005379520570378f5f Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 7:33 PM, Viktor Dukhovni wrote: > On Wed, Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote: > > > > 1. Do you support the working group taking on future work on a pinning > > > mechanism (based on the modifications or another approach)? > > > > Unsure. I'd like to see some real evidence that it will be widely > consumed. > > Do we have a count of major implementors who say they will do so? > > Well, what is a "major implementation"? Well, we could start with "what implementations are going to do this"? > No. I'm undecided on whether we should have an extension point here, but > > I'm strongly against having it just be opaque reserved bytes. Everywhere > > else we have decided to put extension points, we've had them as > Extensions, > > not just "here are some bytes". Aside from this being general TLS > > practice, it is good futureproofing because one can grease Extensions, > > whereas you cannot grease opaque bytes. > > It is far from clear why "grease" is applicable here, or what "grease > barriers" either proposed form of the reserved field presents. > > * With the 16-bit field, servers set it to zero until non-zero > values are specified. > > * With the <0..255> byte value, servers send an empty value > until non-empty values are specified. > * In either case clients ignore either non-zero or non-empty > values, until they implement the specification, and must not > employ pinning until such time. > Yes, and this is where grease comes in. Specifically, if implementations are required to send empty values (or zero) until something is specified, then implementations which *require* those values and choke otherwise go undetected. By contrast, if we have a structured Extension code point with requirements to ignore unknown extensions, then implementations can send grease extension values and verify that the peer properly ignores them. In any case, as Martin Thomson says, we have a perfectly good extension mechanism which can be used to add pinning later without creating any placeholder here. I thought the authors wanted this done quickly, but lately they > seem to be in no rush to get the document finished. Well, I'm not an author, so I'm the wrong person to be addressing this to. If we're no > longer in a hurry to get this out the door before all the issues > are sorted out, we can specify the downgrade protection now, in > which case there's no need for reserved fields, we can define the > pinning approach now. > That would first require there being consensus to do pinning. -Ekr --0000000000005379520570378f5f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 7:33 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:
On Wed= , Jul 04, 2018 at 06:34:44PM -0700, Eric Rescorla wrote:

> > 1.=C2=A0 Do you support the working group taking on = future work on a pinning
> > mechanism (based on the modifications or another approach)?
>
> Unsure. I'd like to see some real evidence that it will be widely = consumed.
> Do we have a count of major implementors who say they will do so?

Well, what is a "major implementation"?=C2=A0
=

Well, we could start with "what implementations ar= e going to do this"?


> No. I'm undecided on whether we should have an extension point her= e, but
> I'm strongly against having it just be opaque reserved bytes. Ever= ywhere
> else we have decided to put extension points, we've had them as Ex= tensions,
> not just "here are some bytes".=C2=A0 Aside from this being = general TLS
> practice, it is good futureproofing because one can grease Extensions,=
> whereas you cannot grease opaque bytes.

It is far from clear why "grease" is applicable here, or w= hat "grease
barriers" either proposed form of the reserved field presents.

=C2=A0 =C2=A0 * With the 16-bit field, servers set it to zero until non-zer= o
=C2=A0 =C2=A0 =C2=A0 values are specified.

=C2=A0 =C2=A0 * With the <0..255> byte value, servers send an empty v= alue
=C2=A0 =C2=A0 =C2=A0 until non-empty values are specified.
=

=C2=A0 =C2=A0 * In either case clients ignore either non-zero or non-empty<= br> =C2=A0 =C2=A0 =C2=A0 values, until they implement the specification, and mu= st not
=C2=A0 =C2=A0 =C2=A0 employ pinning until such time.
<= br>
Yes, and this is where grease comes in. Specifically, if impl= ementations are required to send empty values (or zero) until something is = specified, then implementations which *require* those values and choke othe= rwise go undetected. By contrast, if we have a structured Extension code po= int with requirements to ignore unknown extensions, then implementations ca= n send grease extension values and verify that the peer properly ignores th= em. In any case, as Martin Thomson says, we have a perfectly good extension= mechanism which can be used to add pinning later without creating any plac= eholder here.

I thought the authors wanted this done quickly, but lately they
seem to be in no rush to get the document finished.=C2=A0
=
Well, I'm not an author, so I'm the wrong person to = be addressing this to.


If we're no
longer in a hurry to get this out the door before all the issues
are sorted out, we can specify the downgrade protection now, in
which case there's no need for reserved fields, we can define the
pinning approach now.

That would first = require there being consensus to do pinning.

-Ekr<= span class=3D"m_-7116669225257152004m_2496595792529824897HOEnZb"><= /div>
--0000000000005379520570378f5f-- From nobody Wed Jul 4 19:51:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22025130D7A for ; Wed, 4 Jul 2018 19:51:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lPq0WDkDpTyO for ; Wed, 4 Jul 2018 19:51:49 -0700 (PDT) Received: from mail-pf0-x22c.google.com (mail-pf0-x22c.google.com [IPv6:2607:f8b0:400e:c00::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 5B14F12D949 for ; Wed, 4 Jul 2018 19:51:49 -0700 (PDT) Received: by mail-pf0-x22c.google.com with SMTP id s21-v6so4044122pfm.6 for ; Wed, 04 Jul 2018 19:51:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=sa2k5ZD3yCQnoqnFvvFW1Zuq6S2y+zYKUlirumDags0=; b=mtdC7oEwl2GR5pg0r1epG9g57MQFuinMkf9jfaiO0Ve6utunMYLrbTJmfU4MkyQ1j2 l0HV2mB6ePT3vKwBuqUtPNjXai7Bm5R7UfrEFZDMDf634tmSwniM1G1JxQPv2Pdk8qd4 BGCJSFGqkvckjc3JtnNTcrANJ43pW0DEgzBtcaGrLa0ZbfGnQspJogevPyVJni8hCi1e Be5aIOa5F3dNMx96O2G3Ags6BShC5R0fu/rUWirads0TNxA/Ly2kwRU7GU2z18ydij21 Rt9XcWLhK9+NNMZ8tokNcHBdoijfJdhyyo6DyHKAubfcFXqQ6abeey7zzVJziRL/qqe7 e9yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=sa2k5ZD3yCQnoqnFvvFW1Zuq6S2y+zYKUlirumDags0=; b=o8Yl2WoZKJRkZt/IXvBQ5o3b39kJtqs9HU0+7zdK09fBUvv5fumAHc3y2bGyJ/0ClV NbNzsLq9mlD5fp/vIN2mQNmom/CJR2UyqqZ6SF+Rh0UKjETb3WMEGJjXyAGFsr8qAb+e MVTEwwQz64CAXB2i3Xkbo/O/e/hVfuoPw2bAR2PSjx0alvbke3AJ+bd3j3hoorXYv4W0 Nv7n/bhSikc/wbnejHkgtQUJkCmfjrAhPkOW3wO7Ic+9ROpotU9yVirRQsDuyFClrHOn aoAKTE/mkTVv/7po/UYlmyvlgsFZbsUYeKGb3ULk4hAjeloC9/83ORu1BdocCSfPXkJv /YHQ== X-Gm-Message-State: APt69E23PDxol+f2gHhOFgkmroon0NrKBPlw0gJQInO6F83xjrxEroYP D02picqgOUUkU3a/67rhteAcoRE= X-Google-Smtp-Source: AAOMgpdYIbWYcmhAsnj1mOU9E4R81LYQrS/KUMBZbDO4fUDFv9rcEFhotFmNZW9grE4WowTDXhCyZQ== X-Received: by 2002:a65:62cd:: with SMTP id m13-v6mr3866082pgv.280.1530759108454; Wed, 04 Jul 2018 19:51:48 -0700 (PDT) Received: from aspen.local (209-193-22-151-radius.dynamic.acsalaska.net. [209.193.22.151]) by smtp.gmail.com with ESMTPSA id a24-v6sm16103853pfj.140.2018.07.04.19.51.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jul 2018 19:51:47 -0700 (PDT) To: tls@ietf.org References: <20180604203947.GW13834@akamai.com> <20180705023310.GL85096@straasha.imrryr.org> From: Melinda Shore Message-ID: <1b15e7f6-cb30-c683-8e73-27884fe510eb@nomountain.net> Date: Wed, 4 Jul 2018 18:51:46 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180705023310.GL85096@straasha.imrryr.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:51:52 -0000 On 7/4/18 6:33 PM, Viktor Dukhovni wrote: > I thought the authors wanted this done quickly, but lately they > seem to be in no rush to get the document finished. I'm still trying to figure out a way forward that's useful for the people who intend to use this extension and that doesn't add cruft or ambiguity. Unfortunately there doesn't appear to be one, so compromise is necessary. I also think there's been already been a pretty serious process abuse here and tend to think that the new implication that we can go forward in a timely way if everybody just agrees with you is additionally problematic. But as I said earlier, I'll go along with the working group consensus and will not block a decision I don't happen to like. That's the implicit contract we sign with the IETF when we decide to bring work here. Melinda -- Software longa, hardware brevis PGP fingerprint: 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F From nobody Wed Jul 4 19:57:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C16A130D7A for ; Wed, 4 Jul 2018 19:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kcESoWiLq4el for ; Wed, 4 Jul 2018 19:56:56 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E063B130E87 for ; Wed, 4 Jul 2018 19:56:55 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 1B9A729A219; Wed, 4 Jul 2018 22:56:55 -0400 (EDT) Date: Wed, 4 Jul 2018 22:56:55 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180705025654.GN85096@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20180604203947.GW13834@akamai.com> <20180705023310.GL85096@straasha.imrryr.org> <1b15e7f6-cb30-c683-8e73-27884fe510eb@nomountain.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1b15e7f6-cb30-c683-8e73-27884fe510eb@nomountain.net> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 02:56:58 -0000 On Wed, Jul 04, 2018 at 06:51:46PM -0800, Melinda Shore wrote: > On 7/4/18 6:33 PM, Viktor Dukhovni wrote: > > I thought the authors wanted this done quickly, but lately they > > seem to be in no rush to get the document finished. > > I'm still trying to figure out a way forward that's useful > for the people who intend to use this extension and that doesn't > add cruft or ambiguity. Unfortunately there doesn't appear to > be one, so compromise is necessary. Since the updated security considerations and new denial of existence text are not looking controversial, it would be helpful to all parties to get a new revision out with those merged so they can be polished and put behind us. That leaves just the reserved field unresolved. -- Viktor. From nobody Wed Jul 4 20:16:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57240130E8B for ; Wed, 4 Jul 2018 20:16:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id piJc48n_VMHV for ; Wed, 4 Jul 2018 20:16:17 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 112DF130E87 for ; Wed, 4 Jul 2018 20:16:16 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 1BBE729A228; Wed, 4 Jul 2018 23:16:16 -0400 (EDT) Date: Wed, 4 Jul 2018 23:16:16 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180705031615.GO85096@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20180604203947.GW13834@akamai.com> <20180705023310.GL85096@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 03:16:19 -0000 On Wed, Jul 04, 2018 at 07:46:13PM -0700, Eric Rescorla wrote: > > > Do we have a count of major implementors who say they will do so? > > > > Well, what is a "major implementation"? > > Well, we could start with "what implementations are going to do this"? Since Postfix supports not just MTA-to-MTA SMTP, but also SUBMIT, and I am a maintainer of both the TLS features in Postfix, and the X.509 code in OpenSSL, I expect to add support for DANE chain in OpenSSL and Postfix in 2019. Next on the list would be Dovecot and mutt, but it'd be nice if that was done by one of the primary maintainers of those packages. > Yes, and this is where grease comes in. Specifically, if implementations > are required to send empty values (or zero) until something is specified, > then implementations which *require* those values and choke otherwise go > undetected. Any broken clients will get fixed. The client that motivated this draft is purported to require the extension, and the others will take some time to appear, highly likely not until the follow-on spec is written. The odds of real problems here are negligible. > By contrast, if we have a structured Extension code point with > requirements to ignore unknown extensions, then implementations can send > grease extension values and verify that the peer properly ignores them. There's no need for nested extensions, they serve no purpose. If DANE chain STS is in a separate extension, it may as well be top-level. > any case, as Martin Thomson says, we have a perfectly good extension > mechanism which can be used to add pinning later without creating any > placeholder here. At much too much complexity, unless we fork-lift this extension plus the additional payload, and largely obsolete this draft. Using one extension to pin itself and another is much too cumbersome. > > If we're no > > longer in a hurry to get this out the door before all the issues > > are sorted out, we can specify the downgrade protection now, in > > which case there's no need for reserved fields, we can define the > > pinning approach now. > > That would first require there being consensus to do pinning. That is, to address the security gap highlighted in the upcoming more complete security considerations. s/pinning/DANE chain STS/ -- Viktor. From nobody Wed Jul 4 20:43:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605C7130E87 for ; Wed, 4 Jul 2018 20:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pYn5vfadj6Yd for ; Wed, 4 Jul 2018 20:43:20 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E67130E7B for ; Wed, 4 Jul 2018 20:43:20 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l189-v6so2492329ywb.10 for ; Wed, 04 Jul 2018 20:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=mMaOt6a+8gJjY81yNtxbnW0r1n2uE8kXwlqEKjHoNLA=; b=Jql6HwkzyKFv8j+9Si9FpN+z9eZpfH1RWpJIWC2w1HTEMkNFhxSiOySpug77FR8xRp GZHq7HGXa9DH+yfB45hqzbV0WCfEbar4VLXGd3P5XZNoFgQlYw2m2Are91gu3Ls30NxZ Pm8NBA9lqy3BAHJNqPJDWBKrvQ4I6w1Mbrh/rf9uaZrQhgTv8TkeAvUKcyY1OlNqUtex Lj21iC52fe6vPugHgbaOwiPs1/a4wV4xh9MmF9+zYTEWLVq8/9AZoG7oEkiiJyIETyaZ 3TbI2GQdpPGpcGf3UVIlEKmrjpGg3rfv2pna/YNJOOacO6aBPSNfIwFsDhIr7f2c5a1Z 03Pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=mMaOt6a+8gJjY81yNtxbnW0r1n2uE8kXwlqEKjHoNLA=; b=nnKG48BlAdFDOGYbyueAeM4LR7QCNwVBKtyobLjnstkhTcHe2uz4cjb3xuqrmIBJT3 Jq8iKg5wQefizsul9QehCc1bNykb23xdR8OC2FUgdFp1QexIo0vJgIAhm88ojCNm+RUH ykZZNpcZnKtAJmaG0O4c49MsP8js+P6anqwKUo/aryf3qbRDJt/5D53Acvok2gUspCoH Ys7bb69bmRvMTDgPcltn5m9GyVz/D3iRsCIML9om+vgBIM+ePm0CyXMye62lpI4QPUhb n3HQBDTWx3vQfR5qLDes1iT2wN1mjk9kDuRGJu/N46ju2FpNXTqH5H3hW8jQ0YfdTxaY TqhQ== X-Gm-Message-State: APt69E042yBS+GWPWkMhLK4lY4zUmb9k4xAqkrhpbf4uzxYH7NJGgryp sVkUOhdovOtTPL5FeeHFjCfx+H41WMFDlfRnnmESM797 X-Google-Smtp-Source: AAOMgpdTDtx/qOgvqXDJk8iW/+tBwXWVx4DiAip6ZhIM5pCqmfwE02m3qdBQJH7WvYW4CULd1Qd0YiJ6MKhYNY6qDsE= X-Received: by 2002:a81:3e02:: with SMTP id l2-v6mr2137892ywa.381.1530762199282; Wed, 04 Jul 2018 20:43:19 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 4 Jul 2018 20:42:38 -0700 (PDT) In-Reply-To: <20180705031615.GO85096@straasha.imrryr.org> References: <20180604203947.GW13834@akamai.com> <20180705023310.GL85096@straasha.imrryr.org> <20180705031615.GO85096@straasha.imrryr.org> From: Eric Rescorla Date: Wed, 4 Jul 2018 20:42:38 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="0000000000001fd1ee057038595e" Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 03:43:23 -0000 --0000000000001fd1ee057038595e Content-Type: text/plain; charset="UTF-8" On Wed, Jul 4, 2018 at 8:16 PM, Viktor Dukhovni wrote: > On Wed, Jul 04, 2018 at 07:46:13PM -0700, Eric Rescorla wrote: > > > > > Do we have a count of major implementors who say they will do so? > > > > > > Well, what is a "major implementation"? > > > > Well, we could start with "what implementations are going to do this"? > > Since Postfix supports not just MTA-to-MTA SMTP, but also SUBMIT, > and I am a maintainer of both the TLS features in Postfix, and the > X.509 code in OpenSSL, I expect to add support for DANE chain in > OpenSSL and Postfix in 2019. Next on the list would be Dovecot and > mutt, but it'd be nice if that was done by one of the primary > maintainers of those packages. > It would be nice to hear from those maintainers, as well as from some of the bigger email senders (e.g., GMail, Yahoo Mail, etc.) > Yes, and this is where grease comes in. Specifically, if implementations > > are required to send empty values (or zero) until something is specified, > > then implementations which *require* those values and choke otherwise go > > undetected. > > Any broken clients will get fixed. The client that motivated this > draft is purported to require the extension, and the others will > take some time to appear, highly likely not until the follow-on > spec is written. The odds of real problems here are negligible. > It has not been my experience or, I think, that of the WG, that this is the case. Rather, once there is a significant fielded population of intolerant endpoints, generating the offending PDU causes too much breakage and instead you have to send something which doesn't break those endpoints. cf. the padding extension, supported_versions, and the CCS hack. > any case, as Martin Thomson says, we have a perfectly good extension > > mechanism which can be used to add pinning later without creating any > > placeholder here. > > At much too much complexity, unless we fork-lift this extension > plus the additional payload, and largely obsolete this draft. Using > one extension to pin itself and another is much too cumbersome. > Yes, I appreciate that this is your opinion. -Ekr --0000000000001fd1ee057038595e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jul 4, 2018 at 8:16 PM, Viktor Dukhovni <<= a href=3D"mailto:ietf-dane@dukhovni.org" target=3D"_blank">ietf-dane@dukhov= ni.org> wrote:
On Wed= , Jul 04, 2018 at 07:46:13PM -0700, Eric Rescorla wrote:

> > > Do we have a count of major implementors who say they will d= o so?
> >
> > Well, what is a "major implementation"?
>
> Well, we could start with "what implementations are going to do t= his"?

Since Postfix supports not just MTA-to-MTA SMTP, but also SUBMIT, and I am a maintainer of both the TLS features in Postfix, and the
X.509 code in OpenSSL, I expect to add support for DANE chain in
OpenSSL and Postfix in 2019.=C2=A0 Next on the list would be Dovecot and mutt, but it'd be nice if that was done by one of the primary
maintainers of those packages.

It would= be nice to hear from those maintainers, as well as from some of the bigger= email senders (e.g., GMail, Yahoo Mail, etc.)


> Yes, and this is where grease comes in. Specifically, if implementatio= ns
> are required to send empty values (or zero) until something is specifi= ed,
> then implementations which *require* those values and choke otherwise = go
> undetected.

Any broken clients will get fixed.=C2=A0 The client that motivated t= his
draft is purported to require the extension, and the others will
take some time to appear, highly likely not until the follow-on
spec is written.=C2=A0 The odds of real problems here are negligible.

It has not been my experience or, I think, t= hat of the WG, that this is the case. Rather, once there is a significant f= ielded population of intolerant endpoints, generating the offending PDU cau= ses too much breakage and instead you have to send something which doesn= 9;t break those endpoints. cf. the padding extension, supported_versions, a= nd the CCS hack.


> any case, as Martin Thomson says, we have a perfectly good extension > mechanism which can be used to add pinning later without creating any<= br> > placeholder here.

At much too much complexity, unless we fork-lift this extension
plus the additional payload, and largely obsolete this draft.=C2=A0 Using one extension to pin itself and another is much too cumbersome.

Yes, I appreciate that this is your opinion.
=

-Ekr


--0000000000001fd1ee057038595e-- From nobody Wed Jul 4 20:59:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC751130DEA for ; Wed, 4 Jul 2018 20:59:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJ-MjHSIlVBj for ; Wed, 4 Jul 2018 20:59:48 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFC22130DDA for ; Wed, 4 Jul 2018 20:59:47 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41LkdZ0jH2z39k; Thu, 5 Jul 2018 05:59:46 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530763186; bh=h4CYIx67s7b5wNew5zEuuhWOo9+QpisTh9xqaeIipHM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=SesQUbbYosr446YtYnFybDwGhXMEXZFdWP0xzdbLnZX6f8uap7mD9Gvfi2eBYIA1m Ib4xPqZJMIrlbnBAvnSRh3NyFC56JrBkNYTElGCc/7GSZolg21wnPObx7/nK0MvfP+ cL2ciLcc6RUGEAnYObJiRlhovZPJouNE1JvLrP9c= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id OZNSTBONYUBG; Thu, 5 Jul 2018 05:59:43 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 5 Jul 2018 05:59:41 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3A1EB79AAE; Wed, 4 Jul 2018 23:59:40 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 3A1EB79AAE Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 2FAF1407821F; Wed, 4 Jul 2018 23:59:40 -0400 (EDT) Date: Wed, 4 Jul 2018 23:59:40 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: "" In-Reply-To: Message-ID: References: <20180604203947.GW13834@akamai.com> <20180705023310.GL85096@straasha.imrryr.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 03:59:52 -0000 On Wed, 4 Jul 2018, Eric Rescorla wrote: > In any case, as Martin Thomson says, we have a perfectly good > extension mechanism which can be used to add pinning later without creating any placeholder here. The IETF should not publish security protocols that are trivially downgraded. The work _should_ really be completed within this document to address all downgrade attacks. As a _compromise_ there have been suggestions done to let this document be published while commiting to a method for downgrade protection. That was not an invitation to punt it to infinity or an invitation to have a bis replace this entire document just to be ignored because some people only care about the DOH case. Besides, we would end up with identical specs apart from two bytes and the same discussion about these two bytes would happen about whether the new document Obsoletes: this one. It won't resolve the issue at all and meanwhile some people have implemented and deployed a protocol that can be trivially downgraded, or bothered to just not implement because it offers no real security benefit. If you don't like TLS extension pinning, come up with another mechanism that resolves the downgrade attack. But note that none of the comments against using two bytes for hour scale extension pinning withstood scrutiny and half of them were appeals to authority or based on people's gut feelings. So far, I've only heard incorrect comparisons with other pinning mechanism problems that ignore the fact that the source of this extension material is in DNSSEC and that the extension data is a "live snapshot" of active DNSSEC data and thus never stale/old/bad/brokeb. > That would first require there being consensus to do pinning. Again, why do you think it would be even valid to have consensus to deploy a trivially downgradable security mechanism? I would certainly expect the IESG to send this back to the drawing board, even if they missed it on their first evaluation round. Paul From nobody Wed Jul 4 21:01:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0FEC1310A7 for ; Wed, 4 Jul 2018 21:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9-hptnPZQE2 for ; Wed, 4 Jul 2018 21:01:24 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D87761310B1 for ; Wed, 4 Jul 2018 21:01:24 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 4461E29A25D; Thu, 5 Jul 2018 00:01:24 -0400 (EDT) Date: Thu, 5 Jul 2018 00:01:24 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180705040124.GP85096@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20180604203947.GW13834@akamai.com> <20180705023310.GL85096@straasha.imrryr.org> <20180705031615.GO85096@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 04:01:29 -0000 On Wed, Jul 04, 2018 at 08:42:38PM -0700, Eric Rescorla wrote: > It would be nice to hear from those maintainers, as well as from some of > the bigger email senders (e.g., GMail, Yahoo Mail, etc.) The question is premature, some implementations are not candidate early adopters. Once library support is there, and there are some early adopters deployed, then the others follow. Postfix implemented DANE in 2014, a bunch additional MTAs added support in 2017 and 2018, and I expect more in 2019. > > Any broken clients will get fixed. The client that motivated this > > draft is purported to require the extension, and the others will > > take some time to appear, highly likely not until the follow-on > > spec is written. The odds of real problems here are negligible. > > It has not been my experience or, I think, that of the WG, that this is the > case. Yes, that's true with major TLS revisions. This extension, however, will not see such rapid uptake that sloppy early versions will need to be revised. You're on the one hand questioning whether any adoption will take place at all, and on the other concerned that early adopters will be intolerant of non-sentinel values of the proposed reserved field. Your first concern is closer to the mark. While I'd like to have the second problem, the reality is that for the first couple of years the number of implementations will be rather small, and the specification of the reserved field can and should predate the bulk of the follow-up implementations. > Rather, once there is a significant fielded population of intolerant > endpoints, generating the offending PDU causes too much breakage and > instead you have to send something which doesn't break those endpoints. cf. > the padding extension, supported_versions, and the CCS hack. Sure, but "significan fielded population" is not a problem we'll be having here for some time. This is a space where uptake will be slow, and the early adopters will be well aware of the requirements. By the time the late adopters arrive, we'll have the downgrade protection fully specified. -- Viktor. From nobody Wed Jul 4 21:40:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C4A4130DE2 for ; Wed, 4 Jul 2018 21:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o6fLdwdY2UJ for ; Wed, 4 Jul 2018 21:40:33 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B10421277CC for ; Wed, 4 Jul 2018 21:40:33 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41LlXZ1yQ4z1Kj for ; Thu, 5 Jul 2018 06:40:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1530765630; bh=LtTmWB0mkzqb+xsT4HjQrqxXflRtJmnRI2rND8OCSec=; h=Date:From:To:Subject:In-Reply-To:References; b=Xrn4BtRUcb7vulDtslVbm2NNwPjBPi27ESiNj3Pe7W92QQ74jSm1zwrfT2dZ/i+B+ 9vxAKTetJIcdHxIoaCO0WZHuc/JZjY2RjZJ1jxxJsZvmvZpoJ9kKtre1cgNnrf3WnJ et8AydF8OYGob2C+Bm3u4W2s2iQRP+K5nZ4eVgAw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id HqPyJlotUgYk for ; Thu, 5 Jul 2018 06:40:27 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Thu, 5 Jul 2018 06:40:26 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D5B7A79AAE; Thu, 5 Jul 2018 00:40:25 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca D5B7A79AAE Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id C95E0407821F for ; Thu, 5 Jul 2018 00:40:25 -0400 (EDT) Date: Thu, 5 Jul 2018 00:40:25 -0400 (EDT) From: Paul Wouters To: tls@ietf.org In-Reply-To: Message-ID: References: <20180604203947.GW13834@akamai.com> <20180705023310.GL85096@straasha.imrryr.org> <20180705031615.GO85096@straasha.imrryr.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 04:40:36 -0000 On Wed, 4 Jul 2018, Eric Rescorla wrote: > > > > Do we have a count of major implementors who say they will do so? > > > > > > Well, what is a "major implementation"? > > > > Well, we could start with "what implementations are going to do this"? [postfix and openssl apparently not big enough ] > It would be nice to hear from those maintainers, as well as from some of the bigger email senders (e.g., GMail, Yahoo Mail, > etc.) This is not a valid direction for this technical discussion, and goes pretty directly against the Tao of the IETF. But if you want to go that way, here is my proposed question to those providers: Do you object to your company's product needing to send two additional zero bytes in a TLS handshake if/when you support DANE stappling in TLS in the case that you do NOT want to be protected from downgrade attacks so that other entities that DO want to support downgrade protection can do so without creating yet another a mostly duplicate internet standard that comes with its own delay in deployment? I am fine with people believing they do not need downgrade protection, although in my experience most downgrade possibilities end up getting abused at some point for malicious purposes. But it would be great if those people could reciprocate that freedom of choice to those that do want downgrade protection so they can make actual security decisions based on this standard. Thank you, Paul From nobody Wed Jul 4 23:46:37 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDAA2130EDE for ; Wed, 4 Jul 2018 23:46:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9xePZvJZVmk for ; Wed, 4 Jul 2018 23:46:33 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8E49130ED1 for ; Wed, 4 Jul 2018 23:46:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D605B4F53C; Thu, 5 Jul 2018 09:46:30 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 6fOwln1cZe4Q; Thu, 5 Jul 2018 09:46:30 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3170573; Thu, 5 Jul 2018 09:46:27 +0300 (EEST) Date: Thu, 5 Jul 2018 09:44:55 +0300 From: Ilari Liusvaara To: Peter Gutmann Cc: "" Message-ID: <20180705064455.GA7996@LK-Perkele-VII> References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> <1530756106390.98539@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1530756106390.98539@cs.auckland.ac.nz> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 06:46:36 -0000 On Thu, Jul 05, 2018 at 02:02:04AM +0000, Peter Gutmann wrote: > Ilari Liusvaara writes: > > >Chrome initially did that. It caused quite a lot of bad feedback from owners > >of various bad embedded stuff. The thread on relevant forums was quite > >something. Hundreds of messages blaming Google for breaking stuff. > > If there were "hundreds of messages" doesn't that indicate that it's Chrome > that's the problem, and not everyone else? Basically with DHE in TLS 1.2, you have very few choices: 1) Advertise DHE, accept weak groups. Vulernable to LOGJAM. 2) Advertise DHE, deny weak groups. Unacceptable failure rates. 3) Do not advertise DHE. Loses FPS with some servers. 4) Try DHE at first and fallback to RSA on too small group. Complex. -Ilari From nobody Thu Jul 5 05:05:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B5A1277BB for ; Thu, 5 Jul 2018 05:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxVfSSt5MO_R for ; Thu, 5 Jul 2018 05:05:06 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 800A6130DE4 for ; Thu, 5 Jul 2018 05:05:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530792305; x=1562328305; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=VjH1TyEySi2B6/Iv6mci+0m0OCnkZTDdlyXehbyL2Hk=; b=UqG3cfRRJ7Nhy1eogBnOVn5WZ41TZzuPJ+HMpuWkl/WoHqodwN15k/LE EzCS/zyJ63WhD7z14QJpLjG2nfBygyyXt6JZb6259l/03ZWQO97AM45L7 /tretgD7llBInxPzYHVeyffmcVD2zZ3hkt268twgN2kQj364JpetT//+c Ga0DWPHd1wiWhlIvqcAsG9IyTU06XR0e0ZDdoweujjU8X3w7PypsIlQ5u G0Ge1yfY1cZtxEl2/1T1n1V0cSydYiYPw2xvId0Gr3LA11bWh63b6hnIW gsf8SWritxiEn7gNaxG31YtHb5Cki5zY5UfDS1Ik6V2TZ0TgkHGdn/tN+ w==; X-IronPort-AV: E=Sophos;i="5.51,312,1526299200"; d="scan'208";a="19769706" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-b.UoA.auckland.ac.nz) ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Jul 2018 00:05:02 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 6 Jul 2018 00:05:02 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Fri, 6 Jul 2018 00:05:02 +1200 From: Peter Gutmann To: Ilari Liusvaara CC: "" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAHzICX//4XzgIABInIY Date: Thu, 5 Jul 2018 12:05:01 +0000 Message-ID: <1530792281962.34902@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> <1530756106390.98539@cs.auckland.ac.nz>, <20180705064455.GA7996@LK-Perkele-VII> In-Reply-To: <20180705064455.GA7996@LK-Perkele-VII> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 12:05:13 -0000 Ilari Liusvaara writes:=0A= =0A= >1) Advertise DHE, accept weak groups. Vulernable to LOGJAM.=0A= =0A= Only if the weak groups you accept are 512 bits.=0A= =0A= A bigger question is, why does Chrome think it's up to it to decide whether= =0A= the device user's choice of key size is appropriate or not? As I mentioned= =0A= earlier, in many cases 1024-bit keys are not only perfectly fine but more t= han=0A= enough. In fact given the hardness of the DLP they're probably OK in=0A= virtually all cases as long as everyone doesn't share the same group2 prime= .=0A= =0A= The crazy thing is that although Chrome rejects a connection to a PFS,=0A= relatively safe (via the DLP's hardness) 1024-bit DHE server, it's perfectl= y=0A= happy connecting to a far less safe (both in terms of factorability and use= of=0A= pure RSA) 1024-bit RSA server. =0A= =0A= This is "security" done backwards!=0A= =0A= Peter.=0A= From nobody Thu Jul 5 06:49:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CABC4130E2A for ; Thu, 5 Jul 2018 06:49:54 -0700 (PDT) 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, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nvR9b_tYm0gQ for ; Thu, 5 Jul 2018 06:49:53 -0700 (PDT) Received: from mail-pl0-f53.google.com (mail-pl0-f53.google.com [209.85.160.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C3ED130E29 for ; Thu, 5 Jul 2018 06:49:53 -0700 (PDT) Received: by mail-pl0-f53.google.com with SMTP id 30-v6so1290175pld.13 for ; Thu, 05 Jul 2018 06:49:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QGKRZXD+j9Ug9aVCQhh9/Ew/4Db05SK5TW3I3tHaCsI=; b=OHI75r83Mk8iABZdTl3HFUNLJPPAhZBGPAmuBa2OmlrnaFanN48CQsbgA6CrqLFhlP NEyY8aRDaGIe2eWT6ffyw8FLPxpkrQftH11ZwpH6bGbiP9I9jJ7QCdr3u5N+TSgCKz5S 2q34C1IupxLptYUREFpSeFm0Cyg6NCmughT9uM5geI6BW7i58HXOogKD96K/Jx3RQ8Sx 11CG8lteCRv9whJu1qO58yAkeN78p0WkClTujEU/cdt5bXlcodyL+Ghggjd1xve8ee1T meMausVaFFgOORmIhOKK5wSkFCOC5Wj+X7nNU8x/5ROq1ggVUdwzU2hsbAiFtWFTGGR1 mJdw== X-Gm-Message-State: APt69E3dOaAq5mHJ5jbumhy01HLV58JMRNBTwUZG1CjMjR+Pwp/xrGUc HXdxzQ9Pd3Z7IGFHcy3Zf2tp8TdqMONMqwUEfTo= X-Google-Smtp-Source: AAOMgpdg3FiO/9fowvr9DBAj10IKxL4XGSOZ/Tu2icMT9FsADYTSHBV6JhOST/zA4e0rpeB/WyTh6cPi4lCB7XPLTz4= X-Received: by 2002:a17:902:7581:: with SMTP id j1-v6mr6311311pll.218.1530798592913; Thu, 05 Jul 2018 06:49:52 -0700 (PDT) MIME-Version: 1.0 References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> <1530756106390.98539@cs.auckland.ac.nz> <20180705064455.GA7996@LK-Perkele-VII> <1530792281962.34902@cs.auckland.ac.nz> In-Reply-To: <1530792281962.34902@cs.auckland.ac.nz> From: Adam Langley Date: Thu, 5 Jul 2018 06:49:37 -0700 Message-ID: To: Peter Gutmann Cc: Ilari Liusvaara , tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 13:49:55 -0000 On Thu, Jul 5, 2018 at 5:05 AM Peter Gutmann wrote: > The crazy thing is that although Chrome rejects a connection to a PFS, > relatively safe (via the DLP's hardness) 1024-bit DHE server, it's perfectly > happy connecting to a far less safe (both in terms of factorability and use of > pure RSA) 1024-bit RSA server. A 2048-bit minimum for RSA acts via the CA/Browser Forum rules: it should not be possible to get a publicly-trusted certificate with a < 2048-bit key and, if it happens, we have proportionate measures to address it. However, it's not practically possible to fix the small DHE defaults across all servers and, even if we could, that would have broken many Java clients. Thus the DHE ecosystem was poisoned and, given that DHE has been exceeded by ECDHE, it wasn't worth trying to save it. We have not (at least so far) acted to enforce a 2048-bit RSA minimum in the client as the CA/BF rules suffice for the vast, vast majority of users. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Thu Jul 5 11:18:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5967F130F78 for ; Thu, 5 Jul 2018 11:18:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M2eojQ8iLuI9 for ; Thu, 5 Jul 2018 11:18:34 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECBB4130F76 for ; Thu, 5 Jul 2018 11:18:30 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 41M5hN0mpPzc8; Thu, 5 Jul 2018 20:18:28 +0200 (CEST) X-purgate-ID: 152705::1530814708-0000081F-9B27ABBF/0/0 X-purgate-size: 2466 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 41M5hM2txXzGpp6; Thu, 5 Jul 2018 20:18:27 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 5820E409B; Thu, 5 Jul 2018 20:18:27 +0200 (CEST) In-Reply-To: <1530757910178.45400@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> <1530757910178.45400@cs.auckland.ac.nz> To: Peter Gutmann Date: Thu, 5 Jul 2018 20:18:27 +0200 (CEST) CC: David Benjamin , Nikos Mavrogiannopoulos , "" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20180705181827.5820E409B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 18:18:44 -0000 Peter Gutmann wrote: > David Benjamin ? writes: > >>The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit >>minimum. (Chrome enabled far more DHE ciphers than others, so we encountered >>a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95% >>of DHE negotiations made by Chrome used a 1024-bit minimum. > > How does Google, rather than the people running the systems being connected > to, know that 1024-bit DH isn't secure enough for a given environment? The > majority of this stuff is running on isolated, private networks or inside VPN > tunnels for which pretty much anything, including 512-bit keys, are fine. Silently removing stuff (support for TLS_DHE) is just as bad as silently adding stuff (automatic, silent and unlimited-times protocol downgrade dance in the broswer which became famously known as POODLE). > > It's also somewhat disturbing that Chrome now walks straight past a perfectly > good PFS DHE suite and instead goes to a problematic pure-RSA one instead. Cough, what? TLS_DHE_ was known to be a security disaster beyond fixing a good decade ago (14-May-2007): https://www.ietf.org/mail-archive/web/tls/current/msg01647.html but it needed a LOGJAM demonstration to have folks look at the crappy implementations in the installed base. We didn't have support for TLS_DHE in our SSL implementation back then, and I decided I never want to have it added. We've added support for TLS_ECDHE a few years ago, but TLS_DHE remains unsupported. Probably most usage scenarios that still offer TLS_DHE today, provide less security than with static-RSA 2048-bit. How often does your SCADA devices (=servers) regenerate its DHE params? If it is using DHparams for several weeks, months or even forever, then there is essentially no PFS, and static RSA will be equal or better than DHE. Static RSA-2048 will always be better than DHE-1024. Simply regenerate and roll your RSA keys&server cert if it makes you feel good. btw. which kind of "problematic pure-RSA" are you talking of? I'm not actually aware of any problem, and I'm much more concerned about TLS servers with longterm DHE params or longterm ECDHE keys and equally about servers using session tickets with a longterm session ticket encryption key, because of the illusion of PFS, which they create but do not offer. -Martin From nobody Thu Jul 5 11:51:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D2DD130F46 for ; Thu, 5 Jul 2018 11:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H5wRpEYNdqFK for ; Thu, 5 Jul 2018 11:51:35 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 391A8130F44 for ; Thu, 5 Jul 2018 11:51:35 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 41M6QY3ZwLzcB; Thu, 5 Jul 2018 20:51:33 +0200 (CEST) X-purgate-ID: 152705::1530816693-000007FB-496F3356/0/0 X-purgate-size: 555 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 41M6QY2WvdzGpjR; Thu, 5 Jul 2018 20:51:33 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 4FA2C409B; Thu, 5 Jul 2018 20:51:33 +0200 (CEST) In-Reply-To: References: <1530687136897.97792@cs.auckland.ac.nz> To: Martin Thomson Date: Thu, 5 Jul 2018 20:51:33 +0200 (CEST) CC: Peter Gutmann , "" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20180705185133.4FA2C409B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 18:51:38 -0000 Martin Thomson wrote: > > The problem with DHE of course being that it uses the TLS 1.0 suites > with the SHA1 MAC and with the MAC and encrypt in the wrong order. I'm confused about what you are thinking here. In TLSv1.0 through TLSv1.2 inclusive, all of the TLS handshake messages, including the *KeyExchange handshake messages (with the exception of Finished) are in the clear and neither MACed nor encrypted, so the ordering MtE vs. EtM for the GenericBlockCipher record PDU seems quite irrelevant. -Martin From nobody Thu Jul 5 16:52:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2512E130E7D for ; Thu, 5 Jul 2018 16:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5LiyLd5Ow88m for ; Thu, 5 Jul 2018 16:52:06 -0700 (PDT) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8441130DE0 for ; Thu, 5 Jul 2018 16:52:06 -0700 (PDT) Received: by mail-oi0-x234.google.com with SMTP id k12-v6so20154149oiw.8 for ; Thu, 05 Jul 2018 16:52:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b5W8aGXRtgfJKr0eGXlzPYErdtyHaWowTRPE1EQkyFk=; b=L8uSyYp+G0rg78sMfHVKJB4QVExOaj2HrVq3JGj942br5rNLDBAuA7r26exoDO/AIp PgS3jEuMzIIpXfUcezBFWmbX980qWuTNwT8OdoUCVpfmyByO+FQTkhJ61b7FrfbNtIkV UdFA0JGz95cN66ZSDtPuAht4R67/mtisK5Uh5p4LhV0Bqt1WLrHVho/iKsTNvjiy32+U LNvKHAesoApGkKLlTDbhQQulFYnQ+WDy0L2oecbl7tUTwyIPpAh1PQjJ+edNft0Jgdz3 ZHQeXFdh8+7s/ugf8HNLplUHpFT0ysEj1TJ1EgvGkdj1r6CFLyM6/dj2DiU/g1cRPcaL t4ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b5W8aGXRtgfJKr0eGXlzPYErdtyHaWowTRPE1EQkyFk=; b=BkclXBTJ5Ip9LTbk8t4LNjHGtHntUMiOsduKXo+AS8NoDw3iPOMHAYWw1H3lV5W6Xk tB3JZ574FthHhcKw0bvsxDe5Prm0hZf8qs4+cUFMLa/b/EI+EmYIxwJUBDBg7stbDL9G 7/3XeMpfQ8Q5OInwTqVQa7te0TXJ8PCwQRKvQQYOx9GG4bnn8D1FjhtbK5HwrqFWyIMx 1od41Te/ODN5PBnNVw58Ps+67CF85js460Aa0Lcd82bejcKem3kKYN78rqaqq7gRSygW bNq59uO1oAFmbMyfXQT4nspVNxFlk9Hay8jIR+gOTxZD0LCZsrGZmw0eV26UbseFoXcc sxMA== X-Gm-Message-State: APt69E1r2EwhvY+SPe3TsRfWni82qO2koRHeyQcvvD3KfD+BSnDaQ3hc ePimn3GMh/dMfCTbf1NpoXvEQZK+6+SRiU4c+go= X-Google-Smtp-Source: AAOMgpcze45V96wFPMjHpjmLzNTqFnVVMEV0FYSmeWo+YoAHTk84J5DcNcwRS3USbRCoHQChpbp2I93nrajmjIRZNbk= X-Received: by 2002:aca:5155:: with SMTP id f82-v6mr9435467oib.272.1530834725975; Thu, 05 Jul 2018 16:52:05 -0700 (PDT) MIME-Version: 1.0 References: <1530687136897.97792@cs.auckland.ac.nz> <20180705185133.4FA2C409B@ld9781.wdf.sap.corp> In-Reply-To: <20180705185133.4FA2C409B@ld9781.wdf.sap.corp> From: Martin Thomson Date: Fri, 6 Jul 2018 09:51:54 +1000 Message-ID: To: mrex@sap.com Cc: Peter Gutmann , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 05 Jul 2018 23:52:09 -0000 On Fri, Jul 6, 2018 at 4:51 AM Martin Rex wrote: > Martin Thomson wrote: > > The problem with DHE of course being that it uses the TLS 1.0 suites > > with the SHA1 MAC and with the MAC and encrypt in the wrong order. > > I'm confused about what you are thinking here. Just that we don't implement MtE because it was hard and AEAD is better, that's all. From nobody Thu Jul 5 18:11:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2287C130FC8 for ; Thu, 5 Jul 2018 18:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qA-3L9sg8VE3 for ; Thu, 5 Jul 2018 18:11:41 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod05.osg.ufl.edu [128.227.74.125]) (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 9735D130FBD for ; Thu, 5 Jul 2018 18:11:40 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.33 Received: from exmbxprd02.ad.ufl.edu ([10.36.133.33]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w661BcT6030665 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Thu, 5 Jul 2018 21:11:39 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd02.ad.ufl.edu (10.36.133.33) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 5 Jul 2018 21:11:38 -0400 Received: from exmbxprd23.ad.ufl.edu (2002:80e3:91a7::80e3:91a7) by exmbxprd23.ad.ufl.edu (2002:80e3:91a7::80e3:91a7) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 5 Jul 2018 21:11:38 -0400 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (216.32.180.120) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Thu, 5 Jul 2018 21:11:38 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHPR22MB1005.namprd22.prod.outlook.com (10.172.167.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Fri, 6 Jul 2018 01:11:35 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f%2]) with mapi id 15.20.0930.016; Fri, 6 Jul 2018 01:11:34 +0000 From: "Patton,Christopher J" To: "tls@ietf.org" Thread-Topic: Key agility issue in draft-ietf-tls-subcerts? Thread-Index: AQHUFMWn2gAlG9rgwUeButqZZBcCqg== Date: Fri, 6 Jul 2018 01:11:34 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8800:9589:e6bd:9963:c22b] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB1005; 7:2SwP3Pe0IcRamLVHdj2OgFt3hQUEQTPdHHUVbFXFyOK0Hj8mxRkEmjnnB1l2sTs0tICHxdftTYaz64M9HW+Z8Um1RYpgA5tIHyMaq7UiABjoEKoPnacuLM75vm7oH+jV0NfYxpw0tDytUuIggsMn/C2ho2k0nBHl5NfQKeuGpwLxk6zZYB4oM0F3jsRc+asbLDSS20LtHTAlWNw4HnTo+dxtp70nsDBEtvw49+yuiHjPspJduDbJUwbmp3mKRYHI x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 82116caa-0733-41cf-2c8d-08d5e2dd6aab x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB1005; x-ms-traffictypediagnostic: MWHPR22MB1005: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(788757137089); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231254)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR22MB1005; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB1005; x-forefront-prvs: 0725D9E8D0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(39860400002)(346002)(396003)(199004)(189003)(6606003)(966005)(25786009)(2906002)(6306002)(5250100002)(46003)(54896002)(7696005)(6506007)(2501003)(8936002)(86362001)(105586002)(106356001)(102836004)(6916009)(33656002)(1730700003)(9686003)(81156014)(81166006)(75432002)(5660300001)(6436002)(55016002)(8676002)(99286004)(236005)(5640700003)(14454004)(786003)(7736002)(316002)(68736007)(606006)(97736004)(74316002)(478600001)(186003)(2900100001)(2351001)(53936002)(476003)(486006)(88552002)(6116002)(19627405001)(256004); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB1005; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: zrUWIr1kuDxhYTLnmYPMrRIJP0c9LkykwXUxgLT5X8k558t1blJV/D3Z+YwGLeCjyZtunNYBwCJkKgSXfqgAqvxAxS4Ao63bkbobkhoE4nZbL9LvmXel8bs2fRhTp5d+nYNLlkNPaQHXYNPjdbqHzWcv0QLql3CFhjJuA4zoh6DNzQkQ/HEhMJpSYOJaYHp8Lk/BAEkTV3x2Pk02pLsXD4+mjaKJ8GG/KkFN6EYsvYQSx0pgVY4t48BaLdaodylk8bUvmRS/5+0wU6Y6qiKcYdDEDPtjAggVN8aO+P/ZiUWEox1jjYkFNA60686NwAjC9iIVOFpAZflxtIIQxKVhvo7LU98k3V4wYcMJnVxS8uI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB0461699E06FBD28ECF75B276C6470MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 82116caa-0733-41cf-2c8d-08d5e2dd6aab X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2018 01:11:34.0349 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB1005 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-05_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=770 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060009 X-UFL-Spam-Level: * Archived-At: Subject: [TLS] Key agility issue in draft-ietf-tls-subcerts? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2018 01:11:45 -0000 --_000_MWHPR22MB0461699E06FBD28ECF75B276C6470MWHPR22MB0461namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The string over which the delegation signature is computed contains the `Su= bjectPublicKeyInfo` of the DC public key. This in turn contains an `Algorit= hmIdentifier`. Does an X.509 `AlgorithmIdentifier` determine a unique TLS `= SignatureScheme`? If not, this might lead to key agility issues, since the server could indic= ate a different signature algorithm (via the `signature_scheme` extension) = than it uses to sign the handshake. I'm not sure if this leads to an attack= , but it's a bit ugly. What we could do is replace the `SubjectPublicKeyInf= o` with the DER-encoded public key and the SignatureScheme. This way the de= legation signature binds to the DC to the signature_algorithm indicated by = the server. This design would seem to be inline with the goal of having the= simplest possible semantics for delegated credentials. Comments are welcome. See also the issue on GitHub: https://github.com/tlsw= g/tls-subcerts/issues/4 Chris Patton --_000_MWHPR22MB0461699E06FBD28ECF75B276C6470MWHPR22MB0461namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The string over which the delegation = signature is computed contains the `SubjectPublicKeyInfo` of the DC public = key. This in turn contains an `AlgorithmIdentifier`. Does an X.509 `Algorit= hmIdentifier` determine a unique TLS `SignatureScheme`?

If not, this might lead to key agility issues, since the server could indic= ate a different signature algorithm (via the `signature_scheme` extension) = than it uses to sign the handshake. I'm not sure if this leads to an attack= , but it's a bit ugly. What we could do is replace the `SubjectPublicKeyInfo` with the DER-encoded public key a= nd the SignatureScheme. This way the delegation signature binds to the DC t= o the signature_algorithm indicated by the server. This design would seem t= o be inline with the goal of having the simplest possible semantics for delegated credentials.&n= bsp;

Comments are welcome. See also the issue on GitHub: https://github.com/tlswg/tls-subcerts/i= ssues/4

Chris Patton



--_000_MWHPR22MB0461699E06FBD28ECF75B276C6470MWHPR22MB0461namp_-- From nobody Thu Jul 5 22:35:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D924130DE2 for ; Thu, 5 Jul 2018 22:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etUZDalpZJAt for ; Thu, 5 Jul 2018 22:35:51 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99AEB130DD0 for ; Thu, 5 Jul 2018 22:35:51 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id DD0BE4F914; Fri, 6 Jul 2018 08:35:48 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 7Oexel5kWXdZ; Fri, 6 Jul 2018 08:35:48 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 5B570286; Fri, 6 Jul 2018 08:35:46 +0300 (EEST) Date: Fri, 6 Jul 2018 08:34:09 +0300 From: Ilari Liusvaara To: "Patton,Christopher J" Cc: "tls@ietf.org" Message-ID: <20180706053409.GA26239@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Key agility issue in draft-ietf-tls-subcerts? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2018 05:35:55 -0000 On Fri, Jul 06, 2018 at 01:11:34AM +0000, Patton,Christopher J wrote: > The string over which the delegation signature is computed contains > the `SubjectPublicKeyInfo` of the DC public key. This in turn > contains an `AlgorithmIdentifier`. Does an X.509 `AlgorithmIdentifier` > determine a unique TLS `SignatureScheme`? Unfortunately not. While the ECDSA and EdDSA keys indeed only have one valid SignatureScheme, RSA keys have three (the difference being using SHA-256 vs. SHA-384 vs. SHA-512). This holds for both genric RSA keys and RSA-PSS keys (and the signatureschemes are different for those two). Also, relying on this even for ECDSA keys might not be a good idea, as if another hash ever gets added, then there could be mulitple SignatureSchemes even for ECDSA keys. -Ilari From nobody Thu Jul 5 23:33:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D0EA130DE2 for ; Thu, 5 Jul 2018 23:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, LOTS_OF_MONEY=0.001, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QXi3yDjZ-QEa for ; Thu, 5 Jul 2018 23:33:40 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 3C9CE1271FF for ; Thu, 5 Jul 2018 23:33:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530858820; x=1562394820; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/W9eUayHTZMflSTKSO3Xh1HRnJLkNkPLU+Pf3KADfFQ=; b=y6J77ZM9ab0mTQUOXMjj3cYyONYrkpx40jo1H92rxW90DnIy7x54jyL6 R9Gd0giBJBQQg7EgPA8w53lOg2dKJ9uEt1ih5GTTeZTAsB0YkGOiH9c8s GkwHaaVCdRln/mGVbf1MW8oKAjkEZ5ktvDObBNp838g4iOK3dBr9FM+us 0bHs/PRwehS20nExh6Lm7sk4EHOcMYJyIT5dpAy8EFGPIX1aaGZju25c2 ISrnUJkEs4j6xfkcX7Z4o1Rz6yhoBdvyZH0+Mf2nTbgWlCkYqj1KYBBeS uVxrfc5hVN7rC3I2aqbcAzlh+iySOdiuVF39W5YCuODUm4UVvrNbmh43i Q==; X-IronPort-AV: E=Sophos;i="5.51,314,1526299200"; d="scan'208";a="19920852" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 06 Jul 2018 18:33:37 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 6 Jul 2018 18:33:37 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Fri, 6 Jul 2018 18:33:36 +1200 From: Peter Gutmann To: "mrex@sap.com" CC: David Benjamin , Nikos Mavrogiannopoulos , "" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAAHUoCAAG4mgIABhdIIgAA/joCAAZX2yw== Date: Fri, 6 Jul 2018 06:33:36 +0000 Message-ID: <1530858795765.38904@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <20180704074101.GA19789@LK-Perkele-VII> <1530691044974.54956@cs.auckland.ac.nz> <20180704081519.GA20000@LK-Perkele-VII> <1530757910178.45400@cs.auckland.ac.nz>, <20180705181827.5820E409B@ld9781.wdf.sap.corp> In-Reply-To: <20180705181827.5820E409B@ld9781.wdf.sap.corp> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2018 06:33:44 -0000 Martin Rex writes:=0A= =0A= >Cough, what? TLS_DHE_ was known to be a security disaster beyond fixing a= =0A= >good decade ago (14-May-2007):=0A= >=0A= > https://www.ietf.org/mail-archive/web/tls/current/msg01647.html=0A= =0A= That's not DHE that's the problem, it's the use of ridiculously short toy k= eys=0A= that were known to be insecure 20-25 years ago when they were mandated for= =0A= export grade use.=0A= =0A= >but it needed a LOGJAM demonstration to have folks look at the crappy=0A= >implementations in the installed base.=0A= =0A= Sure, LOGJAM pointed it out, and spurred fixes (finally), just like FREAK d= id=0A= for RSA (and BEAST did, and POODLE did, and CRIME did, and BREACH did, and= =0A= FLUFFYBUNNY did, and Heartbleed did, it always takes some attack with a coo= l=0A= name before people fix their code). I'm still waiting for a paper to point= =0A= out that 512-bit DSA and secp160 are insecure, I assume the lack of public = use=0A= of these is what's prevented that.=0A= =0A= The point is it has nothing to do with DHE, you've got exactly the same=0A= vulnerability with RSA-512, DH-512, DSA-512, Elgamal-512, and Mr-Not-=0A= Appearing-in-this-List-512. =0A= =0A= LOGJAM had two great contributions, firstly pointing out that there were a= =0A= scary number of servers that still allowed toy keys, and secondly providing= a=0A= baseline where, if you're worth less than several hundred million to severa= l=0A= billion dollars to an attacker, DH-1024 is still OK (as long as it's not=0A= group2, that one's a bit too risky).=0A= =0A= >Probably most usage scenarios that still offer TLS_DHE today, provide less= =0A= >security than with static-RSA 2048-bit.=0A= =0A= Sure, if you choose your DH key to be 512 bits and your RSA key to be 2048,= =0A= you can make that claim. I'm going to choose my RSA key to be 128 bits and= my=0A= DH key to be 16384 bits, in which case DH wins again. And by quite a margi= n,=0A= I must say.=0A= =0A= >How often does your SCADA devices (=3Dservers) regenerate its DHE params?= =0A= =0A= That's a question I can't answer in general because I've only seen the sour= ce=0A= code for a small number of vendor-specific embedded implementations (under= =0A= various NDAs), but both from the code and from knowing the coding style use= d=0A= for these implementations, they'll do so on every connection because that's= =0A= how the textbooks describe it. =0A= =0A= These implementations do just enough to connect to a client or server (some= =0A= act as clients connecting to things like PLC control centres). They are th= e=0A= bare minimum needed to function. Cert processing is done with memcpy() of = a=0A= pre-encoded blob. TLS extensions are encoded with memcpy() and decoded wit= h=0A= memcmp(). You get the picture. No-one would even think of the possibility= of=0A= cacheing DH parameters, let alone sit down and write the code for it.=0A= =0A= >Static RSA-2048 will always be better than DHE-1024. =0A= =0A= Since this will be exposing a private-key op with every decryption oracle a= nd=0A= side channel known to research science directly to anything on the network= =0A= (see the comment above on how these implementations are written), I'm going= to=0A= disagree with you there. With DH you've admittedly still got the RSA sig, = but=0A= that's buried behind/under so much other stuff I doubt it's exploitable.=0A= =0A= >Simply regenerate and roll your RSA keys&server cert if it makes you feel= =0A= >good.=0A= =0A= Since that could involve a firmware reflash (with the new cert coded into t= he=0A= firmware), on a remote device that can never go offline, it's not likely to= =0A= happen.=0A= =0A= In a previous message I mentioned an example of using DSA for TLS. This is= =0A= because you can generate a DSA key in essentially zero memory with a single= =0A= modexp, which completes before the watchdog times out and restarts the syst= em.=0A= You can't do that with RSA in hard real-time. =0A= =0A= Also, there's no way to "roll the cert", it's baked in at the factory or wh= en=0A= the device is deployed. Well, a reflash I guess, but then see above.=0A= =0A= >btw. which kind of "problematic pure-RSA" are you talking of?=0A= =0A= See above, exposing your private key via every kind of side channel and=0A= decryption oracle to a network attacker.=0A= =0A= >because of the illusion of PFS, which they create but do not offer.=0A= =0A= Maybe I shouldn't have mentioned PFS, I used that as an example because it = was=0A= quicker than writing several paragraphs on why pure RSA is dangerous. PFS = is=0A= actually more or less irrelevant for SCADA, it's something cryptographers c= are=0A= about but SCADA folks don't because pretty much all the traffic being carri= ed=0A= is tactical, no-one's worried about an attacker being able to go back later= =0A= and see that you sent a pilot-operated relief valve activation command two= =0A= weeks ago in your non-PFS encrypted traffic.=0A= =0A= Peter.=0A= From nobody Fri Jul 6 07:52:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B094D130E57 for ; Fri, 6 Jul 2018 07:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTHd34Elkimg for ; Fri, 6 Jul 2018 07:52:15 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42038130EBA for ; Fri, 6 Jul 2018 07:52:15 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3F97687A6E; Fri, 6 Jul 2018 14:52:14 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-22.brq.redhat.com [10.40.200.22]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1C81D215688A; Fri, 6 Jul 2018 14:52:11 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: Ilari Liusvaara , "" Date: Fri, 06 Jul 2018 16:51:58 +0200 Message-ID: <4232875.9kvh82n3Lj@pintsize.usersys.redhat.com> In-Reply-To: References: <1857183.8Fq0dhFQ1N@pintsize.usersys.redhat.com> <2034146.0jKBJLNyPE@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2823217.hWFlhrhZEB"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 06 Jul 2018 14:52:14 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Fri, 06 Jul 2018 14:52:14 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] [PSA] 0-RTT tolerance is mandatory X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2018 14:52:18 -0000 --nextPart2823217.hWFlhrhZEB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 4 July 2018 18:50:14 CEST Eric Rescorla wrote: > On Wed, Jul 4, 2018 at 6:27 AM, Hubert Kario wrote: > > On Wednesday, 4 July 2018 15:06:27 CEST Ilari Liusvaara wrote: > > > On Wed, Jul 04, 2018 at 02:42:51PM +0200, Hubert Kario wrote: > > > > All the implementations I deal with in my day-to-day work fail to > >=20 > > handle > >=20 > > > > the 0-RTT client hello correctly when the 0-RTT support is not enab= led > >=20 > > on > >=20 > > > > the server. > > > >=20 > > > > I.e. they ignore the MUST clause from > > > > https://tools.ietf.org/html/draft-ietf-tls-tls13-28#page-58 stating > >=20 > > that > >=20 > > > > the server can handle an early_data extension (and following encryp= ted > > > > data) in only one of three ways, neither which allows for > > > > unconditional > > > > connection abort. > > > >=20 > > > > This also runs afoul the recommendation from > >=20 > > https://tools.ietf.org/html/ > >=20 > > > > draft-ietf-tls-tls13-28#section-D.3 on 0-RTT backwards compatibilit= y. > > >=20 > > > OTOH, such servers probably do not send out tickets allowing 0-RTT, so > > > any client attempting 0-RTT with such server is very broken. > >=20 > > please read Section D.3, it is spelled out in detail there why that's n= ot > > the > > case > >=20 > >=20 > > the short of it: the client has no way of knowing if it is connecting to > > the > > same server/instance/process it received the ticket from >=20 > That's true if you have some kind of mixed rollout, but if you never > supported > 0-RTT, then there is something wrong with the client. yes, from omniscient point of view, there is something wrong from the client but I think we can agree that there are no omniscient TLS server=20 implementations and there won't be for quite some time :) (e.g. there could be a situation with a TLS-enabled transparent proxy betwe= en=20 a client and a server that was later removed =E2=80=93 internal corporate n= etwork vs.=20 coffee shop) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2823217.hWFlhrhZEB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAls/gg4ACgkQkqjRuAHS 9fU4hg/8DhE+1IiupbK69szIT3D59ix5/HcwQ+i3OpUeQuwrY6iic3ubky+pb+xS UaJXXvM48Axt8CQcPTtw8PGQVvPMO03zV6SabbyWtBp90E+EyiwrfLTtcU4TPJAO 0sV9dYlIJJdldwoQmC/R/sY8by2/QCgZLjBA9DkU3vEPwHvHVKXeAESS3bcDpGfa EtA1XvnR1CVUCyLI5pcPbt7ZGV06m/dLwS+EYU3Xz3osE/5yTb7QlNaXXLBr3oNn CrqFXfJHASfRWTz9lBHrkdfYXitg0+M9Yy5DAO3HhyhAYYGx6F3DnwwfrALUvHDp Gn2gdoNhuAnuVjHszJ7MoHMmEJykkhTftHA4jetDTZnA46Gyc3PNmC8nqXcYryxq q7uhWEyF7YZpG0WqdXlN3RHqwPR97BfPwaMQWjCZbhnHSi14v3ConfxZzIR0GVbL QFPNbnB3j1th75c1CMBAwqbj5LTcukgE5bSZ8JjUKe/rTGiN4WKf608ovrAsExuo 8wUXvljw1TXQ2tbMb3qYZ1SJvgHqy5pA0uN5Ihv7ZTQghikr7oKD3ygYPUUjhvll To5cx7iwffHvymGTMcuLkZ9iv3X4jf/nkiDd8lpmcGtfEtfYJNdEBp3FR+vuVjto 8+o+xcwlDk5ynrsh2kuKYM0bylIuMMuwMqKPCzySHbAwWrSf8bU= =DzYO -----END PGP SIGNATURE----- --nextPart2823217.hWFlhrhZEB-- From nobody Fri Jul 6 13:22:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31F1D130F17 for ; Fri, 6 Jul 2018 13:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.709 X-Spam-Level: X-Spam-Status: No, score=-2.709 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgZ6kthe92_V for ; Fri, 6 Jul 2018 13:22:07 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FAC3130F0E for ; Fri, 6 Jul 2018 13:22:07 -0700 (PDT) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w66KLfGa015410; Fri, 6 Jul 2018 21:22:05 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=RBqp3uWeFXeZuyxPsabS12bPAkbwCFYD3DGC6Cl5+WE=; b=nuEH9Qfmo9HVjxMFs9KQN8Qt1Mg6XcpElFN0bkix1l9lnhG7G7Nkl/7Jff6WOMJe/xEd nGZj8BoZ5qtBYGQN0tZ/eoIDu2HzInCTk2QcXexBclkDhIH+gaOvN+cefn6zjCIrDJBR tonirP8nZ3IveUkqqOhq49tXJnoOCEjnWCSA8+uFW+TVW8Kq1fkGI4HRE0maSf8RBlLg bEwgQjHyVXX0SLW4YfJXuBj9E+/nJSg/RVngXJythSsJg6+EBIRf6iPHAP+fcBSkFpaI LpYGhfMhz3rW62F3KRYokfuh1LsK5SFOtMD0Kx8u8rOliq8XVJOYi6TBWAKTZICSvNQB ng== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2k0vct0w99-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Jul 2018 21:22:05 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w66Jo0dm012205; Fri, 6 Jul 2018 15:55:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2jx57b1tc3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 Jul 2018 15:55:14 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 6 Jul 2018 14:55:12 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Fri, 6 Jul 2018 14:55:12 -0500 From: "Short, Todd" To: "" CC: Eric Rescorla , "Sniffen, Brian" Thread-Topic: [TLS] DNS-based Encrypted SNI Thread-Index: AQHUEl5BbRY0wnPzbU+tvvqDIqSVJKR94qgAgAUS64A= Date: Fri, 6 Jul 2018 19:55:12 +0000 Message-ID: References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> In-Reply-To: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.145] Content-Type: multipart/alternative; boundary="_000_B266359D218742F5AFB55E55D9D060E7akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060222 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060229 Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2018 20:22:09 -0000 --_000_B266359D218742F5AFB55E55D9D060E7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnVuZGFtZW50YWxseSwgdW5sZXNzIHRoaXMgdHlwZSBvZiBwcm90ZWN0aW9uIGlzIGJha2VkIGlu dG8gdGhlIHByb3RvY29sIGZyb20gdGhlIGJlZ2lubmluZywgYW5kIGlzIG5vdCBhbiBhZGQtb24g b3B0aW9uLCBhbnkgb25lL3RoaW5nIGluIHRoZSBwYXRoIGNhbiBwcmV2ZW50IHRoZSB1c2Ugb2Yg b3B0aW9uYWwgc2VjdXJpdHkgZmVhdHVyZXMuDQoNCkRvbuKAmXQgd2FudCBwZW9wbGUgdG8gYWNj ZXNzIHNpdGUgWFlaPyBCbG9jayBETlNTRUMsIGJsb2NrIF9FU05JIEROUyByZXF1ZXN0cy9yZXNw b25zZXMsIGJsb2NrIHRoZSB1c2Ugb2YgRVNOSSwgZXRjLg0KDQpBIGZpcmV3YWxsIGNhbiBhbHNv IHVzZSB0aGUgcmVjb3JkX2RpZ2VzdCB0byBkZXRlcm1pbmUgdGhlIGRlc3RpbmF0aW9uLCB3aXRo b3V0IGV2ZW4gZGVjcnlwdGluZyB0aGUgRVNOSS4gSXQganVzdCBjYWxjdWxhdGVzIHRoZSBwb3Nz aWJsZSByZWNvcmRfZGlnZXN0cyBvZiB0aGUgYmxvY2tlZCBzaXRlczsgc2luY2UgdGhlIGluZm9y bWF0aW9uIGlzIHB1YmxpYy4gVGhpcyB3aWxsIG1ha2UgaXQgYXBwZWFyIHRoYXQgRVNOSSBpcyBz dXBwb3J0ZWQgKGZvciBsZWdhbCBzaXRlcyksIGJ1dCBzdGlsbCBibG9jayB0aGUgdXNlIHRvIGls bGVnYWwgc2l0ZXMuDQoNCk9yIGV2ZW4gZG8gYSByZXZlcnNlLUROUyBsb29rdXAgb24gdGhlIGRl c3RpbmF0aW9uIElQLCBkaXNjb3ZlciBhbGwgdGhlIGRvbWFpbnMgdGhlcmUsIGFuZCB0aGVuIGNh bGN1bGF0ZSB0aGUgcG9zc2libGUgcmVjb3JkX2RpZ2VzdHMgdG8gc2VlIHdoZXJlIHRoZSB1c2Vy IGlzIGdvaW5nLg0KDQpUaGlzIGNvdWxkIGJlIG1pdGlnYXRlZCBieSBoYXZpbmcgdGhlIHNhbWUg RVNOSUtleXMgZm9yIGRpZmZlcmVudCB3ZWJzaXRlcywgYnV0IHRoYXQgbWVhbnMgdGhlICJTcGxp dCBNb2RlIFRvcG9sb2d5IiBpcyBicm9rZW4gYXMgdGhlIHJlY29yZF9kaWdlc3QgY2Fubm90IGJl IHVzZWQgYnkgdGhlIENsaWVudC1GYWNpbmcgU2VydmVyIHRvIHNlbGVjdCBhIEJhY2tlbmQgU2Vy dmVyLiBBaCwgYnV0IGlmIHRoZSBDRE4gbWFwcyB0aGUgc2hhcmVkLUVTTklLZXlzIGRvbWFpbnMg dG8gYmUgZGlmZmVyZW50IElQcywgdGhlbiBkb2VzbuKAmXQgbWF0dGVyLiBUaGlzIGlzIG5vdCB0 aGUgY2FzZSwgYXMgdGhlIElQIGFkZHJlc3MgY2FuIG5vdyBiZSB1c2VkIGFsb25nIHdpdGggdGhl IEVTTklLZXlzIHRvIGtub3cgd2hhdCB0aGUgZmluYWwgZGVzdGluYXRpb24gaXMuDQoNCi0tDQot VG9kZCBTaG9ydA0KLy8gdHNob3J0QGFrYW1haS5jb208bWFpbHRvOnRzaG9ydEBha2FtYWkuY29t Pg0KLy8gIk9uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50 ZXJuZXQuIg0KDQpPbiBKdWwgMywgMjAxOCwgYXQgMTA6MjYgQU0sIFNuaWZmZW4sIEJyaWFuIDxi c25pZmZlbj00MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmJzbmlmZmVuPTQwYWth bWFpLmNvbUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpMb29rcyBuZWF0Lg0KDQoxKSBURk8g RE9TIHZlY3RvcjogaXMgdGhlIGlkZWEgc2VydmVycyB3aWxsIGRpc2FibGUgVEZPIHVuZGVyIHN0 cmFpbiBidXQgbm90IGJlIGFibGUgdG8gZGlzYWJsZSBFU05JPw0KDQoyKSDigJxjbGllbnRzIG1p Z2h0IG9wdCB0byBhdHRlbXB0IGNhcHRpdmUgcG9ydGFsIGRldGVjdGlvbiB0byBzZWUgaWYgdGhl eSBhcmUgaW4gdGhlIHByZXNlbmNlIG9mIGEgTUlUTSBwcm94eSwgYW5kIGlmIHNvIGRpc2FibGUg RVNOSS7igJ0NCg0KSWYgSeKAmW0gb3BlcmF0aW5nIGEgZ3JlYXQgZmlyZXdhbGwsIEkgY2FuIHVz ZSB0aGlzIHRvIGRpc2NvdmVyIGRpc3NpZGVudHMsIHJpZ2h0PyAgRWl0aGVyIHRoZXkgc2VuZCBt ZSBkYW5nZXJvdXMgU05JIHZhbHVlcyBvciB0aGV5IGFyZSBjb25maWd1cmVkIHRvIG5vdCBkaXNh YmxlIEVTTkksIGFuZCB0YWtpbmcgdGhlIGZpZnRoIGlzIGZhdGFsLiBUbyBwcm90ZWN0IHRoZW0s IEkgdGhpbmsgbm9ib2R5IGNhbiBoYXZlIHRoaXMgbW9kZS4NCg0KMykgSG93IG1hbnkgYml0cyBk b2VzIHRoaXMgb2ZmZXI/IEhpZGluZyBpbiBhIHNldCBvZiBhIG1pbGxpb24gdW5pZm9ybSBob3N0 cyBpcyAyMCBiaXRzLCBhbmQgdGhlIG5vbnVuaWZvcm1pdHkgd2lsbCBhY2NydWUgdG8gdGhlIGFk dmVyc2FyeeKAmXMgYmVuZWZpdC4gQWN0aXZlIHByb2Jpbmcgd2lsbCB1bm1hc2sgdmlzaXRvcnMg dG8gZGlzc2lkZW50IHNpdGVzLg0KDQpJIHdvcnJ5IHRoYXQgdGhpcyB0b29sIGlzIHNvIHdlYWsg YWdhaW5zdCBhIEdGVy1zdHlsZSBhZHZlcnNhcnkgZm9yIHRoZSBwdXJwb3NlIG9mIGFsbG93aW5n IGRpc3NpZGVudCBhY2Nlc3MgdG8gcmVzdHJpY3RlZCB3ZWIgc2l0ZXMgdGhhdCBpdCB3aWxsIGJl IGRhbmdlcm91cyBpZiByZWxlYXNlZC4gQnV0IG1heWJlIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHVy cG9zZS4gSWYgdGhpcyBpcyBqdXN0IHRvIGtlZXAgV2VzdGVybiBJU1BzIGZyb20gbW9ua2V5aW5n IHdpdGggdHJhZmZpYywgc3VyZSwgc2hpcCBpdC4gIExhYmVsbGluZyB0aGUgZW5jcnlwdGlvbiB3 aXRoIGl0cyBzdHJlbmd0aCBhcyBhcHBsaWVkLCBvciBzaG93aW5nIENETnMgYW5kIElTUHMgaG93 IHRvIHdvcmsgb3V0IHNvbWUgYm91bmRzLCBzZWVtcyBvbmUgd2F5IHRvIGhlbHAgdXNlcnMgdW5k ZXJzdGFuZCB3aGV0aGVyIHRoaXMgY2FuIGhlbHAgdGhlbSBvciBwdXQgdGhlbSBtb3JlIGF0IHJp c2suDQoNCi0tDQpCcmlhbiBTbmlmZmVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRv OlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz DQoNCg== --_000_B266359D218742F5AFB55E55D9D060E7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCkZ1bmRhbWVudGFsbHksIHVubGVzcyB0aGlzIHR5 cGUgb2YgcHJvdGVjdGlvbiBpcyBiYWtlZCBpbnRvIHRoZSBwcm90b2NvbCBmcm9tIHRoZSBiZWdp bm5pbmcsIGFuZCBpcyBub3QgYW4gYWRkLW9uIG9wdGlvbiwgYW55IG9uZS90aGluZyBpbiB0aGUg cGF0aCBjYW4gcHJldmVudCB0aGUgdXNlIG9mIG9wdGlvbmFsIHNlY3VyaXR5IGZlYXR1cmVzLg0K PGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RG9u4oCZ dCB3YW50IHBlb3BsZSB0byBhY2Nlc3Mgc2l0ZSBYWVo/IEJsb2NrIEROU1NFQywgYmxvY2sgX0VT TkkgRE5TIHJlcXVlc3RzL3Jlc3BvbnNlcywgYmxvY2sgdGhlIHVzZSBvZiBFU05JLCBldGMuPC9k aXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5B IGZpcmV3YWxsIGNhbiBhbHNvIHVzZSB0aGUgcmVjb3JkX2RpZ2VzdCB0byBkZXRlcm1pbmUgdGhl IGRlc3RpbmF0aW9uLCB3aXRob3V0IGV2ZW4gZGVjcnlwdGluZyB0aGUgRVNOSS4gSXQganVzdCBj YWxjdWxhdGVzIHRoZSBwb3NzaWJsZSByZWNvcmRfZGlnZXN0cyBvZiB0aGUgYmxvY2tlZCBzaXRl czsgc2luY2UgdGhlIGluZm9ybWF0aW9uIGlzIHB1YmxpYy4gVGhpcyB3aWxsIG1ha2UgaXQgYXBw ZWFyIHRoYXQgRVNOSQ0KIGlzIHN1cHBvcnRlZCAoZm9yIGxlZ2FsIHNpdGVzKSwgYnV0IHN0aWxs IGJsb2NrIHRoZSB1c2UgdG8gaWxsZWdhbCBzaXRlcy48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPk9yIGV2ZW4gZG8gYSByZXZlcnNlLURO UyBsb29rdXAgb24gdGhlIGRlc3RpbmF0aW9uIElQLCBkaXNjb3ZlciBhbGwgdGhlIGRvbWFpbnMg dGhlcmUsIGFuZCB0aGVuIGNhbGN1bGF0ZSB0aGUgcG9zc2libGUgcmVjb3JkX2RpZ2VzdHMgdG8g c2VlIHdoZXJlIHRoZSB1c2VyIGlzIGdvaW5nLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xh c3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhpcyBjb3VsZCBiZSBtaXRpZ2F0ZWQgYnkg aGF2aW5nIHRoZSBzYW1lIEVTTklLZXlzIGZvciBkaWZmZXJlbnQgd2Vic2l0ZXMsIGJ1dCB0aGF0 IG1lYW5zIHRoZSAmcXVvdDtTcGxpdCBNb2RlIFRvcG9sb2d5JnF1b3Q7IGlzIGJyb2tlbiBhcyB0 aGUgcmVjb3JkX2RpZ2VzdCBjYW5ub3QgYmUgdXNlZCBieSB0aGUgQ2xpZW50LUZhY2luZyBTZXJ2 ZXIgdG8gc2VsZWN0IGEgQmFja2VuZCBTZXJ2ZXIuIEFoLCBidXQgaWYgdGhlIENETiBtYXBzDQog dGhlIHNoYXJlZC1FU05JS2V5cyBkb21haW5zIHRvIGJlIGRpZmZlcmVudCBJUHMsIHRoZW4gZG9l c27igJl0IG1hdHRlci4gVGhpcyBpcyBub3QgdGhlIGNhc2UsIGFzIHRoZSBJUCBhZGRyZXNzIGNh biBub3cgYmUgdXNlZCBhbG9uZyB3aXRoIHRoZSBFU05JS2V5cyB0byBrbm93IHdoYXQgdGhlIGZp bmFsIGRlc3RpbmF0aW9uIGlzLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0i Y29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0 bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu b25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsg LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAtd2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRl LXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0 ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5zOiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4 dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zvcm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7 IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsgd29yZC13cmFwOiBicmVhay13b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7 IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYg Y2xhc3M9IiI+LS08L2Rpdj4NCjxkaXYgY2xhc3M9IiI+LVRvZGQgU2hvcnQ8L2Rpdj4NCjxkaXYg Y2xhc3M9IiI+Ly8gPGEgaHJlZj0ibWFpbHRvOnRzaG9ydEBha2FtYWkuY29tIiBjbGFzcz0iIj50 c2hvcnRAYWthbWFpLmNvbTwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ly8gJnF1b3Q7T25lIGlm IGJ5IGxhbmQsIHR3byBpZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4mcXVvdDs8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPGJsb2Nr cXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPk9uIEp1bCAzLCAyMDE4 LCBhdCAxMDoyNiBBTSwgU25pZmZlbiwgQnJpYW4gJmx0OzxhIGhyZWY9Im1haWx0bzpic25pZmZl bj00MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmciIGNsYXNzPSIiPmJzbmlmZmVuPTQwYWthbWFp LmNvbUBkbWFyYy5pZXRmLm9yZzwvYT4mZ3Q7IHdyb3RlOjwvZGl2Pg0KPGJyIGNsYXNzPSJBcHBs ZS1pbnRlcmNoYW5nZS1uZXdsaW5lIj4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPkxv b2tzIG5lYXQuIDxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCjEpIFRGTyBET1MgdmVjdG9y OiBpcyB0aGUgaWRlYSBzZXJ2ZXJzIHdpbGwgZGlzYWJsZSBURk8gdW5kZXIgc3RyYWluIGJ1dCBu b3QgYmUgYWJsZSB0byBkaXNhYmxlIEVTTkk/PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K Mikg4oCcY2xpZW50cyBtaWdodCBvcHQgdG8gYXR0ZW1wdCBjYXB0aXZlIHBvcnRhbCBkZXRlY3Rp b24gdG8gc2VlIGlmIHRoZXkgYXJlIGluIHRoZSBwcmVzZW5jZSBvZiBhIE1JVE0gcHJveHksIGFu ZCBpZiBzbyBkaXNhYmxlIEVTTkku4oCdPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KSWYg SeKAmW0gb3BlcmF0aW5nIGEgZ3JlYXQgZmlyZXdhbGwsIEkgY2FuIHVzZSB0aGlzIHRvIGRpc2Nv dmVyIGRpc3NpZGVudHMsIHJpZ2h0PyAmbmJzcDtFaXRoZXIgdGhleSBzZW5kIG1lIGRhbmdlcm91 cyBTTkkgdmFsdWVzIG9yIHRoZXkgYXJlIGNvbmZpZ3VyZWQgdG8gbm90IGRpc2FibGUgRVNOSSwg YW5kIHRha2luZyB0aGUgZmlmdGggaXMgZmF0YWwuIFRvIHByb3RlY3QgdGhlbSwgSSB0aGluayBu b2JvZHkgY2FuIGhhdmUgdGhpcyBtb2RlLg0KPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K MykgSG93IG1hbnkgYml0cyBkb2VzIHRoaXMgb2ZmZXI/IEhpZGluZyBpbiBhIHNldCBvZiBhIG1p bGxpb24gdW5pZm9ybSBob3N0cyBpcyAyMCBiaXRzLCBhbmQgdGhlIG5vbnVuaWZvcm1pdHkgd2ls bCBhY2NydWUgdG8gdGhlIGFkdmVyc2FyeeKAmXMgYmVuZWZpdC4gQWN0aXZlIHByb2Jpbmcgd2ls bCB1bm1hc2sgdmlzaXRvcnMgdG8gZGlzc2lkZW50IHNpdGVzLjxiciBjbGFzcz0iIj4NCjxiciBj bGFzcz0iIj4NCkkgd29ycnkgdGhhdCB0aGlzIHRvb2wgaXMgc28gd2VhayBhZ2FpbnN0IGEgR0ZX LXN0eWxlIGFkdmVyc2FyeSBmb3IgdGhlIHB1cnBvc2Ugb2YgYWxsb3dpbmcgZGlzc2lkZW50IGFj Y2VzcyB0byByZXN0cmljdGVkIHdlYiBzaXRlcyB0aGF0IGl0IHdpbGwgYmUgZGFuZ2Vyb3VzIGlm IHJlbGVhc2VkLiBCdXQgbWF5YmUgSSBtaXN1bmRlcnN0YW5kIHRoZSBwdXJwb3NlLiBJZiB0aGlz IGlzIGp1c3QgdG8ga2VlcCBXZXN0ZXJuIElTUHMgZnJvbSBtb25rZXlpbmcNCiB3aXRoIHRyYWZm aWMsIHN1cmUsIHNoaXAgaXQuICZuYnNwO0xhYmVsbGluZyB0aGUgZW5jcnlwdGlvbiB3aXRoIGl0 cyBzdHJlbmd0aCBhcyBhcHBsaWVkLCBvciBzaG93aW5nIENETnMgYW5kIElTUHMgaG93IHRvIHdv cmsgb3V0IHNvbWUgYm91bmRzLCBzZWVtcyBvbmUgd2F5IHRvIGhlbHAgdXNlcnMgdW5kZXJzdGFu ZCB3aGV0aGVyIHRoaXMgY2FuIGhlbHAgdGhlbSBvciBwdXQgdGhlbSBtb3JlIGF0IHJpc2suDQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQotLSA8YnIgY2xhc3M9IiI+DQpCcmlhbiBTbmlm ZmVuPGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX188YnIgY2xhc3M9IiI+DQpUTFMgbWFpbGluZyBsaXN0PGJy IGNsYXNzPSIiPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyIgY2xhc3M9IiI+VExTQGll dGYub3JnPC9hPjxiciBjbGFzcz0iIj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdGxzPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B266359D218742F5AFB55E55D9D060E7akamaicom_-- From nobody Fri Jul 6 13:43:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76893130DE3 for ; Fri, 6 Jul 2018 13:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8XQaX4Xj3Zaq for ; Fri, 6 Jul 2018 13:43:13 -0700 (PDT) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 722F9130DDC for ; Fri, 6 Jul 2018 13:43:13 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id k18-v6so4621770ywm.11 for ; Fri, 06 Jul 2018 13:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPC6yI6AQpt/m8NeAi4wleex9+g0fHENsrdeum4Xttg=; b=VgQHYvqUaQ5MJ6XMCVeoK3WrsMUI+X1lhg7y0Btdll/VjRvnjLAI+VhM44l4X5S7Ll xBE/yn6JhY8NLCGJXdcSvySFLljQwdAz2Yj0WHYhgoFciTO3UYrfqxcOVBmhIxvamVyh 0AYfEjRtVEhYPw5uBrAlaHsz9n0rrC/kKDFI9pLiS9JUtGbMysy4Pl1BFARMf81aYcbf N5x4/sqLPJzq4GBaIHs6CYr6WIjnrJHr9rCzkeqIEP5zSeVWuIPBUKf2W8Pyzz8iUg2A +zaIe0aM6CWWlzmlZu1LWVVKog8MLa6bv4u0B/3+lyaB476OqLaas0aiSxqH0FEcaL/V DdDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kPC6yI6AQpt/m8NeAi4wleex9+g0fHENsrdeum4Xttg=; b=sGATQTjDbhTFS9Mh7ZEvCcket5qNlnqJFzQJ+vWwwsuzxs+z0l9v2Z2OKIof8jV/wp 8D1Ry2hVtvp/urOoSLnYJazLlN4fh/5LX1TLEL9ZFqzX3wts1pG2eZk7tMSu8Z3VTDD1 i4xekLX4nsETB4UdXSSBT7V/FgOU/EHdpXCXgu5bLOI2KcfWe4TGHXrpux0mihdjtyeC uMWHnA1TD+CqI/xHtRN+52l4Hxg4Vm7WuKi4zX7GTUqa49eGy76WL5uYYOcY6TFIz6bp 8IhdETAFCvGo/rdv9bjUSZV8NwPZX0xOmBwSRg20zAp/HkXXuRP/Yw79qXFKJNFdlvjT NqMg== X-Gm-Message-State: APt69E2+BWNv7kps3aRbiH3j2bPR/up+pV3vbDC0VKQoy0QLs6ZJkVCp iR6oul+jIX5ehapykjmUJIUGRE42cSdBB17B3polCw== X-Google-Smtp-Source: AAOMgpe7vQsw7rpxNAYmvHM2UDv4146zwgD6Kdac9/nLig3eGgXwA7QBzSmHxNggDBt0pai+8HefNHUdgIC5xpIcABM= X-Received: by 2002:a81:2ec8:: with SMTP id u191-v6mr5621847ywu.430.1530909792325; Fri, 06 Jul 2018 13:43:12 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 13:42:31 -0700 (PDT) In-Reply-To: References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 13:42:31 -0700 Message-ID: To: "Short, Todd" Cc: "" , "Sniffen, Brian" Content-Type: multipart/alternative; boundary="0000000000005ae93505705ab6d7" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2018 20:43:17 -0000 --0000000000005ae93505705ab6d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd wrote: > Fundamentally, unless this type of protection is baked into the protocol > from the beginning, and is not an add-on option, any one/thing in the pat= h > can prevent the use of optional security features. > > Don=E2=80=99t want people to access site XYZ? Block DNSSEC, block _ESNI D= NS > requests/responses, block the use of ESNI, etc. > These are sort of different things. It's true that if you control DNS, it's basically game over, which is why this is most attractive with DOH to some location not controlled by the censor. However, if you *do* have DOH, then the client shouldn't fall back, with the result that blocking ESNI blocks all ESNI-enabled sites, not just those which are sensitive > A firewall can also use the record_digest to determine the destination, > without even decrypting the ESNI. It just calculates the possible > record_digests of the blocked sites; since the information is public. Thi= s > will make it appear that ESNI is supported (for legal sites), but still > block the use to illegal sites. > > Or even do a reverse-DNS lookup on the destination IP, discover all the > domains there, and then calculate the possible record_digests to see wher= e > the user is going. > > This could be mitigated by having the same ESNIKeys for different > websites, but that means the "Split Mode Topology" is broken as the > record_digest cannot be used by the Client-Facing Server to select a > Backend Server. > I think you may be misunderstanding the design here. All of the ESNI-enabled sites behind the same client-facing server (split mode or not) use the same keys, and hence have the same record_digest. Thus, record_digest is just an alias for anonymity set. The client-facing server does not use the record_digest to select the backend server. It uses the record_digest to find which of the keys it has offered and then uses that key to decrypt the true SNI. Note that in some naive sense you don't need a record_digest at all. It's just there to facilitate the client-facing server having multiple valid ESNI key sets (e.g., for rollover) at one time= . Ah, but if the CDN maps the shared-ESNIKeys domains to be different IPs, > then doesn=E2=80=99t matter. This is not the case, as the IP address can = now be > used along with the ESNIKeys to know what the final destination is. > Yes, you need to use the same IPs. -Ekr > -- > -Todd Short > // tshort@akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Jul 3, 2018, at 10:26 AM, Sniffen, Brian ietf.org> wrote: > > Looks neat. > > 1) TFO DOS vector: is the idea servers will disable TFO under strain but > not be able to disable ESNI? > > 2) =E2=80=9Cclients might opt to attempt captive portal detection to see = if they > are in the presence of a MITM proxy, and if so disable ESNI.=E2=80=9D > > If I=E2=80=99m operating a great firewall, I can use this to discover dis= sidents, > right? Either they send me dangerous SNI values or they are configured t= o > not disable ESNI, and taking the fifth is fatal. To protect them, I think > nobody can have this mode. > > 3) How many bits does this offer? Hiding in a set of a million uniform > hosts is 20 bits, and the nonuniformity will accrue to the adversary=E2= =80=99s > benefit. Active probing will unmask visitors to dissident sites. > > I worry that this tool is so weak against a GFW-style adversary for the > purpose of allowing dissident access to restricted web sites that it will > be dangerous if released. But maybe I misunderstand the purpose. If this = is > just to keep Western ISPs from monkeying with traffic, sure, ship it. > Labelling the encryption with its strength as applied, or showing CDNs an= d > ISPs how to work out some bounds, seems one way to help users understand > whether this can help them or put them more at risk. > > -- > Brian Sniffen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --0000000000005ae93505705ab6d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd <tshort@akamai.com>= ; wrote:
Fundamentally, unless this type of protection is baked into the protocol fr= om the beginning, and is not an add-on option, any one/thing in the path ca= n prevent the use of optional security features.

Don=E2=80=99t want people to access site XYZ? Block DNSSEC, block _ESN= I DNS requests/responses, block the use of ESNI, etc.

These are sort of different things. It's true th= at if you control DNS, it's basically game over, which is why this is m= ost attractive with DOH to some location not controlled by the censor. Howe= ver, if you *do* have DOH, then the client shouldn't fall back, with th= e result that blocking ESNI blocks all ESNI-enabled sites, not just those w= hich are sensitive

=C2=A0
A firewall can also use the record_digest to determine the destination= , without even decrypting the ESNI. It just calculates the possible record_= digests of the blocked sites; since the information is public. This will ma= ke it appear that ESNI is supported (for legal sites), but still block the use to illegal sites.<= /div>

Or even do a reverse-DNS lookup on the destination IP, discover all th= e domains there, and then calculate the possible record_digests to see wher= e the user is going.

This could be mitigated by having the same ESNIKeys for different webs= ites, but that means the "Split Mode Topology" is broken as the r= ecord_digest cannot be used by the Client-Facing Server to select a Backend= Server.

I think you may be mis= understanding the design here. All of the ESNI-enabled sites behind the sam= e client-facing server (split mode or not) use the same keys, and hence hav= e the same record_digest. Thus, record_digest is just an alias for anonymit= y set. The client-facing server does not use the record_digest to select th= e backend server. It uses the record_digest to find which of the keys it ha= s offered and then uses that key to decrypt the true SNI. Note that in some= naive sense you don't need a record_digest at all. It's just there= to facilitate the client-facing server having multiple valid ESNI key sets= (e.g., for rollover) at one time.


<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Ah, but if the CDN maps the shared-ESNIKeys domains to be different IPs, then doesn=E2=80=99t matt= er. This is not the case, as the IP address can now be used along with the = ESNIKeys to know what the final destination is.=C2=A0

Yes, you need to use the same IPs.

-Ekr


--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

On Jul 3, 2018, at 10:26 AM, Sniffen, Brian <bsniffen=3D40akamai.c= om@dmarc.ietf.org> wrote:

Looks neat.

1) TFO DOS vector: is the idea servers will disable TFO under strain but no= t be able to disable ESNI?

2) =E2=80=9Cclients might opt to attempt captive portal detection to see if= they are in the presence of a MITM proxy, and if so disable ESNI.=E2=80=9D=

If I=E2=80=99m operating a great firewall, I can use this to discover dissi= dents, right?=C2=A0 Either they send me dangerous SNI values or they are co= nfigured to not disable ESNI, and taking the fifth is fatal. To protect the= m, I think nobody can have this mode.

3) How many bits does this offer? Hiding in a set of a million uniform host= s is 20 bits, and the nonuniformity will accrue to the adversary=E2=80=99s = benefit. Active probing will unmask visitors to dissident sites.

I worry that this tool is so weak against a GFW-style adversary for the pur= pose of allowing dissident access to restricted web sites that it will be d= angerous if released. But maybe I misunderstand the purpose. If this is jus= t to keep Western ISPs from monkeying with traffic, sure, ship it.=C2=A0 Labelling the encryption with its stren= gth as applied, or showing CDNs and ISPs how to work out some bounds, seems= one way to help users understand whether this can help them or put them mo= re at risk.

--
Brian Sniffen

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


--0000000000005ae93505705ab6d7-- From nobody Fri Jul 6 14:41:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3CC713107B for ; Fri, 6 Jul 2018 14:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.29 X-Spam-Level: ** X-Spam-Status: No, score=2.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_ROLEX=5, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOU2YnBV7hVT for ; Fri, 6 Jul 2018 14:41:37 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86A051310AF for ; Fri, 6 Jul 2018 14:41:36 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w66Lfaer006489; Fri, 6 Jul 2018 22:41:36 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : content-transfer-encoding; s=jan2016.eng; bh=29o8M5M9Ef4NhJx1I9+ck/XwuCDOcjrV6dbaNMRohBY=; b=bl7kyQSG0EunVmcg9H6074LeiAn0MAwNbwoH5AIPj1geOxV0pazQCO/G76R6XWERY965 bqzsOzdUnHubC/FbcfI8JLHzgq6oaQMt3VPr5Ym1cmEOSz8Nq74/mAj2WCR/opUy49ui kU7D9yD66+ytq5cuPmeL5IhHgeeXVypzOkL7KQcAitjL/1bNrawgFKM4rZ0j2PhVU/w9 687LwPBTuw3DV285wo8+707XtpJcYR5E3dVEIs4WBYh1rwM7gnlO0KlQk+Eqd0P1s59o mNaM3iKza4LwJLC0vE0JyIzo+6eDybvzVonStR4brcOAZA8cAeQs3m23/Ljfd7JRx11E Pw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2k269j9ekf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 06 Jul 2018 22:41:36 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w66LYqgS006220; Fri, 6 Jul 2018 17:41:34 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2jx56vhwkt-1; Fri, 06 Jul 2018 17:41:34 -0400 Received: from bos-mpeve.kendall.corp.akamai.com (unknown [172.19.33.76]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A8D231FC0E; Fri, 6 Jul 2018 21:41:34 +0000 (GMT) From: Brian Sniffen To: Eric Rescorla Cc: "\" In-Reply-To: References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> Date: Fri, 06 Jul 2018 17:41:34 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060241 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807060242 Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2018 21:41:47 -0000 Eric Rescorla writes: > On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian wrot= e: > >> Looks neat. >> >> 1) TFO DOS vector: is the idea servers will disable TFO under strain but >> not be able to disable ESNI? >> > > I hadn't thought about it, but that seems right. I'm not really seeing why > this is a DOS vector? At present, if you're able to pass a routability > test, you can force a server to do a DH exchange and a signature, so > forcing them to do ESNI decryption doesn't seem like it's that much of an > amplification. This is the same worry I had talking about ESNI the first time: if experiencing a lot of load, a server operator might like to route the load-generating customers / apps / users to a different set of servers. To do that, he needs to know which customers / apps / users are inviting the load. Is this a flash crowd to exampleA.com or exampleB.com? Having to do crypto to determine that makes it *much* more expensive. It rules out a bunch of ways of doing it on a separate device that doesn't have the decryption key. I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor, Prolexic) and not give them the real TLS keys? That takes away the routability test---they just test a sample of what's on the wire, but that's probably okay. >> 2) =E2=80=9Cclients might opt to attempt captive portal detection to see= if they >> are in the presence of a MITM proxy, and if so disable ESNI.=E2=80=9D >> >> If I=E2=80=99m operating a great firewall, I can use this to discover di= ssidents, >> right? Either they send me dangerous SNI values or they are configured = to >> not disable ESNI, and taking the fifth is fatal. To protect them, I think >> nobody can have this mode. >> > > This doesn't sound right to me. The idea here is that you only disable ES= NI > if the attacker is able to generate a valid TLS connection to a > *non-default* root, which means that they are MITM-capable, which nation > state firewall operators typically are not. And of course if they are, th= en > you have real problems. Can you walk me through the flow you have in mind. My nation-state operator adversaries typically are MITM-capable. Hunh. And yes, I have real problems! Lucky me. But to generalize: even if it can't be done at the GFWoC, it's still dangerous if done a cafe at a time. >> 3) How many bits does this offer? Hiding in a set of a million uniform >> hosts is 20 bits, > > > Well, I would say it's got an anonymity set of 2^{20}. It's not 20 bits > strong in the sense that the attacker can do a computation of cost 2^{20}= .n > > > and the nonuniformity will accrue to the adversary=E2=80=99s benefit. Act= ive >> probing will unmask visitors to dissident sites. >> > > I don't really follow this. Can you explain? I think it's at most 20 bits strong: the attacker can do a computation of cost 2^{20}, and crack the anonymity. It involves 2^{20} cafe-at-a-time compromises, or 2^{20} operations involving rubber hoses. But I think it's a *lot* weaker than 2^{20}: the needles of the adversary's search are not uniformly distributed. So he can block the most popular site for a day. That doesn't take off 1 bit; that takes off the vast majority of the clients. If sites are on a power-law distribution, it gets down to where the remaining 2^5 are rubber-hosable in just a few experiments. -Brian > -Ekr > > > > I worry that this tool is so weak against a GFW-style adversary for the >> purpose of allowing dissident access to restricted web sites that it will >> be dangerous if released. But maybe I misunderstand the purpose. If this= is >> just to keep Western ISPs from monkeying with traffic, sure, ship it. >> Labelling the encryption with its strength as applied, or showing CDNs a= nd >> ISPs how to work out some bounds, seems one way to help users understand >> whether this can help them or put them more at risk. >> >> -- >> Brian Sniffen >> >> --=20 Brian Sniffen Akamai Technologies From nobody Fri Jul 6 14:52:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3691130FF4 for ; Fri, 6 Jul 2018 14:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.092 X-Spam-Level: *** X-Spam-Status: No, score=3.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ROLEX=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_OP4smHfLXD for ; Fri, 6 Jul 2018 14:52:28 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D761C131017 for ; Fri, 6 Jul 2018 14:52:27 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id y203-v6so4678626ywd.9 for ; Fri, 06 Jul 2018 14:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VpguPu6qFZX7Op0mTSpnoaEzfzipwV+nqgyEil+hcrk=; b=xBPmn46Wui/3Uau6lIDwo7IY1VTcTOKXEtULXj1DeLpCjyZA0FyuHcecSQunnF9mMX gAbrCWS8q+dwLqbABB584OFuo8jtroW8h2nya4Bt1JrPs4Qy8QYqx3DUq622P/SidcXT yL87RDmZSEGyrlpE+o77cxhwexA1gcyuTtmDtLsVRYCX5siTPJlCmZwlneyn87Qbyl1m F95TpVD5fD7V6FaVKPgv5z9WKVFCpi17mEjclYRoqFZC3uu7tuV5emrAqMeHDtANmo/+ z61Eh1jlp9h2vrCDUkC4DxVQz09FSSqZF3WX1AQ4/74ighT/r3yxL9h4PHzbK9hFkuEz 386w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VpguPu6qFZX7Op0mTSpnoaEzfzipwV+nqgyEil+hcrk=; b=IbDVe6w+LqBL7kKBmZc8uOV/uOcF7kyXRC0v/D3JBhjzNKOzpw3QHg5bb0eBqr5ilk OZHwdZ5UMm9N46WTMps2Bi+vy/UI2t1XxeEICS3LmVyu0mopMB8bIhx9qoX6Y5DFVEOY +tyH8Pt8JjJfva0xpJ/QHvsafiA8CmLiwyFz0yFvdynbuS4VWP2EwZYhIFiM9zk/u6En 48y3oAI8nKx0f5sQj/CDvnUbjPw0PbwAgSvvTyP7AzfoKTkE9x0F+8MeVu207NswrSPO syxYkJ9V9BZgZAlXBwVSdUGTmA8HLkNXrqfUPdf6fZGB6VMNCSMKov55OGs0Bav4ROIY mxoQ== X-Gm-Message-State: APt69E1HG9uP+aP5b37aZP/DfM6r30pMlYaHRo5Wst5V2qNl49R2cLm8 OJ/RjofmFqwc6QVoEL9PpVkphnc5XDtwc3dgnUGwqg== X-Google-Smtp-Source: AAOMgpdoYiH6cunWkZ1FjBVqImjVBfRcKOXFtqz+dEDSNEzqtZakh74aYKCJ/c+wzTZw21j+jGfD2lsZg2LDp9pllZQ= X-Received: by 2002:a81:918b:: with SMTP id i133-v6mr5931515ywg.175.1530913946994; Fri, 06 Jul 2018 14:52:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 14:51:46 -0700 (PDT) In-Reply-To: References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 14:51:46 -0700 Message-ID: To: Brian Sniffen Cc: "" Content-Type: multipart/alternative; boundary="000000000000fe27a705705bada4" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 06 Jul 2018 21:52:30 -0000 --000000000000fe27a705705bada4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2018 at 2:41 PM, Brian Sniffen wrote: > Eric Rescorla writes: > > > On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian > wrote: > > > >> Looks neat. > >> > >> 1) TFO DOS vector: is the idea servers will disable TFO under strain b= ut > >> not be able to disable ESNI? > >> > > > > I hadn't thought about it, but that seems right. I'm not really seeing > why > > this is a DOS vector? At present, if you're able to pass a routability > > test, you can force a server to do a DH exchange and a signature, so > > forcing them to do ESNI decryption doesn't seem like it's that much of = an > > amplification. > > This is the same worry I had talking about ESNI the first time: if > experiencing a lot of load, a server operator might like to route the > load-generating customers / apps / users to a different set of servers. > To do that, he needs to know which customers / apps / users are inviting > the load. Is this a flash crowd to exampleA.com or exampleB.com? > Having to do crypto to determine that makes it *much* more expensive. > It rules out a bunch of ways of doing it on a separate device that > doesn't have the decryption key. > Well, the glib answer is "nobody is making you do ESNI". More concretely, there are plenty of people who have to deal with DoS who don't have the luxury of segmenting traffic by SNI (e.g., Google), so I'm unpersuaded that this is a necessary part of DoS defense. > I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor, > Prolexic) and not give them the real TLS keys? Yes, the system is specifically designed to allow this. >> 2) =E2=80=9Cclients might opt to attempt captive portal detection to see= if they > >> are in the presence of a MITM proxy, and if so disable ESNI.=E2=80=9D > >> > >> If I=E2=80=99m operating a great firewall, I can use this to discover > dissidents, > >> right? Either they send me dangerous SNI values or they are configure= d > to > >> not disable ESNI, and taking the fifth is fatal. To protect them, I > think > >> nobody can have this mode. > >> > > > > This doesn't sound right to me. The idea here is that you only disable > ESNI > > if the attacker is able to generate a valid TLS connection to a > > *non-default* root, which means that they are MITM-capable, which natio= n > > state firewall operators typically are not. And of course if they are, > then > > you have real problems. Can you walk me through the flow you have in > mind. > > My nation-state operator adversaries typically are MITM-capable. Hunh. > And yes, I have real problems! Lucky me. > I don't think anything can protect you from attackers who have a trust anchor on your machine. That's contrary to the whole TLS threat model. > But to generalize: even if it can't be done at the GFWoC, it's still > dangerous if done a cafe at a time. > Cafes do not generally have trust anchors on your machine. > >> 3) How many bits does this offer? Hiding in a set of a million uniform > >> hosts is 20 bits, > > > > > > Well, I would say it's got an anonymity set of 2^{20}. It's not 20 bits > > strong in the sense that the attacker can do a computation of cost > 2^{20}.n > > > > > > and the nonuniformity will accrue to the adversary=E2=80=99s benefit. A= ctive > >> probing will unmask visitors to dissident sites. > >> > > > > I don't really follow this. Can you explain? > > I think it's at most 20 bits strong: the attacker can do a computation > of cost 2^{20}, and crack the anonymity. It involves 2^{20} > cafe-at-a-time compromises, or 2^{20} operations involving rubber hoses. > I'm sorry, I'm not following you. Can you please describe the precise form of attack you have in mind. > But I think it's a *lot* weaker than 2^{20}: the needles of the > adversary's search are not uniformly distributed. So he can block the > most popular site for a day. That doesn't take off 1 bit; that takes > off the vast majority of the clients. If sites are on a power-law > distribution, it gets down to where the remaining 2^5 are rubber-hosable > in just a few experiments > I don't follow this either. At this point it would perhaps be helpful if yo= u drew a diagram or described the attack in a lot more detail. -Ekr > -Brian > > > -Ekr > > > > > > > > I worry that this tool is so weak against a GFW-style adversary for the > >> purpose of allowing dissident access to restricted web sites that it > will > >> be dangerous if released. But maybe I misunderstand the purpose. If > this is > >> just to keep Western ISPs from monkeying with traffic, sure, ship it. > >> Labelling the encryption with its strength as applied, or showing CDNs > and > >> ISPs how to work out some bounds, seems one way to help users understa= nd > >> whether this can help them or put them more at risk. > >> > >> -- > >> Brian Sniffen > >> > >> > > -- > Brian Sniffen > Akamai Technologies > --000000000000fe27a705705bada4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 6, 2018 at 2:41 PM, Brian Sniffen <bsniffen@akamai.com> wrote:
Eric Rescorla = <ekr@rtfm.com> = writes:

> On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian <bsniffen@akamai.com> wrote: >
>> Looks neat.
>>
>> 1) TFO DOS vector: is the idea servers will disable TFO under stra= in but
>> not be able to disable ESNI?
>>
>
> I hadn't thought about it, but that seems right. I'm not reall= y seeing why
> this is a DOS vector? At present, if you're able to pass a routabi= lity
> test, you can force a server to do a DH exchange and a signature, so > forcing them to do ESNI decryption doesn't seem like it's that= much of an
> amplification.

This is the same worry I had talking about ESNI the first time: if experiencing a lot of load, a server operator might like to route the
load-generating customers / apps / users to a different set of servers.
To do that, he needs to know which customers / apps / users are inviting the load.=C2=A0 Is this a flash crowd to exampleA.com or exampleB.com?
Having to do crypto to determine that makes it *much* more expensive.
It rules out a bunch of ways of doing it on a separate device that
doesn't have the decryption key.

We= ll, the glib answer is "nobody is making you do ESNI". More concr= etely,
there are plenty of people who have to deal with DoS who d= on't have
the luxury of segmenting traffic by SNI (e.g., Goog= le), so I'm unpersuaded
that this is a necessary part of DoS = defense.

=C2=A0
I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor,
Prolexic) and not give them the real TLS keys?=C2=A0

<= /div>
Yes, the system is specifically designed to allow this.




>> 2) =E2=80=9Cclients might opt to attempt captive portal detection = to see if they
>> are in the presence of a MITM proxy, and if so disable ESNI.=E2=80= =9D
>>
>> If I=E2=80=99m operating a great firewall, I can use this to disco= ver dissidents,
>> right?=C2=A0 Either they send me dangerous SNI values or they are = configured to
>> not disable ESNI, and taking the fifth is fatal. To protect them, = I think
>> nobody can have this mode.
>>
>
> This doesn't sound right to me. The idea here is that you only dis= able ESNI
> if the attacker is able to generate a valid TLS connection to a
> *non-default* root, which means that they are MITM-capable, which nati= on
> state firewall operators typically are not. And of course if they are,= then
> you have real problems. Can you walk me through the flow you have in m= ind.

My nation-state operator adversaries typically are MITM-capable.=C2= =A0 Hunh.
And yes, I have real problems!=C2=A0 Lucky me.

I don't think anything can protect you from attackers who have = a trust anchor
on your machine. That's contrary to the whole = TLS threat model.

=C2=A0
But to generalize: even if it can't be done at the GFWoC, it's stil= l
dangerous if done a cafe at a time.

Caf= es do not generally have trust anchors on your machine.


>> 3) How many bits does this offer? Hiding in a set of a million uni= form
>> hosts is 20 bits,
>
>
> Well, I would say it's got an anonymity set of 2^{20}. It's no= t 20 bits
> strong in the sense that the attacker can do a computation of cost 2^{= 20}.n
>
>
> and the nonuniformity will accrue to the adversary=E2=80=99s benefit. = Active
>> probing will unmask visitors to dissident sites.
>>
>
> I don't really follow this. Can you explain?

I think it's at most 20 bits strong: the attacker can do a compu= tation
of cost 2^{20}, and crack the anonymity. It involves 2^{20}
cafe-at-a-time compromises, or 2^{20} operations involving rubber hoses.

I'm sorry, I'm not following you.= Can you please describe the precise
form of attack you have in m= ind.

=C2=A0
But I think it's a *lot* weaker than 2^{20}: the needles of the
adversary's search are not uniformly distributed.=C2=A0 So he can block= the
most popular site for a day.=C2=A0 That doesn't take off 1 bit; that ta= kes
off the vast majority of the clients.=C2=A0 If sites are on a power-law
distribution, it gets down to where the remaining 2^5 are rubber-hosable in just a few experiments

I don't f= ollow this either. At this point it would perhaps be helpful if you
drew a diagram or described the attack in a lot more detail.

-Ekr


-Brian

> -Ekr
>
>
>
> I worry that this tool is so weak against a GFW-style adversary for th= e
>> purpose of allowing dissident access to restricted web sites that = it will
>> be dangerous if released. But maybe I misunderstand the purpose. I= f this is
>> just to keep Western ISPs from monkeying with traffic, sure, ship = it.
>> Labelling the encryption with its strength as applied, or showing = CDNs and
>> ISPs how to work out some bounds, seems one way to help users unde= rstand
>> whether this can help them or put them more at risk.
>>
>> --
>> Brian Sniffen
>>
>>

--
Brian Sniffen
Akamai Technologies

--000000000000fe27a705705bada4-- From nobody Fri Jul 6 17:30:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F985130E54 for ; Fri, 6 Jul 2018 17:30:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MJOKtBsVhxEO for ; Fri, 6 Jul 2018 17:30:26 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F1B130E13 for ; Fri, 6 Jul 2018 17:30:25 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 41Msv34P20zyPH; Sat, 7 Jul 2018 02:30:23 +0200 (CEST) X-purgate-ID: 152705::1530923423-000007FB-22CCF857/0/0 X-purgate-size: 3690 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 41Msv20pl2zGqwh; Sat, 7 Jul 2018 02:30:22 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 09C72409B; Sat, 7 Jul 2018 02:30:22 +0200 (CEST) In-Reply-To: <1530756330644.68072@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <1530690320155.99154@cs.auckland.ac.nz> <1673271.m6b9jqBoj9@pintsize.usersys.redhat.com> <20180704122407.GA10998@roeckx.be> <1530756330644.68072@cs.auckland.ac.nz> To: Peter Gutmann Date: Sat, 7 Jul 2018 02:30:21 +0200 (CEST) CC: Kurt Roeckx , Hubert Kario , "tls@ietf.org" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20180707003022.09C72409B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2018 00:30:29 -0000 Peter Gutmann wrote: > > (I have no idea about the prevalence of IE vs. others, but since it's the > default browser for Windows I assume this will be the easiest/recommended path > fowards, and until Windows 10 MS had a long history of being excruciatingly > careful about backwards compatibility so it seems the safest bet). The last time that I've seen a Microsoft Windows TLS implementation show a reasonble level of interoperability was Windows2003sp2 with Hotfix 948963 installed. Windows 2008R2 has sever interop problems with TLSv1.2, and goofed the RSA premaster secret version check. https://www.ietf.org/mail-archive/web/tls/current/msg08139.html Windows2012R2 made things worse, same TLSv1.2 interop failures, plus default lack of backwards compatibility to non-SNI clients. I was surprised when I just recently saw responses from Windows 2016 Microsoft IIS/10.0 = presumably Windows 2016 Microsoft IIS/8.5 = Windows 2012R2 Microsoft IIS/7.5 = Windows 2008R2 While 2016 seems to have fixed two annoying TLSv1.2 interop failures that affect 2008R2 and 2012R2 (about the TLSv1.2 signature_algorithms extension), Win2016 also newly added two _new_ handshake failures (compared to 2008R2) Comparing Win2016 behaviour for SSLv2Hello vs. extension-less SSLv3 Hello the new behaviour is just crazy: the server requires TLS extension SNI for SSLv3 ClientHellos with client_version=(3,1) and (3,2), but *NOT* for client_version=(3,3) and *NOT* for SSLv2Hellos (any version)! I would expect that someone who cares about backwards compatibility would test stuff at least once before shipping. Windows 2008R2 and later looks like entirely untested to me or maybe "tested only with MSIE and only in default config" -- which is equivalent to "untested" on my scorecard. Windows 2008R2 in default config had TLSv1.2 disabled, and no one seem to have thought of testing with a sha256WithRsaEncryption signed server certificate. -Martin All cells marked with ** are SChannel Bugs. 2003 2008R2 2012R2 2016 -------------------------------------------------------------------- SSLv2Hello offering (3,1) TLSv1.0 TLSv1.0 **FAIL TLSv1.0 SSLv2Hello offering (3,2) TLSv1.0 TLSV1.1 **FAIL TLSv1.1 SSLv2Hello offering (3,3) TLSv1.0 **TLSv1.1 **FAIL **TLSv1.1 ClientHello (no extensions) TLSv1.0 TLSv1.0 **FAIL **FAIL client_version=(3,1) ClientHello (SNI) TLSv1.0 TLSv1.0 TLSv1.0 TLSv1.0 client_version=(3,1) ClientHello (no extensions) TLSv1.0 TLSv1.1 **FAIL **FAIL client_version=(3,2) ClientHello (SNI) TLSv1.0 TLSv1.1 TLSv1.1 TLSv1.1 client_version=(3,2) ClientHello (no extensions) TLSv1.0 **FAIL **FAIL TLSv1.2 client_version(3,3) ClientHello (SNI) TLSv1.0 **FAIL **FAIL TLSv1.2 client_version(3,3) ClientHello (SNI+sig_algs) client_version(3,3) TLSv1.0 TLSv1.2 TLSv1.2 TLSv1.2 The strange SChannel behaviour for SSLv2Hello offering (3,3) affects MSIE 11 Win 7/2008R2 (and probably Win8/8.1/2012/2012R2 as well). When "SSL Version 2" is enabled in "Internet Options" together with TLSv1.2 then interop with an TLSv1.2-enabled Microsoft IIS (SChannel) is still possible, because of the server-side bug to negotiate only TLSv1.1. But when MSIE offers TLSv1.2 in SSLv2Hello to a server with a correct TLS implementation, and that server responds with protocol version TLSv1.2, then MSIE chokes and dies. https://support.microsoft.com/en-us/kb/2851628 From nobody Fri Jul 6 18:35:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83B67130DE0 for ; Fri, 6 Jul 2018 18:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1ubMq-iIDl5 for ; Fri, 6 Jul 2018 18:35:01 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 240BC130DDB for ; Fri, 6 Jul 2018 18:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1530927301; x=1562463301; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/IBtecWXCWMy/VfTgWuDaxYY/YhvsyVFduCmoASpV8c=; b=P/5+CTTacd2DFV39mTJDj55SsJHc1CIXbUyAOS2oY9ahNcvWF0Lsh0s1 HgrkRsKDbzQHcHANuE0rCJY20IzR7MjWLe13rp5IAhT8HnmGM41R1zHJE KqlSVRZQHxaZbuZXjQETV5Q2ZGe+ovVbZPCVw9/3rGioFAJY/68myxM8d 9JGfIpvwRa0xWJFVWGa5Ic39JE7hpBfU9OiNCHyaVMzXOkpvBBhY/Gne7 BDywaUGQr/dzyWyssxTfQgJCRUj4chcZFEkxL4lVyWBmHObdfs5TGWsaQ uuSv/0AZ6Xx1OPR5W8DKu94rDNMcJlyUpMTY++IQaw2eb51FNegbly3TN w==; X-IronPort-AV: E=Sophos;i="5.51,318,1526299200"; d="scan'208";a="20010470" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from uxcn13-tdc-b.uoa.auckland.ac.nz ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 07 Jul 2018 13:34:54 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Sat, 7 Jul 2018 13:34:53 +1200 Received: from uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8]) by uxcn13-tdc-d.UoA.auckland.ac.nz ([fe80::ccab:7bf5:3d4a:aed8%14]) with mapi id 15.00.1263.000; Sat, 7 Jul 2018 13:34:53 +1200 From: Peter Gutmann To: "mrex@sap.com" CC: Kurt Roeckx , Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgADQEJ///2EpAIAAJ+eAgAGuV0eAAkE7gIAA2umH Date: Sat, 7 Jul 2018 01:34:52 +0000 Message-ID: <1530927270479.40817@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <1530690320155.99154@cs.auckland.ac.nz> <1673271.m6b9jqBoj9@pintsize.usersys.redhat.com> <20180704122407.GA10998@roeckx.be> <1530756330644.68072@cs.auckland.ac.nz>, <20180707003022.09C72409B@ld9781.wdf.sap.corp> In-Reply-To: <20180707003022.09C72409B@ld9781.wdf.sap.corp> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2018 01:35:04 -0000 Martin Rex writes:=0A= =0A= >I would expect that someone who cares about backwards compatibility would= =0A= >test stuff at least once before shipping.=0A= =0A= It's not just their TLS code that does things like this. The Server 2003 S= CEP=0A= implementation, when sent a standard SCEP GetCACaps message, would immediat= ely=0A= drop the connection (which at least let you know what server you were talki= ng=0A= to, so it was a sort-of GetCACaps at least). The Server 2012 SCEP=0A= implementation will respond to a PKCS #1-wrapped (as per the spec) AES-=0A= encrypted SCEP client request with an OAEP-wrapped (completely incorrect)= =0A= single-DES-encrypted response.=0A= =0A= I cannot even begin to imagine what sort of coding would produce that level= of=0A= breakage. This must have been tested on exactly zero implementations befor= e=0A= it shipped.=0A= =0A= >Windows 2008R2 and later looks like entirely untested to me or maybe "test= ed=0A= >only with MSIE and only in default config"=0A= =0A= For SCADA stuff it's only the client side that matters (browsers being used= to=0A= admin devices), so I haven't looked at server-side breakage that much. Eve= n=0A= then, note the comments in my first message about the bizarro fallback danc= e +=0A= eventual fail to connect that IE goes through.=0A= =0A= In any case thanks for posting that list, it's good to have for reference. = I=0A= suspect at least some of that behaviour may be due to the destructive=0A= interaction of too many backwards-compatibility hacks...=0A= =0A= Peter.=0A= From nobody Fri Jul 6 19:17:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B74130E13 for ; Fri, 6 Jul 2018 19:17:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.721 X-Spam-Level: X-Spam-Status: No, score=-0.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y0KNr4-GVrr1 for ; Fri, 6 Jul 2018 19:17:54 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 78D98130E20 for ; Fri, 6 Jul 2018 19:17:53 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w672HprI020741; Sat, 7 Jul 2018 03:17:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=gu5YSVj9PFlTKgMLejeseT+IwKiD18ZI7lDQI1sE+rA=; b=VdYHHeKlD0uQXVQOErglcPvYYzrNRVfBBItWiuSgZlqDXdY9yGZ0zh+iM+djT+gPhV1O d1dOiQ6UZxnFWQf3gy1pH8kb3DQ10tUlCpeSLXcYq4puE77uKp6hbQDNgz1YkILwHYwK kusgv79UuDAlk0tyHPsWppZ4zX4nhh+Q25sApJxQvDJVMoeNhNi4tyCxOd7SYOgMk/+H J1xeY3ObyjgTHWnyHEUOABUmT7RGGC0rKH2IfADVR91PXESL6Oe4QZWtejLdoR/lA6r/ VHMfO/XNKyo+oLbG4/zVBJPin/6rDGpkG6yValW5tyqni052scMWMRXk8f0PNL1smbga ag== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2k1ucn3myk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 07 Jul 2018 03:17:51 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6724c0s002374; Fri, 6 Jul 2018 22:17:50 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2jx57b30nn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 06 Jul 2018 22:17:49 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 6 Jul 2018 19:17:48 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Fri, 6 Jul 2018 21:17:48 -0500 From: "Short, Todd" To: Eric Rescorla CC: "" , "Sniffen, Brian" Thread-Topic: [TLS] DNS-based Encrypted SNI Thread-Index: AQHUEl5BbRY0wnPzbU+tvvqDIqSVJKR94qgAgAUS64CAAA06gIAACdxX Date: Sat, 7 Jul 2018 02:17:48 +0000 Message-ID: References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@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 Content-Type: multipart/alternative; boundary="_000_AE0160F7659347F7BB01261EA8F389CBakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807070022 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-06_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807070025 Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2018 02:17:58 -0000 --_000_AE0160F7659347F7BB01261EA8F389CBakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQooUGFyZG9uIHBob25lIHR5cG9zIGJlbG93LikNCi0tDQotVG9kZCBTaG9ydA0KLy8gU2VudCBm cm9tIG15IGlQaG9uZQ0KLy8gIk9uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJlZSBp ZiBieSB0aGUgSW50ZXJuZXQuIg0KDQoNCk9uIEp1bCA2LCAyMDE4LCBhdCA0OjQzIFBNLCBFcmlj IFJlc2NvcmxhIDxla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KDQoN Cg0KT24gRnJpLCBKdWwgNiwgMjAxOCBhdCAxMjo1NSBQTSwgU2hvcnQsIFRvZGQgPHRzaG9ydEBh a2FtYWkuY29tPG1haWx0bzp0c2hvcnRAYWthbWFpLmNvbT4+IHdyb3RlOg0KRnVuZGFtZW50YWxs eSwgdW5sZXNzIHRoaXMgdHlwZSBvZiBwcm90ZWN0aW9uIGlzIGJha2VkIGludG8gdGhlIHByb3Rv Y29sIGZyb20gdGhlIGJlZ2lubmluZywgYW5kIGlzIG5vdCBhbiBhZGQtb24gb3B0aW9uLCBhbnkg b25lL3RoaW5nIGluIHRoZSBwYXRoIGNhbiBwcmV2ZW50IHRoZSB1c2Ugb2Ygb3B0aW9uYWwgc2Vj dXJpdHkgZmVhdHVyZXMuDQoNCkRvbuKAmXQgd2FudCBwZW9wbGUgdG8gYWNjZXNzIHNpdGUgWFla PyBCbG9jayBETlNTRUMsIGJsb2NrIF9FU05JIEROUyByZXF1ZXN0cy9yZXNwb25zZXMsIGJsb2Nr IHRoZSB1c2Ugb2YgRVNOSSwgZXRjLg0KDQpUaGVzZSBhcmUgc29ydCBvZiBkaWZmZXJlbnQgdGhp bmdzLiBJdCdzIHRydWUgdGhhdCBpZiB5b3UgY29udHJvbCBETlMsIGl0J3MgYmFzaWNhbGx5IGdh bWUgb3Zlciwgd2hpY2ggaXMgd2h5IHRoaXMgaXMgbW9zdCBhdHRyYWN0aXZlIHdpdGggRE9IIHRv IHNvbWUgbG9jYXRpb24gbm90IGNvbnRyb2xsZWQgYnkgdGhlIGNlbnNvci4gSG93ZXZlciwgaWYg eW91ICpkbyogaGF2ZSBET0gsIHRoZW4gdGhlIGNsaWVudCBzaG91bGRuJ3QgZmFsbCBiYWNrLCB3 aXRoIHRoZSByZXN1bHQgdGhhdCBibG9ja2luZyBFU05JIGJsb2NrcyBhbGwgRVNOSS1lbmFibGVk IHNpdGVzLCBub3QganVzdCB0aG9zZSB3aGljaCBhcmUgc2Vuc2l0aXZlDQoNCldoaWNoIG1ha2Vz IHRoaXMgbWVjaGFuaXNtIHBvdGVudGlhbGx5IHVzZWxlc3MuIElmIGl0IHdhcyBtYW5kYXRvcnkg aW4gVExTdjEuMywgdGhlbiB0cnlpbmcgdG8gYmxvY2sgZW5jcnlwdGVkIFNOSSB3b3VsZCBiZSBi cmVhayBhIGxvdCBtb3JlIHNpdGVzLCBhbmQgbWlnaHQgaGF2ZSB0byBiZSBhbGxvd2VkLg0KDQoN Cg0KQSBmaXJld2FsbCBjYW4gYWxzbyB1c2UgdGhlIHJlY29yZF9kaWdlc3QgdG8gZGV0ZXJtaW5l IHRoZSBkZXN0aW5hdGlvbiwgd2l0aG91dCBldmVuIGRlY3J5cHRpbmcgdGhlIEVTTkkuIEl0IGp1 c3QgY2FsY3VsYXRlcyB0aGUgcG9zc2libGUgcmVjb3JkX2RpZ2VzdHMgb2YgdGhlIGJsb2NrZWQg c2l0ZXM7IHNpbmNlIHRoZSBpbmZvcm1hdGlvbiBpcyBwdWJsaWMuIFRoaXMgd2lsbCBtYWtlIGl0 IGFwcGVhciB0aGF0IEVTTkkgaXMgc3VwcG9ydGVkIChmb3IgbGVnYWwgc2l0ZXMpLCBidXQgc3Rp bGwgYmxvY2sgdGhlIHVzZSB0byBpbGxlZ2FsIHNpdGVzLg0KDQpPciBldmVuIGRvIGEgcmV2ZXJz ZS1ETlMgbG9va3VwIG9uIHRoZSBkZXN0aW5hdGlvbiBJUCwgZGlzY292ZXIgYWxsIHRoZSBkb21h aW5zIHRoZXJlLCBhbmQgdGhlbiBjYWxjdWxhdGUgdGhlIHBvc3NpYmxlIHJlY29yZF9kaWdlc3Rz IHRvIHNlZSB3aGVyZSB0aGUgdXNlciBpcyBnb2luZy4NCg0KVGhpcyBjb3VsZCBiZSBtaXRpZ2F0 ZWQgYnkgaGF2aW5nIHRoZSBzYW1lIEVTTklLZXlzIGZvciBkaWZmZXJlbnQgd2Vic2l0ZXMsIGJ1 dCB0aGF0IG1lYW5zIHRoZSAiU3BsaXQgTW9kZSBUb3BvbG9neSIgaXMgYnJva2VuIGFzIHRoZSBy ZWNvcmRfZGlnZXN0IGNhbm5vdCBiZSB1c2VkIGJ5IHRoZSBDbGllbnQtRmFjaW5nIFNlcnZlciB0 byBzZWxlY3QgYSBCYWNrZW5kIFNlcnZlci4NCg0KSSB0aGluayB5b3UgbWF5IGJlIG1pc3VuZGVy c3RhbmRpbmcgdGhlIGRlc2lnbiBoZXJlLiBBbGwgb2YgdGhlIEVTTkktZW5hYmxlZCBzaXRlcyBi ZWhpbmQgdGhlIHNhbWUgY2xpZW50LWZhY2luZyBzZXJ2ZXIgKHNwbGl0IG1vZGUgb3Igbm90KSB1 c2UgdGhlIHNhbWUga2V5cywgYW5kIGhlbmNlIGhhdmUgdGhlIHNhbWUgcmVjb3JkX2RpZ2VzdC4g VGh1cywgcmVjb3JkX2RpZ2VzdCBpcyBqdXN0IGFuIGFsaWFzIGZvciBhbm9ueW1pdHkgc2V0LiBU aGUgY2xpZW50LWZhY2luZyBzZXJ2ZXIgZG9lcyBub3QgdXNlIHRoZSByZWNvcmRfZGlnZXN0IHRv IHNlbGVjdCB0aGUgYmFja2VuZCBzZXJ2ZXIuIEl0IHVzZXMgdGhlIHJlY29yZF9kaWdlc3QgdG8g ZmluZCB3aGljaCBvZiB0aGUga2V5cyBpdCBoYXMgb2ZmZXJlZCBhbmQgdGhlbiB1c2VzIHRoYXQg a2V5IHRvIGRlY3J5cHQgdGhlIHRydWUgU05JLiBOb3RlIHRoYXQgaW4gc29tZSBuYWl2ZSBzZW5z ZSB5b3UgZG9uJ3QgbmVlZCBhIHJlY29yZF9kaWdlc3QgYXQgYWxsLiBJdCdzIGp1c3QgdGhlcmUg dG8gZmFjaWxpdGF0ZSB0aGUgY2xpZW50LWZhY2luZyBzZXJ2ZXIgaGF2aW5nIG11bHRpcGxlIHZh bGlkIEVTTkkga2V5IHNldHMgKGUuZy4sIGZvciByb2xsb3ZlcikgYXQgb25lIHRpbWUuDQoNCkl0 J3MgaW1wbGllZCB0aGF0IHJlY29yZF9kaWdlc3QgaXMvY2FuIGJlIHVzZWQgdG8gc2VsZWN0IHRo ZSAib3JpZ2luIHNlcnZlciIuIElmIG5vdCwgdGhlbiB0aGUgd29yZGluZyBzaG91bGQgYmUgY2xh cmlmaWVkLg0KDQpBZ2FpbiwgYmVjYXVzZSB0aGlzIGlzIG9wdGlvbmFsLCB0aGUgKGluaXRpYWwp IHNldCBvZiBzZXJ2ZXJzIHRoYXQgdXNlIEVTTkkgd2lsbCBiZSBzbWFsbCwgYW5kIGNhbiBiZSBy ZWFzb25hYmx5IGRldGVybWluZWQuIFRoZSBhbm9ueW1pdHkgc2V0LCBhdCB0aGUgbGVhc3QsIGNh biBiZSByZWR1Y2VkIGJ5IGRlc3RpbmF0aW9uIGFkZHJlc3MgdmlhIHJldmVyc2UtRE5TLiBDRE5z IHdpbGwgcmVzb2x2ZSBkb21haW5zIHRvIGRpZmZlcmVudCBJUHMgKG9uIHZhcmlvdXMgbWV0cmlj cykgd2hpY2ggY291bGQgbGVhayBpbmZvcm1hdGlvbiB0byBoZWxwIG5hcnJvdyBkb3duIHRoZSBh Y3R1YWwgZG9tYWluLiBTbywgaXQgc3RpbGwgY2FuIGV4cG9zZSBhIHNldCBvZiBwb3NzaWJsZSBk ZXN0aW5hdGlvbiBkb21haW5zIHRoYXQgdGhlIHVzZXIgaXMgYXR0ZW1wdGluZyB0byByZWFjaC4N Cg0KTXkgZmVhciBpcyB0aGF0IHRoZXJlJ3MgZW5vdWdoIHBvdGVudGlhbCBsZWFrYWdlIHRoYXQg c29tZXRoaW5nIHNob3VsZCBiZSBtZW50aW9uZWQgaW4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMu DQoNCg0KDQpBaCwgYnV0IGlmIHRoZSBDRE4gbWFwcyB0aGUgc2hhcmVkLUVTTklLZXlzIGRvbWFp bnMgdG8gYmUgZGlmZmVyZW50IElQcywgdGhlbiBkb2VzbuKAmXQgbWF0dGVyLiBUaGlzIGlzIG5v dCB0aGUgY2FzZSwgYXMgdGhlIElQIGFkZHJlc3MgY2FuIG5vdyBiZSB1c2VkIGFsb25nIHdpdGgg dGhlIEVTTklLZXlzIHRvIGtub3cgd2hhdCB0aGUgZmluYWwgZGVzdGluYXRpb24gaXMuDQoNClll cywgeW91IG5lZWQgdG8gdXNlIHRoZSBzYW1lIElQcy4NCg0KLUVrcg0KDQoNCi0tDQotVG9kZCBT aG9ydA0KLy8gdHNob3J0QGFrYW1haS5jb208bWFpbHRvOnRzaG9ydEBha2FtYWkuY29tPg0KLy8g Ik9uZSBpZiBieSBsYW5kLCB0d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQu Ig0KDQpPbiBKdWwgMywgMjAxOCwgYXQgMTA6MjYgQU0sIFNuaWZmZW4sIEJyaWFuIDxic25pZmZl bj00MGFrYW1haS5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRvOmJzbmlmZmVuPTQwYWthbWFpLmNv bUBkbWFyYy5pZXRmLm9yZz4+IHdyb3RlOg0KDQpMb29rcyBuZWF0Lg0KDQoxKSBURk8gRE9TIHZl Y3RvcjogaXMgdGhlIGlkZWEgc2VydmVycyB3aWxsIGRpc2FibGUgVEZPIHVuZGVyIHN0cmFpbiBi dXQgbm90IGJlIGFibGUgdG8gZGlzYWJsZSBFU05JPw0KDQoyKSDigJxjbGllbnRzIG1pZ2h0IG9w dCB0byBhdHRlbXB0IGNhcHRpdmUgcG9ydGFsIGRldGVjdGlvbiB0byBzZWUgaWYgdGhleSBhcmUg aW4gdGhlIHByZXNlbmNlIG9mIGEgTUlUTSBwcm94eSwgYW5kIGlmIHNvIGRpc2FibGUgRVNOSS7i gJ0NCg0KSWYgSeKAmW0gb3BlcmF0aW5nIGEgZ3JlYXQgZmlyZXdhbGwsIEkgY2FuIHVzZSB0aGlz IHRvIGRpc2NvdmVyIGRpc3NpZGVudHMsIHJpZ2h0PyAgRWl0aGVyIHRoZXkgc2VuZCBtZSBkYW5n ZXJvdXMgU05JIHZhbHVlcyBvciB0aGV5IGFyZSBjb25maWd1cmVkIHRvIG5vdCBkaXNhYmxlIEVT TkksIGFuZCB0YWtpbmcgdGhlIGZpZnRoIGlzIGZhdGFsLiBUbyBwcm90ZWN0IHRoZW0sIEkgdGhp bmsgbm9ib2R5IGNhbiBoYXZlIHRoaXMgbW9kZS4NCg0KMykgSG93IG1hbnkgYml0cyBkb2VzIHRo aXMgb2ZmZXI/IEhpZGluZyBpbiBhIHNldCBvZiBhIG1pbGxpb24gdW5pZm9ybSBob3N0cyBpcyAy MCBiaXRzLCBhbmQgdGhlIG5vbnVuaWZvcm1pdHkgd2lsbCBhY2NydWUgdG8gdGhlIGFkdmVyc2Fy eeKAmXMgYmVuZWZpdC4gQWN0aXZlIHByb2Jpbmcgd2lsbCB1bm1hc2sgdmlzaXRvcnMgdG8gZGlz c2lkZW50IHNpdGVzLg0KDQpJIHdvcnJ5IHRoYXQgdGhpcyB0b29sIGlzIHNvIHdlYWsgYWdhaW5z dCBhIEdGVy1zdHlsZSBhZHZlcnNhcnkgZm9yIHRoZSBwdXJwb3NlIG9mIGFsbG93aW5nIGRpc3Np ZGVudCBhY2Nlc3MgdG8gcmVzdHJpY3RlZCB3ZWIgc2l0ZXMgdGhhdCBpdCB3aWxsIGJlIGRhbmdl cm91cyBpZiByZWxlYXNlZC4gQnV0IG1heWJlIEkgbWlzdW5kZXJzdGFuZCB0aGUgcHVycG9zZS4g SWYgdGhpcyBpcyBqdXN0IHRvIGtlZXAgV2VzdGVybiBJU1BzIGZyb20gbW9ua2V5aW5nIHdpdGgg dHJhZmZpYywgc3VyZSwgc2hpcCBpdC4gIExhYmVsbGluZyB0aGUgZW5jcnlwdGlvbiB3aXRoIGl0 cyBzdHJlbmd0aCBhcyBhcHBsaWVkLCBvciBzaG93aW5nIENETnMgYW5kIElTUHMgaG93IHRvIHdv cmsgb3V0IHNvbWUgYm91bmRzLCBzZWVtcyBvbmUgd2F5IHRvIGhlbHAgdXNlcnMgdW5kZXJzdGFu ZCB3aGV0aGVyIHRoaXMgY2FuIGhlbHAgdGhlbSBvciBwdXQgdGhlbSBtb3JlIGF0IHJpc2suDQoN Ci0tDQpCcmlhbiBTbmlmZmVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0Bp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPGh0dHBz Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu b3JnX21haWxtYW5fbGlzdGluZm9fdGxzJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxa ZyZyPVFCRWNRc3FvVURkazFRMjZDemx6TlBQVWtLWVdJaDFMWXNpSEF3bXRSaWsmbT1qTzZGdEd4 SHdJOFY1cmNLTkpKM255V3QzMG51WVJ4RHNNdzRTckRqUXY4JnM9dWdONlNYVGhqWjVvYnF2MlYz VmVkN2lsaGg4bjhnWGRGc09WYWpKOXpSMCZlPT4NCg0KDQo= --_000_AE0160F7659347F7BB01261EA8F389CBakamaicom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 YnI+DQooUGFyZG9uIHBob25lIHR5cG9zIGJlbG93Lik8YnI+DQo8ZGl2IGlkPSJBcHBsZU1haWxT aWduYXR1cmUiPg0KPGRpdj4tLTwvZGl2Pg0KLVRvZGQgU2hvcnQNCjxkaXY+Ly8gU2VudCBmcm9t IG15IGlQaG9uZTxicj4NCjxkaXY+Ly8gJnF1b3Q7T25lIGlmIGJ5IGxhbmQsIHR3byBpZiBieSBz ZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4mcXVvdDs8YnI+DQo8ZGl2Pjxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj48YnI+DQpPbiBKdWwgNiwgMjAxOCwgYXQg NDo0MyBQTSwgRXJpYyBSZXNjb3JsYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVrckBydGZtLmNvbSI+ ZWtyQHJ0Zm0uY29tPC9hPiZndDsgd3JvdGU6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSB0eXBlPSJjaXRlIj4NCjxkaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8ZGl2IGNsYXNzPSJn bWFpbF9leHRyYSI+PGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEZyaSwgSnVsIDYs IDIwMTggYXQgMTI6NTUgUE0sIFNob3J0LCBUb2RkIDxzcGFuIGRpcj0ibHRyIj4NCiZsdDs8YSBo cmVmPSJtYWlsdG86dHNob3J0QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj50c2hvcnRAYWth bWFpLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21h aWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBz b2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3Jk O2xpbmUtYnJlYWs6YWZ0ZXItd2hpdGUtc3BhY2UiPkZ1bmRhbWVudGFsbHksIHVubGVzcyB0aGlz IHR5cGUgb2YgcHJvdGVjdGlvbiBpcyBiYWtlZCBpbnRvIHRoZSBwcm90b2NvbCBmcm9tIHRoZSBi ZWdpbm5pbmcsIGFuZCBpcyBub3QgYW4gYWRkLW9uIG9wdGlvbiwgYW55IG9uZS90aGluZyBpbiB0 aGUgcGF0aCBjYW4gcHJldmVudCB0aGUgdXNlIG9mIG9wdGlvbmFsIHNlY3VyaXR5IGZlYXR1cmVz Lg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+RG9u4oCZdCB3YW50IHBlb3BsZSB0byBhY2Nlc3Mg c2l0ZSBYWVo/IEJsb2NrIEROU1NFQywgYmxvY2sgX0VTTkkgRE5TIHJlcXVlc3RzL3Jlc3BvbnNl cywgYmxvY2sgdGhlIHVzZSBvZiBFU05JLCBldGMuPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZXNlIGFyZSBzb3J0IG9mIGRpZmZlcmVudCB0 aGluZ3MuIEl0J3MgdHJ1ZSB0aGF0IGlmIHlvdSBjb250cm9sIEROUywgaXQncyBiYXNpY2FsbHkg Z2FtZSBvdmVyLCB3aGljaCBpcyB3aHkgdGhpcyBpcyBtb3N0IGF0dHJhY3RpdmUgd2l0aCBET0gg dG8gc29tZSBsb2NhdGlvbiBub3QgY29udHJvbGxlZCBieSB0aGUgY2Vuc29yLiBIb3dldmVyLCBp ZiB5b3UgKmRvKiBoYXZlIERPSCwgdGhlbiB0aGUgY2xpZW50IHNob3VsZG4ndCBmYWxsDQogYmFj aywgd2l0aCB0aGUgcmVzdWx0IHRoYXQgYmxvY2tpbmcgRVNOSSBibG9ja3MgYWxsIEVTTkktZW5h YmxlZCBzaXRlcywgbm90IGp1c3QgdGhvc2Ugd2hpY2ggYXJlIHNlbnNpdGl2ZTxicj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KPGRpdj5XaGljaCBtYWtlcyB0aGlzIG1lY2hhbmlzbSBwb3RlbnRpYWxseSB1 c2VsZXNzLiBJZiBpdCB3YXMgbWFuZGF0b3J5IGluIFRMU3YxLjMsIHRoZW4gdHJ5aW5nIHRvIGJs b2NrIGVuY3J5cHRlZCBTTkkgd291bGQgYmUgYnJlYWsgYSBsb3QgbW9yZSBzaXRlcywgYW5kIG1p Z2h0IGhhdmUgdG8gYmUgYWxsb3dlZC4mbmJzcDs8L2Rpdj4NCjxicj4NCjxibG9ja3F1b3RlIHR5 cGU9ImNpdGUiPg0KPGRpdj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdiBjbGFzcz0iZ21haWxfZXh0 cmEiPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ Jm5ic3A7PC9kaXY+DQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJn aW46MCAwIDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4 Ij4NCjxkaXYgc3R5bGU9IndvcmQtd3JhcDpicmVhay13b3JkO2xpbmUtYnJlYWs6YWZ0ZXItd2hp dGUtc3BhY2UiPg0KPGRpdj5BIGZpcmV3YWxsIGNhbiBhbHNvIHVzZSB0aGUgcmVjb3JkX2RpZ2Vz dCB0byBkZXRlcm1pbmUgdGhlIGRlc3RpbmF0aW9uLCB3aXRob3V0IGV2ZW4gZGVjcnlwdGluZyB0 aGUgRVNOSS4gSXQganVzdCBjYWxjdWxhdGVzIHRoZSBwb3NzaWJsZSByZWNvcmRfZGlnZXN0cyBv ZiB0aGUgYmxvY2tlZCBzaXRlczsgc2luY2UgdGhlIGluZm9ybWF0aW9uIGlzIHB1YmxpYy4gVGhp cyB3aWxsIG1ha2UgaXQgYXBwZWFyIHRoYXQgRVNOSSBpcyBzdXBwb3J0ZWQNCiAoZm9yIGxlZ2Fs IHNpdGVzKSwgYnV0IHN0aWxsIGJsb2NrIHRoZSB1c2UgdG8gaWxsZWdhbCBzaXRlcy48L2Rpdj4N CjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk9yIGV2ZW4gZG8gYSByZXZlcnNlLUROUyBsb29rdXAg b24gdGhlIGRlc3RpbmF0aW9uIElQLCBkaXNjb3ZlciBhbGwgdGhlIGRvbWFpbnMgdGhlcmUsIGFu ZCB0aGVuIGNhbGN1bGF0ZSB0aGUgcG9zc2libGUgcmVjb3JkX2RpZ2VzdHMgdG8gc2VlIHdoZXJl IHRoZSB1c2VyIGlzIGdvaW5nLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhpcyBj b3VsZCBiZSBtaXRpZ2F0ZWQgYnkgaGF2aW5nIHRoZSBzYW1lIEVTTklLZXlzIGZvciBkaWZmZXJl bnQgd2Vic2l0ZXMsIGJ1dCB0aGF0IG1lYW5zIHRoZSAmcXVvdDtTcGxpdCBNb2RlIFRvcG9sb2d5 JnF1b3Q7IGlzIGJyb2tlbiBhcyB0aGUgcmVjb3JkX2RpZ2VzdCBjYW5ub3QgYmUgdXNlZCBieSB0 aGUgQ2xpZW50LUZhY2luZyBTZXJ2ZXIgdG8gc2VsZWN0IGEgQmFja2VuZCBTZXJ2ZXIuPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkkgdGhpbmsg eW91IG1heSBiZSBtaXN1bmRlcnN0YW5kaW5nIHRoZSBkZXNpZ24gaGVyZS4gQWxsIG9mIHRoZSBF U05JLWVuYWJsZWQgc2l0ZXMgYmVoaW5kIHRoZSBzYW1lIGNsaWVudC1mYWNpbmcgc2VydmVyIChz cGxpdCBtb2RlIG9yIG5vdCkgdXNlIHRoZSBzYW1lIGtleXMsIGFuZCBoZW5jZSBoYXZlIHRoZSBz YW1lIHJlY29yZF9kaWdlc3QuIFRodXMsIHJlY29yZF9kaWdlc3QgaXMganVzdCBhbiBhbGlhcyBm b3IgYW5vbnltaXR5IHNldC4NCiBUaGUgY2xpZW50LWZhY2luZyBzZXJ2ZXIgZG9lcyBub3QgdXNl IHRoZSByZWNvcmRfZGlnZXN0IHRvIHNlbGVjdCB0aGUgYmFja2VuZCBzZXJ2ZXIuIEl0IHVzZXMg dGhlIHJlY29yZF9kaWdlc3QgdG8gZmluZCB3aGljaCBvZiB0aGUga2V5cyBpdCBoYXMgb2ZmZXJl ZCBhbmQgdGhlbiB1c2VzIHRoYXQga2V5IHRvIGRlY3J5cHQgdGhlIHRydWUgU05JLiBOb3RlIHRo YXQgaW4gc29tZSBuYWl2ZSBzZW5zZSB5b3UgZG9uJ3QgbmVlZCBhIHJlY29yZF9kaWdlc3QNCiBh dCBhbGwuIEl0J3MganVzdCB0aGVyZSB0byBmYWNpbGl0YXRlIHRoZSBjbGllbnQtZmFjaW5nIHNl cnZlciBoYXZpbmcgbXVsdGlwbGUgdmFsaWQgRVNOSSBrZXkgc2V0cyAoZS5nLiwgZm9yIHJvbGxv dmVyKSBhdCBvbmUgdGltZS48YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+SXQncyBpbXBsaWVk IHRoYXQgcmVjb3JkX2RpZ2VzdCBpcy9jYW4gYmUgdXNlZCB0byBzZWxlY3QgdGhlICZxdW90O29y aWdpbiBzZXJ2ZXImcXVvdDsuIElmIG5vdCwgdGhlbiB0aGUgd29yZGluZyBzaG91bGQgYmUgY2xh cmlmaWVkLiZuYnNwOzwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+QWdhaW4sIGJlY2F1 c2UgdGhpcyBpcyBvcHRpb25hbCwgdGhlIChpbml0aWFsKSBzZXQgb2Ygc2VydmVycyB0aGF0IHVz ZSBFU05JIHdpbGwgYmUgc21hbGwsIGFuZCBjYW4gYmUgcmVhc29uYWJseSBkZXRlcm1pbmVkLiBU aGUgYW5vbnltaXR5IHNldCwgYXQgdGhlIGxlYXN0LCBjYW4gYmUgcmVkdWNlZCBieSBkZXN0aW5h dGlvbiBhZGRyZXNzIHZpYSByZXZlcnNlLUROUy4gQ0ROcyB3aWxsIHJlc29sdmUgZG9tYWlucyB0 byBkaWZmZXJlbnQNCiBJUHMgKG9uIHZhcmlvdXMgbWV0cmljcykgd2hpY2ggY291bGQgbGVhayBp bmZvcm1hdGlvbiB0byBoZWxwIG5hcnJvdyBkb3duIHRoZSBhY3R1YWwgZG9tYWluLiBTbywgaXQg c3RpbGwgY2FuIGV4cG9zZSBhIHNldCBvZiBwb3NzaWJsZSBkZXN0aW5hdGlvbiBkb21haW5zIHRo YXQgdGhlIHVzZXIgaXMgYXR0ZW1wdGluZyB0byByZWFjaC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9k aXY+DQo8ZGl2Pk15IGZlYXIgaXMgdGhhdCB0aGVyZSdzIGVub3VnaCBwb3RlbnRpYWwgbGVha2Fn ZSB0aGF0IHNvbWV0aGluZyBzaG91bGQgYmUgbWVudGlvbmVkIGluIHNlY3VyaXR5IGNvbnNpZGVy YXRpb25zLiZuYnNwOzwvZGl2Pg0KPGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2 Pg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2IGNsYXNzPSJnbWFpbF9leHRyYSI+DQo8ZGl2IGNsYXNz PSJnbWFpbF9xdW90ZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2Jv cmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0i d29yZC13cmFwOmJyZWFrLXdvcmQ7bGluZS1icmVhazphZnRlci13aGl0ZS1zcGFjZSI+DQo8ZGl2 PkFoLCBidXQgaWYgdGhlIENETiBtYXBzIHRoZSBzaGFyZWQtRVNOSUtleXMgZG9tYWlucyB0byBi ZSBkaWZmZXJlbnQgSVBzLCB0aGVuIGRvZXNu4oCZdCBtYXR0ZXIuIFRoaXMgaXMgbm90IHRoZSBj YXNlLCBhcyB0aGUgSVAgYWRkcmVzcyBjYW4gbm93IGJlIHVzZWQgYWxvbmcgd2l0aCB0aGUgRVNO SUtleXMgdG8ga25vdyB3aGF0IHRoZSBmaW5hbCBkZXN0aW5hdGlvbiBpcy4mbmJzcDs8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+WWVzLCB5b3Ug bmVlZCB0byB1c2UgdGhlIHNhbWUgSVBzLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+ LUVrcjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9x dW90ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlk O3BhZGRpbmctbGVmdDoxZXgiPg0KPGRpdiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQ7bGlu ZS1icmVhazphZnRlci13aGl0ZS1zcGFjZSI+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJjb2xvcjpyZ2IoMCwwLDApO2xldHRlci1zcGFjaW5nOm5vcm1hbDt0 ZXh0LWFsaWduOnN0YXJ0O3RleHQtaW5kZW50OjBweDt0ZXh0LXRyYW5zZm9ybTpub25lO3doaXRl LXNwYWNlOm5vcm1hbDt3b3JkLXNwYWNpbmc6MHB4O3dvcmQtd3JhcDpicmVhay13b3JkIj4NCjxk aXYgc3R5bGU9ImNvbG9yOnJnYigwLDAsMCk7bGV0dGVyLXNwYWNpbmc6bm9ybWFsO3RleHQtYWxp Z246c3RhcnQ7dGV4dC1pbmRlbnQ6MHB4O3RleHQtdHJhbnNmb3JtOm5vbmU7d2hpdGUtc3BhY2U6 bm9ybWFsO3dvcmQtc3BhY2luZzowcHg7d29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdj4tLTwv ZGl2Pg0KPGRpdj4tVG9kZCBTaG9ydDwvZGl2Pg0KPGRpdj4vLyA8YSBocmVmPSJtYWlsdG86dHNo b3J0QGFrYW1haS5jb20iIHRhcmdldD0iX2JsYW5rIj50c2hvcnRAYWthbWFpLmNvbTwvYT48L2Rp dj4NCjxkaXY+Ly8gJnF1b3Q7T25lIGlmIGJ5IGxhbmQsIHR3byBpZiBieSBzZWEsIHRocmVlIGlm IGJ5IHRoZSBJbnRlcm5ldC4mcXVvdDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+DQo8ZGl2Pg0KPGRpdiBjbGFzcz0iaDUi Pg0KPGRpdj5PbiBKdWwgMywgMjAxOCwgYXQgMTA6MjYgQU0sIFNuaWZmZW4sIEJyaWFuICZsdDs8 YSBocmVmPSJtYWlsdG86YnNuaWZmZW49NDBha2FtYWkuY29tQGRtYXJjLmlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+YnNuaWZmZW49NDBha2FtYWkuY29tQGRtYXJjLjx3YnI+aWV0Zi5vcmc8L2E+ Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0ibV8xMzY4NjI3MzA5MjUyMTk1ODYzQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdiBjbGFzcz0iaDUiPkxvb2tzIG5lYXQuIDxicj4NCjxicj4NCjEpIFRGTyBET1MgdmVj dG9yOiBpcyB0aGUgaWRlYSBzZXJ2ZXJzIHdpbGwgZGlzYWJsZSBURk8gdW5kZXIgc3RyYWluIGJ1 dCBub3QgYmUgYWJsZSB0byBkaXNhYmxlIEVTTkk/PGJyPg0KPGJyPg0KMikg4oCcY2xpZW50cyBt aWdodCBvcHQgdG8gYXR0ZW1wdCBjYXB0aXZlIHBvcnRhbCBkZXRlY3Rpb24gdG8gc2VlIGlmIHRo ZXkgYXJlIGluIHRoZSBwcmVzZW5jZSBvZiBhIE1JVE0gcHJveHksIGFuZCBpZiBzbyBkaXNhYmxl IEVTTkku4oCdPGJyPg0KPGJyPg0KSWYgSeKAmW0gb3BlcmF0aW5nIGEgZ3JlYXQgZmlyZXdhbGws IEkgY2FuIHVzZSB0aGlzIHRvIGRpc2NvdmVyIGRpc3NpZGVudHMsIHJpZ2h0PyZuYnNwOyBFaXRo ZXIgdGhleSBzZW5kIG1lIGRhbmdlcm91cyBTTkkgdmFsdWVzIG9yIHRoZXkgYXJlIGNvbmZpZ3Vy ZWQgdG8gbm90IGRpc2FibGUgRVNOSSwgYW5kIHRha2luZyB0aGUgZmlmdGggaXMgZmF0YWwuIFRv IHByb3RlY3QgdGhlbSwgSSB0aGluayBub2JvZHkgY2FuIGhhdmUgdGhpcyBtb2RlLg0KPGJyPg0K PGJyPg0KMykgSG93IG1hbnkgYml0cyBkb2VzIHRoaXMgb2ZmZXI/IEhpZGluZyBpbiBhIHNldCBv ZiBhIG1pbGxpb24gdW5pZm9ybSBob3N0cyBpcyAyMCBiaXRzLCBhbmQgdGhlIG5vbnVuaWZvcm1p dHkgd2lsbCBhY2NydWUgdG8gdGhlIGFkdmVyc2FyeeKAmXMgYmVuZWZpdC4gQWN0aXZlIHByb2Jp bmcgd2lsbCB1bm1hc2sgdmlzaXRvcnMgdG8gZGlzc2lkZW50IHNpdGVzLjxicj4NCjxicj4NCkkg d29ycnkgdGhhdCB0aGlzIHRvb2wgaXMgc28gd2VhayBhZ2FpbnN0IGEgR0ZXLXN0eWxlIGFkdmVy c2FyeSBmb3IgdGhlIHB1cnBvc2Ugb2YgYWxsb3dpbmcgZGlzc2lkZW50IGFjY2VzcyB0byByZXN0 cmljdGVkIHdlYiBzaXRlcyB0aGF0IGl0IHdpbGwgYmUgZGFuZ2Vyb3VzIGlmIHJlbGVhc2VkLiBC dXQgbWF5YmUgSSBtaXN1bmRlcnN0YW5kIHRoZSBwdXJwb3NlLiBJZiB0aGlzIGlzIGp1c3QgdG8g a2VlcCBXZXN0ZXJuIElTUHMgZnJvbSBtb25rZXlpbmcNCiB3aXRoIHRyYWZmaWMsIHN1cmUsIHNo aXAgaXQuJm5ic3A7IExhYmVsbGluZyB0aGUgZW5jcnlwdGlvbiB3aXRoIGl0cyBzdHJlbmd0aCBh cyBhcHBsaWVkLCBvciBzaG93aW5nIENETnMgYW5kIElTUHMgaG93IHRvIHdvcmsgb3V0IHNvbWUg Ym91bmRzLCBzZWVtcyBvbmUgd2F5IHRvIGhlbHAgdXNlcnMgdW5kZXJzdGFuZCB3aGV0aGVyIHRo aXMgY2FuIGhlbHAgdGhlbSBvciBwdXQgdGhlbSBtb3JlIGF0IHJpc2suDQo8YnI+DQo8YnI+DQot LSA8YnI+DQpCcmlhbiBTbmlmZmVuPGJyPg0KPGJyPg0KPC9kaXY+DQo8L2Rpdj4NCjxzcGFuIGNs YXNzPSIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzx3YnI+X19fX19fX19fX19fX19f X188YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9y Z19tYWlsbWFuX2xpc3RpbmZvX3RscyZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0 anBONkxaZyZhbXA7cj1RQkVjUXNxb1VEZGsxUTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210Umlr JmFtcDttPWpPNkZ0R3hId0k4VjVyY0tOSkozbnlXdDMwbnVZUnhEc013NFNyRGpRdjgmYW1wO3M9 dWdONlNYVGhqWjVvYnF2MlYzVmVkN2lsaGg4bjhnWGRGc09WYWpKOXpSMCZhbXA7ZT0iIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuLzx3YnI+bGlzdGluZm8vdGxz PC9hPjxicj4NCjwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 YnI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8YnI+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_AE0160F7659347F7BB01261EA8F389CBakamaicom_-- From nobody Fri Jul 6 19:43:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C85130E10 for ; Fri, 6 Jul 2018 19:43:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.08 X-Spam-Level: X-Spam-Status: No, score=0.08 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4H9BFbAw4V61 for ; Fri, 6 Jul 2018 19:43:54 -0700 (PDT) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DACC31277C8 for ; Fri, 6 Jul 2018 19:43:53 -0700 (PDT) Received: by mail-yw0-x232.google.com with SMTP id e23-v6so4339082ywe.13 for ; Fri, 06 Jul 2018 19:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K11leoC/6ObnbII22/nUsrgu5AdYs41LgXin2pKeCME=; b=aybuxWWW7aOR6X307dsn2M65UpwBPYFTO3pNiFW+pocOZh0f/ZxggXjDg6Rhp9v0eF 0geLGw6G42HysuGnC/+3WM5njzqfPaJUJSjc2M37L4ehDhMA2kHuwXqJ5/W+Szei+HZH m0kyFdraqRy8L8NfO8Vho6oxMmjJ1nhDEBrJL6xaTD7xxnx8/WoFz+j8ywiAL8Th3MGS yLAJ7PlmKAotgRDYL5hW9cc6qJWJNQgaxsVnpH8R/8mFGo0ESPln8Hx7AZmIz9b4mTvx XbfvxM/VbwbAbbudAKtWK/XFNDJrsEq+slgmm4agP2K0KsN9Kv8ZhIAv88JICgaLLCtX sEUg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K11leoC/6ObnbII22/nUsrgu5AdYs41LgXin2pKeCME=; b=PTTOXOWonjvymqzScRWh6p+ZuCqbGlyfiY0zxz7aySmEC+Wi5z/vnwvOsPACaGO7tc FJ/E3OlDaQ29ovvmSFUILGvjm6MGsX2cRRiIyVxyeJP+uUOKILTn66bpf+tK3dNI54PJ ksqqGGH615HrBD98hxssyAiZzMJrldzFOEtpACdIKRUmxCa5vNYqmasB3MmI1J7n4F8P lzsoGKOAyivReuSdMnWxGD7UBXKkOtSw7QxYIQ/A6xxxaaFfqo8GT6nnuk73/JT0SyTN dNxhavfdNWzF/9K04S+JFP/2FTKakuQPDue0HtGeBGxYRk4yKKvXVgwwi98Tp1PXrHdt asTw== X-Gm-Message-State: APt69E2LMT+23p/vYXDv/dmnLaoQZrBeK/ymdg8kylQuS+glsM9Qbx6N zyMUhvpyzsEdETX9057gZexujK/drFbCQfH5zNiggwp4 X-Google-Smtp-Source: AAOMgpcZ563pC6I3iemB1baawEjlawbWYbmXyTsf+3B2kfIQ5X2MH7S54oomSzpQ6xKXRXwiZ3l60ZefkIYwD0y0eZQ= X-Received: by 2002:a0d:fe07:: with SMTP id o7-v6mr5923575ywf.167.1530931433014; Fri, 06 Jul 2018 19:43:53 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 6 Jul 2018 19:43:12 -0700 (PDT) In-Reply-To: References: <0AE65C49-5D09-44A0-BD30-4016AC39E293@akamai.com> From: Eric Rescorla Date: Fri, 6 Jul 2018 19:43:12 -0700 Message-ID: To: "Short, Todd" Cc: "" , "Sniffen, Brian" Content-Type: multipart/alternative; boundary="0000000000003da30f05705fc020" Archived-At: Subject: Re: [TLS] DNS-based Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 07 Jul 2018 02:43:57 -0000 --0000000000003da30f05705fc020 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 6, 2018 at 7:17 PM, Short, Todd wrote: > > (Pardon phone typos below.) > -- > -Todd Short > // Sent from my iPhone > // "One if by land, two if by sea, three if by the Internet." > > > On Jul 6, 2018, at 4:43 PM, Eric Rescorla wrote: > > > > On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd wrote: > >> Fundamentally, unless this type of protection is baked into the protocol >> from the beginning, and is not an add-on option, any one/thing in the pa= th >> can prevent the use of optional security features. >> >> Don=E2=80=99t want people to access site XYZ? Block DNSSEC, block _ESNI = DNS >> requests/responses, block the use of ESNI, etc. >> > > These are sort of different things. It's true that if you control DNS, > it's basically game over, which is why this is most attractive with DOH t= o > some location not controlled by the censor. However, if you *do* have DOH= , > then the client shouldn't fall back, with the result that blocking ESNI > blocks all ESNI-enabled sites, not just those which are sensitive > > > Which makes this mechanism potentially useless. If it was mandatory in > TLSv1.3, then trying to block encrypted SNI would be break a lot more > sites, and might have to be allowed. > I'm not sure I agree with this, but I also don't see a lot of point in debating it. > A firewall can also use the record_digest to determine the destination, >> without even decrypting the ESNI. It just calculates the possible >> record_digests of the blocked sites; since the information is public. Th= is >> will make it appear that ESNI is supported (for legal sites), but still >> block the use to illegal sites. >> >> Or even do a reverse-DNS lookup on the destination IP, discover all the >> domains there, and then calculate the possible record_digests to see whe= re >> the user is going. >> >> This could be mitigated by having the same ESNIKeys for different >> websites, but that means the "Split Mode Topology" is broken as the >> record_digest cannot be used by the Client-Facing Server to select a >> Backend Server. >> > > I think you may be misunderstanding the design here. All of the > ESNI-enabled sites behind the same client-facing server (split mode or no= t) > use the same keys, and hence have the same record_digest. Thus, > record_digest is just an alias for anonymity set. The client-facing serve= r > does not use the record_digest to select the backend server. It uses the > record_digest to find which of the keys it has offered and then uses that > key to decrypt the true SNI. Note that in some naive sense you don't need= a > record_digest at all. It's just there to facilitate the client-facing > server having multiple valid ESNI key sets (e.g., for rollover) at one ti= me. > > > It's implied that record_digest is/can be used to select the "origin > server". If not, then the wording should be clarified. > I'm not sure where you're getting this from. Here's the text in question: " o If the EncryptedSNI.record_digest value does not match the cryptographic hash of any known ENSIKeys structure, it MUST abort the connection with an "illegal_parameter" alert. This is " Anyway, if you think this should be clarified, please feel free to submit a PR. > Again, because this is optional, the (initial) set of servers that use > ESNI will be small, and can be reasonably determined.The anonymity set, a= t > the least, can be reduced by destination address via reverse-DNS. CDNs wi= ll > resolve domains to different IPs (on various metrics) which could leak > information to help narrow down the actual domain. So, it still can expos= e > a set of possible destination domains that the user is attempting to reac= h. > Yes, it's true that the client-facing servers need to take steps to put people in the same anonymity set on the same IP. In general, we have a pile of sources of privacy leakage (cert in the TLS handshake, DNS, SNI, IP addr, traffic analysis, etc.). In order to make any progress, we're going to need to tackle them one at a time. My fear is that there's enough potential leakage that something should be > mentioned in security considerations. > Again, PR welcome. -Ekr > > > Ah, but if the CDN maps the shared-ESNIKeys domains to be different IPs, >> then doesn=E2=80=99t matter. This is not the case, as the IP address can= now be >> used along with the ESNIKeys to know what the final destination is. >> > > Yes, you need to use the same IPs. > > -Ekr > > >> -- >> -Todd Short >> // tshort@akamai.com >> // "One if by land, two if by sea, three if by the Internet." >> >> On Jul 3, 2018, at 10:26 AM, Sniffen, Brian < >> bsniffen=3D40akamai.com@dmarc.ietf.org> wrote: >> >> Looks neat. >> >> 1) TFO DOS vector: is the idea servers will disable TFO under strain but >> not be able to disable ESNI? >> >> 2) =E2=80=9Cclients might opt to attempt captive portal detection to see= if they >> are in the presence of a MITM proxy, and if so disable ESNI.=E2=80=9D >> >> If I=E2=80=99m operating a great firewall, I can use this to discover di= ssidents, >> right? Either they send me dangerous SNI values or they are configured = to >> not disable ESNI, and taking the fifth is fatal. To protect them, I thin= k >> nobody can have this mode. >> >> 3) How many bits does this offer? Hiding in a set of a million uniform >> hosts is 20 bits, and the nonuniformity will accrue to the adversary=E2= =80=99s >> benefit. Active probing will unmask visitors to dissident sites. >> >> I worry that this tool is so weak against a GFW-style adversary for the >> purpose of allowing dissident access to restricted web sites that it wil= l >> be dangerous if released. But maybe I misunderstand the purpose. If this= is >> just to keep Western ISPs from monkeying with traffic, sure, ship it. >> Labelling the encryption with its strength as applied, or showing CDNs a= nd >> ISPs how to work out some bounds, seems one way to help users understand >> whether this can help them or put them more at risk. >> >> -- >> Brian Sniffen >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> >> >> > --0000000000003da30f05705fc020 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 6, 2018 at 7:17 PM, Short, Todd <tshort@akamai.com>= wrote:

(Pardon phone typos below.)
--
-Todd Short
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."= ;


On Jul 6, 2018, at 4:43 PM, Eric Rescorla <ekr@rtfm.com> wrote:



On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd <tshort@akamai.co= m> wrote:
Fundamentally, unless this type of protection is baked into the protoc= ol from the beginning, and is not an add-on option, any one/thing in the pa= th can prevent the use of optional security features.

Don=E2=80=99t want people to access site XYZ? Block DNSSEC, block _ESN= I DNS requests/responses, block the use of ESNI, etc.

These are sort of different things. It's true that if you control = DNS, it's basically game over, which is why this is most attractive wit= h DOH to some location not controlled by the censor. However, if you *do* h= ave DOH, then the client shouldn't fall back, with the result that blocking ESNI blocks all ESNI-enabled sites, no= t just those which are sensitive

Which makes this mechanism potentially useless. If it was manda= tory in TLSv1.3, then trying to block encrypted SNI would be break a lot mo= re sites, and might have to be allowed.=C2=A0
=
I'm not sure I agree with this, but I also don't see= a lot of point in debating it.

=C2=A0
A firewall can also use the record_digest to determine the destination= , without even decrypting the ESNI. It just calculates the possible record_= digests of the blocked sites; since the information is public. This will ma= ke it appear that ESNI is supported (for legal sites), but still block the use to illegal sites.

Or even do a reverse-DNS lookup on the destination IP, discover all th= e domains there, and then calculate the possible record_digests to see wher= e the user is going.

This could be mitigated by having the same ESNIKeys for different webs= ites, but that means the "Split Mode Topology" is broken as the r= ecord_digest cannot be used by the Client-Facing Server to select a Backend= Server.

I think you may be misunderstanding the design here. All of the ESNI-e= nabled sites behind the same client-facing server (split mode or not) use t= he same keys, and hence have the same record_digest. Thus, record_digest is= just an alias for anonymity set. The client-facing server does not use the record_digest to select the back= end server. It uses the record_digest to find which of the keys it has offe= red and then uses that key to decrypt the true SNI. Note that in some naive= sense you don't need a record_digest at all. It's just there to facilitate the client-facing server having = multiple valid ESNI key sets (e.g., for rollover) at one time.

It's implied that record_digest is/can be used to select th= e "origin server". If not, then the wording should be clarified.= =C2=A0

I'm not sure where y= ou're getting this from. Here's the text in question:
"=C2=A0=C2=A0 o=C2=A0 If the EncryptedSNI.record_digest va= lue does not match the
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 cryptographic hash= of any known ENSIKeys structure, it MUST abort
=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 the connection with an "illegal_parameter" alert.=C2=A0 Th= is is
"

Anyway, if you think this should b= e clarified, please feel free to submit a PR.

=C2= =A0
Again, because this is optional, the (initial) set of servers that use= ESNI will be small, and can be reasonably determined.The anonymity set, at= the least, can be reduced by destination address via reverse-DNS. CDNs wil= l resolve domains to different IPs (on various metrics) which could leak information to help narrow down = the actual domain. So, it still can expose a set of possible destination do= mains that the user is attempting to reach.
= =C2=A0
Yes, it's true that the client-facing servers need to = take steps to put people in the same anonymity set on the same IP. In gener= al, we have a pile of sources of privacy leakage (cert in the TLS handshake= , DNS, SNI, IP addr, traffic analysis, etc.). In order to make any progress= , we're going to need to tackle them one at a time.


My fear is that there's enough potential leakage that something sh= ould be mentioned in security considerations.=C2=A0

Again, PR welcome.

-Ekr




Ah, but if the CDN maps the shared-ESNIKeys domains to be different IP= s, then doesn=E2=80=99t matter. This is not the case, as the IP address can= now be used along with the ESNIKeys to know what the final destination is.= =C2=A0

Yes, you need to use the same IPs.

-Ekr


--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."= ;

On Jul 3, 2018, at 10:26 AM, Sniffen, Brian <bsniffen=3D40akamai.c= om@dmarc.ietf.org> wrote:

Looks ne= at.

1) TFO DOS vector: is the idea servers will disable TFO under strain but no= t be able to disable ESNI?

2) =E2=80=9Cclients might opt to attempt captive portal detection to see if= they are in the presence of a MITM proxy, and if so disable ESNI.=E2=80=9D=

If I=E2=80=99m operating a great firewall, I can use this to discover dissi= dents, right?=C2=A0 Either they send me dangerous SNI values or they are co= nfigured to not disable ESNI, and taking the fifth is fatal. To protect the= m, I think nobody can have this mode.

3) How many bits does this offer? Hiding in a set of a million uniform host= s is 20 bits, and the nonuniformity will accrue to the adversary=E2=80=99s = benefit. Active probing will unmask visitors to dissident sites.

I worry that this tool is so weak against a GFW-style adversary for the pur= pose of allowing dissident access to restricted web sites that it will be d= angerous if released. But maybe I misunderstand the purpose. If this is jus= t to keep Western ISPs from monkeying with traffic, sure, ship it.=C2=A0 Labelling the encryption with its stren= gth as applied, or showing CDNs and ISPs how to work out some bounds, seems= one way to help users understand whether this can help them or put them mo= re at risk.

--
Brian Sniffen

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



--0000000000003da30f05705fc020-- From nobody Mon Jul 9 03:58:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2549130E3C for ; Mon, 9 Jul 2018 03:58:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oc38tXTAoYii for ; Mon, 9 Jul 2018 03:58:41 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B59B012D7F8 for ; Mon, 9 Jul 2018 03:58:41 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C455C857AB; Mon, 9 Jul 2018 10:58:40 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-16.brq.redhat.com [10.40.200.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id 005122166BA2; Mon, 9 Jul 2018 10:58:38 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 09 Jul 2018 12:58:33 +0200 Message-ID: <8417187.FtxZZQNsAt@pintsize.usersys.redhat.com> In-Reply-To: <1530757910178.45400@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <1530757910178.45400@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5302405.CUEPRHvGVM"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 09 Jul 2018 10:58:40 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Mon, 09 Jul 2018 10:58:40 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 10:58:44 -0000 --nextPart5302405.CUEPRHvGVM Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 5 July 2018 04:32:08 CEST Peter Gutmann wrote: > David Benjamin =E2=80=8B writes: > >The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit > >minimum. (Chrome enabled far more DHE ciphers than others, so we > >encountered a lot of this.) 2048-bit was completely hopeless. At the time > >of removal, 95% of DHE negotiations made by Chrome used a 1024-bit > >minimum. >=20 > How does Google, rather than the people running the systems being connect= ed > to, know that 1024-bit DH isn't secure enough for a given environment? T= he > majority of this stuff is running on isolated, private networks or inside > VPN tunnels for which pretty much anything, including 512-bit keys, are > fine. There Is No Such Thing As A Trusted Network and there wasn't for half a decade at least If the IPsec is used for p2p security, then the TLS is useless in the first= =20 place. If there is "last leg" that goes over regular copper or fibre, then = TLS=20 is providing the security, so 512 big keys are NOT secure https://cloud.google.com/beyondcorp/ https://blog.cloudpassage.com/2015/10/06/the-end-of-trusted-networks/ and dozens of other articles on the topic I'll just ignore the fact that no browser has ability to tell if it is=20 connecting over such "secure" network or not, let alone making it=20 unexploitable for regular Internet connections... =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart5302405.CUEPRHvGVM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltDP9kACgkQkqjRuAHS 9fVd6BAAnb+em2kDy6XAIWIudbgZOKQoO3hJTp4zX1KhNJVYV690BwJuAt4qItU3 YE2WEl2gXhugeYrkGp/yBQGsWUcDq8th+JkMprOZ5K80gFQLkdZoubYS0WbPCiEz 9I+BpKOfKoV2JvoKhiK43TjcmgDrCdOaN6cYnXdoAeiO83g+8THC4vv/EClXNf5T +UGsPacGKHoLHRkbhicDO9p7r0l0lN3axCXf4myEgN4cmowR+2pabjSEklCLZEN5 ahRKl91NeLDnAd+mbXL2MgPXZGxLNtkMjXh8t8wDcTpp+uH/GuTIwJEKtBKBMKav H/a7pWRWRgHS/dU2X3dkz0/RQpZyutcIhIBAg54ms1fykyvPh77mX3G8fMdAWO1D Dqs+MqDPXxX4tr42cv2DmZpVgyXJgN4fGBvXG4uBJKZp5o4xbzSmjt1MYX2NHCuF DfDGpJVkVmW3RSb8WWCKZizlVcZp5JmcLpWXulaVH1L7jprpVLbgsY40Yf2ztZey o3Usa4iGjDLUqpshQw0XObu4ITNvRA2mqmmcCC3qH9AmG3PMDYexN8hz8WUurl2f ItB5nfViFAOzBUPpn0q/uKVqhz0zuJMpQgop5vXQ5b4bZJ5+Qmfdy/7Z4ImM9OuB +nJEmRiVpr5bwY2mL9nEDvqrgRdY2XLCIYXl/D1kHMSJ3fuWels= =p8pZ -----END PGP SIGNATURE----- --nextPart5302405.CUEPRHvGVM-- From nobody Mon Jul 9 04:01:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5E6512D7F8 for ; Mon, 9 Jul 2018 04:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g96nuUXB3cWk for ; Mon, 9 Jul 2018 04:01:48 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64B58130F9A for ; Mon, 9 Jul 2018 04:01:48 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id B14B983207; Mon, 9 Jul 2018 11:01:47 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-16.brq.redhat.com [10.40.200.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id 7DFDA2026D65; Mon, 9 Jul 2018 11:01:46 +0000 (UTC) From: Hubert Kario To: tls@ietf.org, mrex@sap.com Date: Mon, 09 Jul 2018 13:01:45 +0200 Message-ID: <4534346.lDc38SZVkg@pintsize.usersys.redhat.com> In-Reply-To: <20180705181827.5820E409B@ld9781.wdf.sap.corp> References: <1530687136897.97792@cs.auckland.ac.nz> <1530757910178.45400@cs.auckland.ac.nz> <20180705181827.5820E409B@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart20695365.UrfWVJa5FV"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 09 Jul 2018 11:01:47 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 09 Jul 2018 11:01:47 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 11:01:50 -0000 --nextPart20695365.UrfWVJa5FV Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 5 July 2018 20:18:27 CEST Martin Rex wrote: > btw. which kind of "problematic pure-RSA" are you talking of? > I'm not actually aware of any problem=20 the ones that gave us 20 years of oracles to use for attacking encrypted=20 connections Bleichenbacher and ROBOT, and those are not even /timing/ based attacks! =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart20695365.UrfWVJa5FV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltDQJkACgkQkqjRuAHS 9fVKmRAAn1it3H1fvHR4Vza3sblXDlY9CLK6jMVperh9WXpOceWs7ryefe4b3v+H JcdzCzfFFfx8Yal1eNvibkBZFthTwbRreg6pOtFkK3Yi1DLDUwW15HcHjbzZAv5z mDT0UXeH6fOKDXrf73QRXoYtfmUUI25MJE+oyloArKVaNGAOSODXrE39LW7yquwd Od9mfBCrCPvAxpOwZGoIuPxIv3ptB/c3S/9a3Rvs/ltavL0PvotbYWXJ+iTose7J 3ovUmrY6quR40noRDirP0nH/9Fa29PX+jCD692Bb4PhPyTcGVxBWMCFmqRenzEYy EVvDvM2KZGvmLLfq4plEhRv0duOQrqqEmt8AKUsnre/EkQq/em/8lYcvQ3GaUkjC sttRDf2UJFwWNKcb6BnwMzlReCNLPCi7d3iIEvGvRU1GUIXUJZ8kJMqtDiEJRjs3 kgOeAgzb5fj+QhI+3XbQzkbmOzEmURSiQ9HWyNjsUwqQNpC2MxEbhKHnYFufnniQ CO/GqrTt1M0vRB0Xk3sfRWkQRlgg+QjlgbVmaIgyIrqbAE03VtbQ07crsZsteU5Q C7q++y7ryzlb+6/Q2UQXXloAnzaS/qL2uoj6bkEX5CIblMETjMmultLGc+Kgw8wM PUNXgAWbPgxwqprc17O0feyCfOW4/wlGoWv/KF+xXPv46FBMVos= =u8Es -----END PGP SIGNATURE----- --nextPart20695365.UrfWVJa5FV-- From nobody Mon Jul 9 04:55:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 982F2130DEE for ; Mon, 9 Jul 2018 04:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfvPjLKwcS5A for ; Mon, 9 Jul 2018 04:55:47 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 528F412D7F8 for ; Mon, 9 Jul 2018 04:55:47 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9001083207; Mon, 9 Jul 2018 11:38:45 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-16.brq.redhat.com [10.40.200.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9836A2156889; Mon, 9 Jul 2018 11:38:44 +0000 (UTC) From: Hubert Kario To: Martin Thomson Cc: "" Date: Mon, 09 Jul 2018 13:38:43 +0200 Message-ID: <15164129.iB2ZhdnDRk@pintsize.usersys.redhat.com> In-Reply-To: References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1597638.mVuHIr1vSW"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 09 Jul 2018 11:38:45 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.1]); Mon, 09 Jul 2018 11:38:45 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Malformed Finished handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 11:55:49 -0000 --nextPart1597638.mVuHIr1vSW Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Thursday, 5 July 2018 02:06:45 CEST Martin Thomson wrote: > On Wed, Jul 4, 2018 at 7:55 PM Hubert Kario wrote: > > Despite this, is it correct to terminate a connection with > > "illegal_parameter" upon receiving a Finished handshake message with a > > 100 byte payload? or a 20 byte payload? My opinion is that it is not, > > "decode_error" is more specific so it should be used instead. >=20 > When there are multiple problems with a message, why do we need to > accept just one of the possible alerts? That assumes either a very > particular order of processing, or a strict precedence order for > errors. Like Rich says, there is a degree of imprecision in our error > reporting, but - for me - that's OK. but there are no multiple problems with the message in question no part of the TLS standards states that the implementation should check if= =20 the length of the handshake message lies within expected bounds but there *is* a section that explicitly calls out that the implementation= =20 needs to verify if the handshake message matches the header, *after* parsing =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1597638.mVuHIr1vSW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltDSUMACgkQkqjRuAHS 9fWd4BAAgBHS3nW6zzs01nLnQN94r1f+CxBurdMfpBgGuewWHTkpJ8s48GbIN9u2 fzPfeg9FnbdZ8tahuJ/+NWB1sWnujoq1149vW3vbs5K0U4buxz8ZLub6GWY9PRDK qoZYQt0cnbcfkRkDobENI3jdmc8azDUn3n1N1UYBdAos9gBRmgqyGZX1GgrPRdZ5 woX1Z7pBDagK90aCoJV+pAjiCn1jQjEcVzegjII0HoUIysuRadIJaJv56MnHjseg MCQBOx3kAMPe+kRZ8+rzX83sCJ8n762GdLRufTYKZ8iffRw46iBGmM8EN7Pe6OC2 GqBy0p8lyXUaT8xAhawB27E1sgrvoW9jgROJrtf0iiatVe6WQEXvQUw4hcfB2pPB 9uBzM2belCTFkZ13zZ4UOwadKCzDdpkkuDyfOu2738z04eKYfKf56JMN7NKtz3i6 EWlI/dLgu+HWfZqzP2Se3EFHJJidffFklvLjdFNqKpL93ZWyXuixkqlIOGqOEUt2 0NGmXnjAhDEgc2+qnbTT0m17CP2RduSOC5t+T9fXXccuAFkvHa9uJNYw0lsntEz/ QxaDCT2hCxrtLw0SRVHMu23voojaLzwtE2/tRrkpz6g4E6v0/AngiWb5kF5rUR11 rv+hJ+3uTwx5YR7kbRcQO8nIjCny57QNmHkTqqTDf1zzdwMqHBk= =Snzr -----END PGP SIGNATURE----- --nextPart1597638.mVuHIr1vSW-- From nobody Mon Jul 9 05:04:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 879D6126BED for ; Mon, 9 Jul 2018 05:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxQ5Kvj7awio for ; Mon, 9 Jul 2018 05:04:39 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 395D5124C04 for ; Mon, 9 Jul 2018 05:04:39 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D3CD9401EF05; Mon, 9 Jul 2018 11:29:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-16.brq.redhat.com [10.40.200.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id A5A4651E3; Mon, 9 Jul 2018 11:29:29 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: "" Date: Mon, 09 Jul 2018 13:29:28 +0200 Message-ID: <2130941.FryZTEcNbp@pintsize.usersys.redhat.com> In-Reply-To: References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> <10346670.25GZR1XrEq@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart382788306.0sBPEuVBLf"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 09 Jul 2018 11:29:30 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Mon, 09 Jul 2018 11:29:30 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Malformed Finished handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 12:04:41 -0000 --nextPart382788306.0sBPEuVBLf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 4 July 2018 18:54:10 CEST Eric Rescorla wrote: > On Wed, Jul 4, 2018 at 6:36 AM, Hubert Kario wrote: > > On Wednesday, 4 July 2018 15:00:18 CEST Eric Rescorla wrote: > > > I think it's a close call, because the length is sort of external to = the > > > language. > >=20 > > which language? the decode_error alert description literally says "leng= th > > of > > the message was incorrect." >=20 > The protocol definition language. Sorry, I really don't see it. There are multiple references to "length" in = the=20 draft, and as far as I can tell, all are quite consistent. =20 > -Ekr >=20 > > > That's why, for instance, NSS sends "illegal_parameter". So, > > > absent specific text about this value, I think this is something we c= an > > > leave to the implementations. > >=20 > > but the text is explicit, if a message continues past message boundary, > > the > > correct response is decode_error. Decode_error is also consistent with = the > > way > > above-expected length Client Hello MUST be handled. > >=20 > > Just because the description of the message uses a single opaque array > > doesn't > > make this message syntactically any different from other Handshake > > protocol > > message. > >=20 > > if the interpretation of "I know this _message_ _length_ is wrong becau= se > > of > > some other values I negotiated before, so I'll send illegal_parameter" = was > > correct, then overflow_error, decrypt_error and probably few others wou= ld > > also > > need to be replaced with illegal_parameter... > >=20 > > > -Ekr > > >=20 > > > On Wed, Jul 4, 2018 at 2:54 AM, Hubert Kario wrot= e: > > > > Despite this, is it correct to terminate a connection with > > > > "illegal_parameter" > > > > upon receiving a Finished handshake message with a 100 byte payload? > >=20 > > or a > >=20 > > > > 20 > > > > byte payload? My opinion is that it is not, "decode_error" is more > > > > specific so > > > > it should be used instead. > > > >=20 > > > >=20 > > > > Specification says the following on the matter: > > > >=20 > > > > The draft 28 specifies the Finished message as having following > >=20 > > structure: > > > > struct { > > > > =20 > > > > opaque verify_data[Hash.length]; > > > > =20 > > > > } Finished; > > > >=20 > > > > At multiple places it also talks about handling messages that have > >=20 > > sizes > >=20 > > > > that > > > > don't match their structure as requiring termination of connection > > > > with > > > > "decode_error". > > > >=20 > > > > The generic situation in Section 6: > > > > Peers which receive a message which > > > > cannot be parsed according to the syntax (e.g., have a length > > > > extending beyond the message boundary or contain an out-of-range > > > > length) MUST terminate the connection with a "decode_error" aler= t. > > > >=20 > > > > as description of the alert in Section 6.2: > > > > decode_error A message could not be decoded because some field = was > > > > =20 > > > > out of the specified range or the length of the message was > > > > incorrect. This alert is used for errors where the message d= oes > > > > not conform to the formal protocol syntax. > > > >=20 > > > > In specific about Client Hello, in Section 4.1.2: > > > > If negotiating a version of TLS prior to 1.3, a server MUST check > > > > that the message either contains no data after > > > > legacy_compression_methods or that it contains a valid extensions > > > > block with no data following. If not, then it MUST abort the > > > > handshake with a "decode_error" alert. > > > >=20 > > > > And specific handling of Certificate from server in Section 4.4.2.4: > > > > If the server supplies an empty Certificate message, the client > > > > MUST > > > > abort the handshake with a "decode_error" alert. > > > >=20 > > > > Description of "illegal_parameter" in Section 6: > > > > Peers which receive a message which is syntactically correct but > > > > semantically invalid (e.g., a DHE share of p - 1, or an invalid > >=20 > > enum) > >=20 > > > > MUST terminate the connection with an "illegal_parameter" alert. > > > >=20 > > > > Alert description in Section 6.2: > > > > illegal_parameter A field in the handshake was incorrect or > > > > =20 > > > > inconsistent with other fields. This alert is used for errors > > > > which conform to the formal protocol syntax but are otherwise > > > > incorrect. > > > >=20 > > > > (it's also mentioned in over a dozen places in the draft) > > > > -- > > > > Regards, > > > > Hubert Kario > > > > Senior Quality Engineer, QE BaseOS Security team > > > > Web: www.cz.redhat.com > > > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Repub= lic > > > > _______________________________________________ > > > > TLS mailing list > > > > TLS@ietf.org > > > > https://www.ietf.org/mailman/listinfo/tls > >=20 > > -- > > Regards, > > Hubert Kario > > Senior Quality Engineer, QE BaseOS Security team > > Web: www.cz.redhat.com > > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart382788306.0sBPEuVBLf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltDRxgACgkQkqjRuAHS 9fVRHg//f3gk5QNafNPMfPbdcMgEfp0f5Smp/xIVxmEhABw26udIr7tYrYjL8xbh MNrH9zufz9eapQVuK9M7MtBfqjrk4tiSwni62G9HBZHXvNhw/LWAzMzmGf24Nnd7 Qx4L+tNpPvh7eLczARPsDQzi3NzaJc4zH1auJDd62gV/mlvQ3TNXjOJpORyyeyiY yRF5bz0QsmV2Pu84Loa8WcNYf/uWXTeESVVOFUGuV1DL9MDuaOIxrXooO9f/1Fjk JRRExEGYyukWgh/pyd0Qv+4H+vmP0oYiW1xuwzjGMYCZzGPznjxy/Za+ESrqt1lc 6C3kH+S8VSSIh3/uord2Dk5xOhszh23iROY6C/yoozofAejNEuRWzzNo+RwGt1Xs YoHLJNm5OL2+xdrQfQOT8NY3Fy69abgmHdxydyv1NOBpN1sGO0SnBGKljpORA/9W 8kQ+ALiW4ggEHva3rALKwKhLtp6dQDICqM2AJCljDRFKP+oCkGLj8XQkirrw+HKo SCNqLLjQTjHQyHrxagAuELxHOaQDXovsnBU166FxyaxTqPJx+OnfmLxCtwek2A9t rYwt4DIUAnwkZvlB3rcbbey9/NkT2eKfwp+fA5sw7ZRpJsQ0tgAXgknJB0KKInzc do7eqG+qMgdUodwU2WpUZGOhdL01sy9QbA02aLLx4aTXFmNWVnI= =yeQx -----END PGP SIGNATURE----- --nextPart382788306.0sBPEuVBLf-- From nobody Mon Jul 9 05:12:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34755130DC9 for ; Mon, 9 Jul 2018 05:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YqvHSx4ag_IE for ; Mon, 9 Jul 2018 05:12:19 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D5A124C04 for ; Mon, 9 Jul 2018 05:12:19 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 399F040250FF; Mon, 9 Jul 2018 11:27:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-16.brq.redhat.com [10.40.200.16]) by smtp.corp.redhat.com (Postfix) with ESMTP id EDDDE2026D65; Mon, 9 Jul 2018 11:27:24 +0000 (UTC) From: Hubert Kario To: "Salz, Rich" Cc: Eric Rescorla , "" Date: Mon, 09 Jul 2018 13:27:23 +0200 Message-ID: <2272713.B1rdPjq6dU@pintsize.usersys.redhat.com> In-Reply-To: <76911F76-2FF1-4EAB-8BEA-784B805184F2@akamai.com> References: <2069745.MLjj786GGa@pintsize.usersys.redhat.com> <10346670.25GZR1XrEq@pintsize.usersys.redhat.com> <76911F76-2FF1-4EAB-8BEA-784B805184F2@akamai.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2808641.ccO3BPbT5W"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 09 Jul 2018 11:27:26 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 09 Jul 2018 11:27:26 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Malformed Finished handling X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 12:12:21 -0000 --nextPart2808641.ccO3BPbT5W Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 4 July 2018 15:46:04 CEST Salz, Rich wrote: > > if the interpretation of "I know this _message_ _length_ is wrong > > because of=20 > > some other values I negotiated before, so I'll send illegal_paramete= r" > > was correct, then overflow_error, decrypt_error and probably few > > others > > would also need to be replaced with illegal_parameter... > =20 > I think the rigorousness of error codes is not at the same level as the r= est > of the document. I'm fine with that. I can understand why people > developing test suites are frustrated.=20 It's not about developing test suites. It's about software the test suites = are=20 running against. Inconsistent behaviour is usually a sign of a bug (I already had to deal wi= th=20 two security bugs, including one remote crash, that were/could have been fo= und=20 by verifying the sending of alerts and description of alerts), if not a=20 security issue by itself (see ROBOT). To reiterate: I'm not doing it because it brings me perverse pleasure or=20 because I'm obsessive about details or because it makes writing test suites= =20 easier (it doesn't, that's why first tests I was writing didn't do that), I= =20 insist on specific, explicit and correct error handling _because it finds bugs_=20 And I think we can all agree that a secure implementation of TLS needs not = to=20 have bugs. And we all primarily want to see such implementations, don't we? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2808641.ccO3BPbT5W Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltDRpsACgkQkqjRuAHS 9fVWBg/+KxN4mskTjcZeVA2PLLyUPfPCu4a7dyksaTar9FPde5RSwCxcyGCn0zUh Fg4q4mWGeowY+EG5USoA44X9j7CXZKFu3un1hXMfBzvsiXLblc61MunyrXqCMlMu sHpEUijGhKClQGIvGX6xBqBnf49vC2UiHI2u8zcgNR59+yWp+42Ip76KIHhNQ26u Re7HACh/kjJa5yemcN+LOjCPEYoMeYwxZlKo5mwcQTSmfZhooeGrSEHO/47ShZ7S g8taTmxcx8Px5zdP9eT5/LVlHwdJHb4uBYbbjxisAsnoGCd3fxE3yKS4rPgGxkcz cBWd/jdIiG0VoymRWBLpLi97VepULobkNOjyYahCBW0vql3QDYjtfVYSiUbXQJSp MNlProv6U/uWi16FlCD+iDb9XvNdbKxB82AlAVdcivf9FRCYKqBU94/E8tjtZl1L sBOL4YhGdLyUiGeQIop/zNMAC5h2QyXWLAAoVBlu0kk6+wx9kttisjvWji7tX4Go TA6x/W2Fjf94Y52wjk3qFjd6Nb3lN9bieRvYgNwb4+vrginhOgxxFgJo0z0Pf6CX +sHIlMRyFyV3NLChQrAdp1lSWJKQky0WDa+sPhkeFw6phegiVsXFdUuoYylYGpmS gsM/JzCh7xo4ozjbpmlxKj4JnVkjrwq3GPz9OxK0MJkPC5FDgqQ= =OjwY -----END PGP SIGNATURE----- --nextPart2808641.ccO3BPbT5W-- From nobody Mon Jul 9 05:19:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEE12130DF2 for ; Mon, 9 Jul 2018 05:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rb-3FkRzlpXt for ; Mon, 9 Jul 2018 05:19:40 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B534130DEF for ; Mon, 9 Jul 2018 05:19:40 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w69CHVJ9012378; Mon, 9 Jul 2018 13:19:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=GBwz02TlDHcbclgyXwMFRCfde4n/qaP8kAQDZ3IQOa0=; b=SJTVpW5XJqYXh8pcCfIrxpFPgrkz4R7DRw67kSSs5tQ0+okS8gNCALLuLpUgtx8TRqYD aB9wzaJqkZz+oQ7QOdUBggq0OPeywA5pBeCPXJ7pCfeX2v/VPjxaeyCf9tS0RoGf0gBE EKkyslPWx5NZMWVL7xkQEnH3Ke1oubTyfzOpOuY4mvgUcsN/ildzyLSzDU5AvE8id9OM LSHT/r+koWtnfcQyENM9hCMcj5QPwSmwP86Pjd1FtV+MoHt3Ci47QpOEgv2nDDYFQVWf TSF3d/zawfENcaoVJud77lHaJGom7IhrbZW5VMRkibB3gD8xM894ME1TSPv/1Yhhywde qg== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2k2pbnnw92-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Jul 2018 13:19:39 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w69C5VJ9008813; Mon, 9 Jul 2018 08:19:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.27.25]) by prod-mail-ppoint3.akamai.com with ESMTP id 2k2ruvp2m0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Jul 2018 08:19:31 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 9 Jul 2018 07:18:41 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1365.000; Mon, 9 Jul 2018 07:18:41 -0500 From: "Salz, Rich" To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR+97sAgAAKB4CAAASogIAABO2AgAAHUoCAAG4mgIAAvPsAgAbW0YD//9NTgA== Date: Mon, 9 Jul 2018 12:18:40 +0000 Message-ID: <13647E58-59A9-4174-BF74-7B00E00E8EAF@akamai.com> References: <1530687136897.97792@cs.auckland.ac.nz> <1530757910178.45400@cs.auckland.ac.nz> <8417187.FtxZZQNsAt@pintsize.usersys.redhat.com> In-Reply-To: <8417187.FtxZZQNsAt@pintsize.usersys.redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.133] Content-Type: text/plain; charset="utf-8" Content-ID: <827B19FEF05E804D89767475DC848AA3@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-09_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=931 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807090140 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-09_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=847 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807090141 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 12:19:42 -0000 PiAgICBUaGVyZSBJcyBObyBTdWNoIFRoaW5nIEFzIEEgVHJ1c3RlZCBOZXR3b3JrDQogIA0KVGhh dCdzIGEgZ3JlYXQgYXBob3Jpc20sIGFuZCB3ZSd2ZSBhbGwgbWFkZSBsb3RzIG9mIHByb2dyZXNz IGluIHdvcmtpbmcgd2l0aCB0aGF0IGFzc3VtcHRpb24sIGJ1dCB0aGVyZSBhcmUgaW1wb3J0YW50 IGNhc2VzIHdoZXJlIGl0IGlzIG5vdCB0cnVlLiAgQW5kIEkgdGhpbmsgUGV0ZXIgd29ya3MgaW4g bWFueSBvZiB0aG9zZSBjYXNlcy4NCg0KDQo= From nobody Mon Jul 9 06:46:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A2C130FDC for ; Mon, 9 Jul 2018 06:46:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l4J9hAhLB36Z for ; Mon, 9 Jul 2018 06:46:27 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7A825130FD6 for ; Mon, 9 Jul 2018 06:46:27 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id w69DkPZR030310; Mon, 9 Jul 2018 09:46:25 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Salz, Rich" CC: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR+5vgAgAAKBoCAAASogIAABO6AgAAHUoCAAG4lgIAAvPsAgAbW0YCAABZiAIAAGIKA Date: Mon, 9 Jul 2018 13:46:24 +0000 Message-ID: References: <1530687136897.97792@cs.auckland.ac.nz> <1530757910178.45400@cs.auckland.ac.nz> <8417187.FtxZZQNsAt@pintsize.usersys.redhat.com> <13647E58-59A9-4174-BF74-7B00E00E8EAF@akamai.com> In-Reply-To: <13647E58-59A9-4174-BF74-7B00E00E8EAF@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-D2DB7A35-CCDF-40A6-B8FD-D5C19C38331B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-09_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807090158 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 13:46:29 -0000 --Apple-Mail-D2DB7A35-CCDF-40A6-B8FD-D5C19C38331B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable +1 to Rich and Peter. Regards, Uri Sent from my iPhone On Jul 9, 2018, at 08:20, Salz, Rich w= rote: >> There Is No Such Thing As A Trusted Network >=20 > That's a great aphorism, and we've all made lots of progress in working wi= th that assumption, but there are important cases where it is not true. And= I think Peter works in many of those cases. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-D2DB7A35-CCDF-40A6-B8FD-D5C19C38331B Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTgwNzA5MTM0NjIzWjAjBgkqhkiG9w0BCQQxFgQUcoLHmsBYvVZwFvsUu9DToaTc6k8wbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBADcPwB4BizMhNGFU3qtBgNHy4zHV4p5T7b0Ixre/Xxl+DFzV5dkMhTh924A+vCFC VUWZmA/d4xFvuXiFTMOsN2PtIm35ShitHkIE0Td1W14ClN710t+pL7XJi6s2rygf/flle3I0JPjO 3l0jvydEQYnJ9Y8jmqYEJVmlOv03XB4bXDYO6uBqd+2IFCRVlIDBddl+DiDthZGMWbHHVOKrkqEr h5un8GCXZoRQgoWs1jhOATi6fLZOeDsplvYRN/PV+uOg0Hmy+WJ1ycRZfmwFFj2FFut3GnGl2Ogq 2EUlwwI09kaNcPe8tNWiKEf9DYhNSCrIzvTe0lD3BGZ9Q7q6VigAAAAAAAA= --Apple-Mail-D2DB7A35-CCDF-40A6-B8FD-D5C19C38331B-- From nobody Mon Jul 9 09:41:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8AA131063 for ; Mon, 9 Jul 2018 09:41:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gYEF6-xaCshV for ; Mon, 9 Jul 2018 09:41:35 -0700 (PDT) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A43913101E for ; Mon, 9 Jul 2018 09:41:35 -0700 (PDT) Received: by mail-oi0-x241.google.com with SMTP id k81-v6so37074204oib.4 for ; Mon, 09 Jul 2018 09:41:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=IzjRbFX0CEAtVpjOD4ITGmClGVfLYYMkH4o7Dz6SaFI=; b=KTZXfhOqSZQ4kNZvy/MXAQ0aScZStgbgH3y44wwEdBKUefRilNe/pCd1Bp7BqveWoB 9yJPJAK8VA84rdeAF5EqyjNmTCQey0R4cIlP1bdiV1WrQTAcRu6MKNtkN9HyIbdrfzCQ eyOlRT0qTH8KMyXTX0sXe1ODDuWso/v318SShHQsGFibO3cqjuGYZH8GhRR0pR7hmZ/m QkF7Xkv+FVXowV6ru0KWvNmLH+uDqGo7nPbjZwl6zy220w9+B7/Su+txPmfhiWR9/5/H FYW7ARrsQNC9KqtxLkcn/xJx58ztOPhZEXJIQjBgpZGKQsGY7EAR3ZJOOaI/1DhfyVFF 5y/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=IzjRbFX0CEAtVpjOD4ITGmClGVfLYYMkH4o7Dz6SaFI=; b=o38sArOHFWHhl27R1h/p3MCv5a3jNxkMf0d+Mi986/MLWZCkPLth8BQwUNRkVv9s+A C6+wXskedmP6LnOtNQwI0Q/E0qlJyHWU/GsIeR84uTdiNL54GEo/5vwIlXBVinDoar7F VO2bYWF7Kp/QjKezv/j5waiv3hTlpY1yEewHx31TDTCwESqgOSidGAkYoq1VF30+g8fc Hr25EhdZUeigJxspIfvoBF119GdZ3/iehBBrPZDxGiu138vcPEBCgHhc89stjQBQDVBP WWlYqk1jdNFrfLtysgNiWHrtOEsw5O2KsKjL5rdWiRBBBZq2CMdeDYen950QjYuK9gtz Oqng== X-Gm-Message-State: APt69E3+kKTBZiWIiEVNO8f7WFqP143O33WJVJjVuSmPr7JYwXJdYFFa tx5SeiLRZiDuKwvZmy3PB7LuGt+0jvx6ZnkufVMCuw== X-Google-Smtp-Source: AAOMgpeafofofKlsNqRtauGTRNTbsD29YsXbcfKoKPzIUwjrMustxyyA4bbQWR/XYLhK/6cMWBfSq3tIk3Pd/OGEFRg= X-Received: by 2002:aca:e082:: with SMTP id x124-v6mr21698383oig.220.1531154494593; Mon, 09 Jul 2018 09:41:34 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac9:7ad0:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 09:40:54 -0700 (PDT) In-Reply-To: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> From: Kathleen Moriarty Date: Mon, 9 Jul 2018 12:40:54 -0400 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 16:41:44 -0000 Hello, Stephen and I posted the draft below to see if the TLS working group is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has been a recent drop off in usage for web applications due to the PCI Council recommendation to move off TLSv1.0, with a recommendation to go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 as a baseline. Applications other than those using HTTP may not have had the same reduction in usage. If you are responsible for services where you have a reasonable vantage point to gather and share statistics to assess usage further, that could be helpful for the discussion. We've received some feedback that has been incorporated into the working draft and feelers in general have been positive. It would be good to know if there are any show stoppers that have not been considered. https://github.com/sftcd/tls-oldversions-diediedie Thanks in advance, Kathleen ---------- Forwarded message ---------- From: Date: Mon, Jun 18, 2018 at 3:05 PM Subject: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt To: Stephen Farrell , Kathleen Moriarty A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt has been successfully submitted by Stephen Farrell and posted to the IETF repository. Name: draft-moriarty-tls-oldversions-diediedie Revision: 00 Title: Deprecating TLSv1.0 and TLSv1.1 Document date: 2018-06-18 Group: Individual Submission Pages: 10 URL: https://www.ietf.org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt Status: https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/ Htmlized: https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie Abstract: This document [if approved] formally deprecates Transport Layer Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves these documents to the historic state. These versions lack support for current and recommended cipher suites, and various government and industry profiiles of applications using TLS now mandate avoiding these old TLS versions. TLSv1.2 has been the recommended version for IETF protocols since 2008, providing sufficient time to transition away from older versions. Products having to support older versions increase the attack surface unnecessarily and increase opportunities for misconfigurations. Supporting these older versions also requires additional effort for library and product maintenance. This document updates the backward compatibility sections of TLS RFCs [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This document also updates RFC 7525. 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 -- Best regards, Kathleen From nobody Mon Jul 9 09:55:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A218B131026 for ; Mon, 9 Jul 2018 09:55:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGlcW_KNc321 for ; Mon, 9 Jul 2018 09:55:24 -0700 (PDT) Received: from mail-yw0-x243.google.com (mail-yw0-x243.google.com [IPv6:2607:f8b0:4002:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B60BA130E88 for ; Mon, 9 Jul 2018 09:55:24 -0700 (PDT) Received: by mail-yw0-x243.google.com with SMTP id p129-v6so6778864ywg.7 for ; Mon, 09 Jul 2018 09:55:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+tDsW5ON2klEXgl4nlC7v8tTeTTy81p9YrlXLJGmk/Q=; b=p0pSY4v5UqI72aj5vqlSn3XYHgsM5trEOniMd891ERnSRqivsTyEswamo3ZNmtooIc b6XS/fNAoppkPSM7RSyTxYcCgX4WS/G2td3cNGqg7wnEy1ajU4GLUREePYUGwcMavcYG vQ8qUNobyMWgvHwLS1mHfDa6o2dvKM0QQ4r0EBB3DupyYD40Ai16eJJIkIS0BPEIPpqs c9nU5Lyc33H7dQ8wSEWv+b+xB++n8USxNR0VjbgXY78LnbmXayQVf62K/OBdkTImKi2a ZNll8A4Q+ETTVk5omd3xMlk5TkSi+l5yhLToDgrLS7w972SnzBj1dFoV6P4BogZyqJlK nAxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+tDsW5ON2klEXgl4nlC7v8tTeTTy81p9YrlXLJGmk/Q=; b=kPCHg4XR+zb/yqwoEDNivLoDrAK8t54wDVBhRbZFGJQEKZ2+vYqdYZdPBzSJYoL5/F rcn3IrHRq6tbuDE/DYVFB7uZH8nsG3fewkwMBBnod8V02R8ayAZ2jxeFuwDdm5vh89WB YZsAnPnRE8Lu5w0jGB62sWEGMqCSI+h0hUULtaktyac67M8dC5Hmfw4OPFZE+rZscFW8 p6n+K43JRgJ/vtlyxI74z7Sc+nmWp3DhjU+G1bBoQvZKmII1SjI8pMkI0XkpOtNKzHP0 CxaU9Kei8/tQBhEuMe74AyM5iY3wBkJbu555DyuERuGUwzj8TjproxvnlvGQK4W6xsYQ wY7A== X-Gm-Message-State: APt69E3fr6u/DVd7YikfdWSlyGghdxc5oBdov4lJ2qK3CocUe4o/0l9a DWvk1hV+SxbbwNfNcKMHj/F1fke4WMbWIv4HTGDbfA== X-Google-Smtp-Source: AAOMgpeAy++h6qedigayzzdHf4fbw6crMcSDU65jNsDx8ztM/NGPcaiChqKJn6BakK2LTJnB+5DxWiAAvy/dxipFGHI= X-Received: by 2002:a81:b642:: with SMTP id h2-v6mr10446784ywk.102.1531155323824; Mon, 09 Jul 2018 09:55:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 09:54:43 -0700 (PDT) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 9 Jul 2018 09:54:43 -0700 Message-ID: To: Kathleen Moriarty Cc: "" Content-Type: multipart/alternative; boundary="0000000000002c563d057093e1c4" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 16:55:28 -0000 --0000000000002c563d057093e1c4 Content-Type: text/plain; charset="UTF-8" Thanks for writing this. I would be in favor of deprecating old versions of TLS prior to 1.2. Firefox Telemetry shows that about 1% of our connections are TLS 1.1 (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. This is probably a higher number than we'd be comfortable turning off immediately, but it is probably worth starting the process. -Ekr On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > Hello, > > Stephen and I posted the draft below to see if the TLS working group > is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has > been a recent drop off in usage for web applications due to the PCI > Council recommendation to move off TLSv1.0, with a recommendation to > go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 > as a baseline. Applications other than those using HTTP may not have > had the same reduction in usage. If you are responsible for services > where you have a reasonable vantage point to gather and share > statistics to assess usage further, that could be helpful for the > discussion. We've received some feedback that has been incorporated > into the working draft and feelers in general have been positive. It > would be good to know if there are any show stoppers that have not > been considered. > > https://github.com/sftcd/tls-oldversions-diediedie > > Thanks in advance, > Kathleen > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jun 18, 2018 at 3:05 PM > Subject: New Version Notification for > draft-moriarty-tls-oldversions-diediedie-00.txt > To: Stephen Farrell , Kathleen Moriarty > > > > > A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt > has been successfully submitted by Stephen Farrell and posted to the > IETF repository. > > Name: draft-moriarty-tls-oldversions-diediedie > Revision: 00 > Title: Deprecating TLSv1.0 and TLSv1.1 > Document date: 2018-06-18 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-moriarty-tls- > oldversions-diediedie-00.txt > Status: > https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/ > Htmlized: > https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moriarty-tls- > oldversions-diediedie > > > Abstract: > This document [if approved] formally deprecates Transport Layer > Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves > these documents to the historic state. These versions lack support > for current and recommended cipher suites, and various government and > industry profiiles of applications using TLS now mandate avoiding > these old TLS versions. TLSv1.2 has been the recommended version for > IETF protocols since 2008, providing sufficient time to transition > away from older versions. Products having to support older versions > increase the attack surface unnecessarily and increase opportunities > for misconfigurations. Supporting these older versions also requires > additional effort for library and product maintenance. > > This document updates the backward compatibility sections of TLS RFCs > [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This > document also updates RFC 7525. > > > > > 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 > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000002c563d057093e1c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for writing this.

I w= ould be in favor of deprecating old versions of TLS prior to 1.2. Firefox T= elemetry shows that about 1% of our connections are TLS 1.1 (on the same da= ta set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.

This is probably a higher number than we'd be comfortable turning= off immediately, but it is probably worth starting the process.
=
-Ekr

On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moria= rty <kathleen.moriarty.ietf@gmail.com> wrote:=
Hello,

Stephen and I posted the draft below to see if the TLS working group
is ready to take steps to deprecate TLSv1.0 and TLSv1.1.=C2=A0 There has been a recent drop off in usage for web applications due to the PCI
Council recommendation to move off TLSv1.0, with a recommendation to
go to TLSv1.2 by June 30th.=C2=A0 NIST has also been recommending TLSv1.2 as a baseline.=C2=A0 Applications other than those using HTTP may not have<= br> had the same reduction in usage.=C2=A0 If you are responsible for services<= br> where you have a reasonable vantage point to gather and share
statistics to assess usage further, that could be helpful for the
discussion.=C2=A0 We've received some feedback that has been incorporat= ed
into the working draft and feelers in general have been positive.=C2=A0 It<= br> would be good to know if there are any show stoppers that have not
been considered.

https://github.com/sftcd/tls-oldversions-died= iedie

Thanks in advance,
Kathleen


---------- Forwarded message ----------
From:=C2=A0 <internet-drafts= @ietf.org>
Date: Mon, Jun 18, 2018 at 3:05 PM
Subject: New Version Notification for
draft-moriarty-tls-oldversions-diediedie-00.txt
To: Stephen Farrell <stephe= n.farrell@cs.tcd.ie>, Kathleen Moriarty
<Kathleen.Moriarty.i= etf@gmail.com>



A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt<= br> has been successfully submitted by Stephen Farrell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-moriarty-tls-oldve= rsions-diediedie
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecating TLSv1.0 and TLSv1.1 Document date:=C2=A0 2018-06-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:
https://www.ietf= .org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.= txt
Status:
https://datatracker.ietf.o= rg/doc/draft-moriarty-tls-oldversions-diediedie/
Htmlized:
https://tools.ietf.org/html/<= wbr>draft-moriarty-tls-oldversions-diediedie-00
Htmlized:
https://datatracker.ie= tf.org/doc/html/draft-moriarty-tls-oldversions-diediedie


Abstract:
=C2=A0 =C2=A0This document [if approved] formally deprecates Transport Laye= r
=C2=A0 =C2=A0Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and mo= ves
=C2=A0 =C2=A0these documents to the historic state.=C2=A0 These versions la= ck support
=C2=A0 =C2=A0for current and recommended cipher suites, and various governm= ent and
=C2=A0 =C2=A0industry profiiles of applications using TLS now mandate avoid= ing
=C2=A0 =C2=A0these old TLS versions.=C2=A0 TLSv1.2 has been the recommended= version for
=C2=A0 =C2=A0IETF protocols since 2008, providing sufficient time to transi= tion
=C2=A0 =C2=A0away from older versions.=C2=A0 Products having to support old= er versions
=C2=A0 =C2=A0increase the attack surface unnecessarily and increase opportu= nities
=C2=A0 =C2=A0for misconfigurations.=C2=A0 Supporting these older versions a= lso requires
=C2=A0 =C2=A0additional effort for library and product maintenance.

=C2=A0 =C2=A0This document updates the backward compatibility sections of T= LS RFCs
=C2=A0 =C2=A0[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.=C2= =A0 This
=C2=A0 =C2=A0document also updates RFC 7525.




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

The IETF Secretariat



--

Best regards,
Kathleen

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

--0000000000002c563d057093e1c4-- From nobody Mon Jul 9 09:58:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 276FA130E88 for ; Mon, 9 Jul 2018 09:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CDstEDZCiAM6 for ; Mon, 9 Jul 2018 09:58:11 -0700 (PDT) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com [IPv6:2607:f8b0:4002:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C138130DCE for ; Mon, 9 Jul 2018 09:58:11 -0700 (PDT) Received: by mail-yb0-x241.google.com with SMTP id y11-v6so7447671ybm.7 for ; Mon, 09 Jul 2018 09:58:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6XQsZ/yKVqpYE7HH6eUi7UefnS75sCe6XzZvKnpsqG0=; b=aa4iAZnGZtye7K5secfk4rvuiLXt5AscjpR99kvyhESgy/6CEb4JFmsVZ2pcRsNkBW stD5u1IjspqoeUidg0leEKtQvNoRvXqC6yTMyGhv5vxz8aDqUyhSQnYO6wAjIxB7Xsd8 Vb2YoupphkLCF1eUf9JTZbDzN5Kty4rLHEyie6/GPBn6yRITyxVLJNrzmC1v+LI+bqqt IeMZxtY3FDUXsMF0G3dFAv28hfyhHYCRc/nHF7tbhqPjja4wuGepmdmJ0TNGlPMuu1pW AQq7AxGTGSNFR3JCS+oOpCpI5/dDIgjHmBQZR7UIjFc65ZxAnYHWoRQnTZCpiVcdPTZU Gn+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6XQsZ/yKVqpYE7HH6eUi7UefnS75sCe6XzZvKnpsqG0=; b=sn3h6LaL9PooNU0Uqw3N/IBBlDf2tdk1Wbi5Xam1sN9VNYl4tf9etgc02uuLcnqxEV NMF/RX/NmmZgTtop8cfXz8s5sFf3lfOX1VXITmtDbp4BCIFxpIr6JJd/dPurbjZ/OZkd m3dESbeBP785tOn70zp2/v7BjBrBY0DWlESGB6+5yTEUglh28Gsnmln39nVkTwhQpwK9 XII3k4vaY9dl8+g4BiGV8X1Qvb9gzOz0SSVVpS2+kebSryXJEAP/f4jje9wW0WxonRGO BUJlgXVH7aMN8jT/N+5+3xbyEpWgmk+vSC5jHZKfDYkU1aq/pTarN9BGd6TPEYX3hK1L luGA== X-Gm-Message-State: APt69E0Axty0uDGJ5kww3/lDMOtm3aiiSGBLuNMCgoz9wmDW265N+q6O +e4aUDzVDQyODzRDAGb6PMJY7JU0dQizuPuOFYbeKA== X-Google-Smtp-Source: AAOMgpd6s8tAiIm7/F0doIKwqn2yHwm4pi+rTA0dqz6GN0V99QPpWHSOdtqmq/oZcWaJ0NjDsV+69qh1wWnshg9qhsM= X-Received: by 2002:a25:adcb:: with SMTP id d11-v6mr11777994ybe.73.1531155489947; Mon, 09 Jul 2018 09:58:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 09:57:29 -0700 (PDT) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> From: Eric Rescorla Date: Mon, 9 Jul 2018 09:57:29 -0700 Message-ID: To: Kathleen Moriarty Cc: "" Content-Type: multipart/alternative; boundary="000000000000131308057093eb39" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 16:58:14 -0000 --000000000000131308057093eb39 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla wrote: > Thanks for writing this. > > I would be in favor of deprecating old versions of TLS prior to 1.2. > Firefox Telemetry shows that about 1% of our connections are TLS 1.1 > This should be 1.0. (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. > > This is probably a higher number than we'd be comfortable turning off > immediately, but it is probably worth starting the process. > > -Ekr > > > On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > >> Hello, >> >> Stephen and I posted the draft below to see if the TLS working group >> is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has >> been a recent drop off in usage for web applications due to the PCI >> Council recommendation to move off TLSv1.0, with a recommendation to >> go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 >> as a baseline. Applications other than those using HTTP may not have >> had the same reduction in usage. If you are responsible for services >> where you have a reasonable vantage point to gather and share >> statistics to assess usage further, that could be helpful for the >> discussion. We've received some feedback that has been incorporated >> into the working draft and feelers in general have been positive. It >> would be good to know if there are any show stoppers that have not >> been considered. >> >> https://github.com/sftcd/tls-oldversions-diediedie >> >> Thanks in advance, >> Kathleen >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Jun 18, 2018 at 3:05 PM >> Subject: New Version Notification for >> draft-moriarty-tls-oldversions-diediedie-00.txt >> To: Stephen Farrell , Kathleen Moriarty >> >> >> >> >> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt >> has been successfully submitted by Stephen Farrell and posted to the >> IETF repository. >> >> Name: draft-moriarty-tls-oldversions-diediedie >> Revision: 00 >> Title: Deprecating TLSv1.0 and TLSv1.1 >> Document date: 2018-06-18 >> Group: Individual Submission >> Pages: 10 >> URL: >> https://www.ietf.org/internet-drafts/draft-moriarty-tls-oldv >> ersions-diediedie-00.txt >> Status: >> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversi >> ons-diediedie/ >> Htmlized: >> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 >> Htmlized: >> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-old >> versions-diediedie >> >> >> Abstract: >> This document [if approved] formally deprecates Transport Layer >> Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves >> these documents to the historic state. These versions lack support >> for current and recommended cipher suites, and various government and >> industry profiiles of applications using TLS now mandate avoiding >> these old TLS versions. TLSv1.2 has been the recommended version for >> IETF protocols since 2008, providing sufficient time to transition >> away from older versions. Products having to support older versions >> increase the attack surface unnecessarily and increase opportunities >> for misconfigurations. Supporting these older versions also requires >> additional effort for library and product maintenance. >> >> This document updates the backward compatibility sections of TLS RFCs >> [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This >> document also updates RFC 7525. >> >> >> >> >> 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 >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --000000000000131308057093eb39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla <ekr@rtfm.com> = wrote:
Thanks for w= riting this.

I would be in favor of deprecating ol= d versions of TLS prior to 1.2. Firefox Telemetry shows that about 1% of ou= r connections are TLS 1.1

This = should be 1.0.


(on the same data set, TLS 1.3 is > 5%), a= nd TLS 1.1 is negligible.

This is probably a highe= r number than we'd be comfortable turning off immediately, but it is pr= obably worth starting the process.

-Ekr
=

On Mon, Jul 9, 2018 at 9:40 AM, Kath= leen Moriarty <kathleen.moriarty.ietf@gmail.com>= ; wrote:
Hello,

Stephen and I posted the draft below to see if the TLS working group
is ready to take steps to deprecate TLSv1.0 and TLSv1.1.=C2=A0 There has been a recent drop off in usage for web applications due to the PCI
Council recommendation to move off TLSv1.0, with a recommendation to
go to TLSv1.2 by June 30th.=C2=A0 NIST has also been recommending TLSv1.2 as a baseline.=C2=A0 Applications other than those using HTTP may not have<= br> had the same reduction in usage.=C2=A0 If you are responsible for services<= br> where you have a reasonable vantage point to gather and share
statistics to assess usage further, that could be helpful for the
discussion.=C2=A0 We've received some feedback that has been incorporat= ed
into the working draft and feelers in general have been positive.=C2=A0 It<= br> would be good to know if there are any show stoppers that have not
been considered.

https://github.com/sftcd/tls-oldversions-died= iedie

Thanks in advance,
Kathleen


---------- Forwarded message ----------
From:=C2=A0 <internet-drafts@ietf.org>
Date: Mon, Jun 18, 2018 at 3:05 PM
Subject: New Version Notification for
draft-moriarty-tls-oldversions-diediedie-00.txt
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Kathleen Moriarty
<K= athleen.Moriarty.ietf@gmail.com>



A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt<= br> has been successfully submitted by Stephen Farrell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-moriarty-tls-oldversion= s-diediedie
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecating TLSv1.0 and TLSv1.1 Document date:=C2=A0 2018-06-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:
https://www.ietf= .org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.= txt
Status:
https://datatracker.ietf.o= rg/doc/draft-moriarty-tls-oldversions-diediedie/
Htmlized:
https://tools.ietf.org/html/d= raft-moriarty-tls-oldversions-diediedie-00
Htmlized:
https://datatracker.ie= tf.org/doc/html/draft-moriarty-tls-oldversions-diediedie


Abstract:
=C2=A0 =C2=A0This document [if approved] formally deprecates Transport Laye= r
=C2=A0 =C2=A0Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and mo= ves
=C2=A0 =C2=A0these documents to the historic state.=C2=A0 These versions la= ck support
=C2=A0 =C2=A0for current and recommended cipher suites, and various governm= ent and
=C2=A0 =C2=A0industry profiiles of applications using TLS now mandate avoid= ing
=C2=A0 =C2=A0these old TLS versions.=C2=A0 TLSv1.2 has been the recommended= version for
=C2=A0 =C2=A0IETF protocols since 2008, providing sufficient time to transi= tion
=C2=A0 =C2=A0away from older versions.=C2=A0 Products having to support old= er versions
=C2=A0 =C2=A0increase the attack surface unnecessarily and increase opportu= nities
=C2=A0 =C2=A0for misconfigurations.=C2=A0 Supporting these older versions a= lso requires
=C2=A0 =C2=A0additional effort for library and product maintenance.

=C2=A0 =C2=A0This document updates the backward compatibility sections of T= LS RFCs
=C2=A0 =C2=A0[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.=C2= =A0 This
=C2=A0 =C2=A0document also updates RFC 7525.




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

The IETF Secretariat



--

Best regards,
Kathleen

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


--000000000000131308057093eb39-- From nobody Mon Jul 9 11:00:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B1CC130E5C for ; Mon, 9 Jul 2018 11:00:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.101 X-Spam-Level: * X-Spam-Status: No, score=1.101 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_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CAebIZ4m1G-P for ; Mon, 9 Jul 2018 11:00:18 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0091.outbound.protection.outlook.com [104.47.38.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C56612F1AC for ; Mon, 9 Jul 2018 11:00:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DD++c7xVoMJrSyHZSa1yuN8hu+ZRjDiCOEMmRm3pH6Y=; b=neaoCorm9vYhF8dp5W4eI6AFPl/OFR4EgYC5wF3S5tWJNDseerlURA1StmXRcFvCKiKHMiOROYs+YIg3Fp5CcWZglt9UD8DKwo7Ui6lbmE7LCxGnW3oIHZoeyW/OwN4FRI2Bcddq9jCG0SNbWDYBVMMNatLyBKr4vnGNseHSv84= Received: from CY4PR21MB0774.namprd21.prod.outlook.com (10.173.192.20) by CY4PR21MB0279.namprd21.prod.outlook.com (10.173.193.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.4; Mon, 9 Jul 2018 18:00:16 +0000 Received: from CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b]) by CY4PR21MB0774.namprd21.prod.outlook.com ([fe80::9d01:113b:290a:750b%3]) with mapi id 15.20.0952.013; Mon, 9 Jul 2018 18:00:16 +0000 From: Andrei Popov To: Eric Rescorla , Kathleen Moriarty CC: "" Thread-Topic: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt Thread-Index: AQHUF6PJpStkJhSBckq3e+cc3FSKFaSHG8mAgAAAxoCAAAqYYA== Date: Mon, 9 Jul 2018 18:00:16 +0000 Message-ID: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:3:28ba:a023:971b:e42c] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0279; 7:oPQxsoiY64KiHseq7LDTKTVRjeiUXvrbwo+YboYWzT46JOpXWjS2HwxDQhXQ8xjfd1vM5fgXcGo2V3l50ZndZwMbTWP52AurXXqJySMWY6YbwNEU5VQxq/PaeiSqaPg2AaiBQD6iiEOnRGc8pDuJunMDsilBGqYM25gjNTghOCegojiiVEbAXGnHsZIc8PtLAgq06gGX7lwB4q3vr8kQTFri4tpBEE7MtxQsK/RxlJS4tYIBgu3RXbo3IoK7zD4y x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f4192fc6-00a1-424d-03ac-08d5e5c5d374 x-microsoft-antispam: UriScan:(32856632585715); BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(48565401081)(5600053)(711020)(2017052603328)(7193020); SRVR:CY4PR21MB0279; x-ms-traffictypediagnostic: CY4PR21MB0279: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(32856632585715)(158342451672863)(278428928389397)(120809045254105)(166708455590820)(192374486261705)(189930954265078)(85827821059158)(219752817060721); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(944501410)(52105095)(2018427008)(10201501046)(93006095)(93001095)(6055026)(149027)(150027)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:CY4PR21MB0279; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0279; x-forefront-prvs: 07283408BE x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(376002)(346002)(396003)(136003)(39860400002)(22974007)(51874003)(189003)(199004)(7696005)(6436002)(33656002)(97736004)(5660300001)(10090500001)(7110500001)(476003)(46003)(446003)(186003)(486006)(53936002)(2900100001)(11346002)(14971765001)(229853002)(8990500004)(110136005)(86612001)(22452003)(256004)(2906002)(14444005)(76176011)(99286004)(316002)(102836004)(6506007)(53546011)(86362001)(478600001)(7736002)(19609705001)(81166006)(81156014)(10710500007)(106356001)(105586002)(54896002)(5250100002)(6306002)(9686003)(39060400002)(236005)(14454004)(10290500003)(72206003)(55016002)(966005)(25786009)(4326008)(6116002)(790700001)(68736007)(8936002)(74316002)(6246003)(606006)(8676002)(2420400007)(15650500001)(93886005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0279; H:CY4PR21MB0774.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: pQG/n3Z2l4TCu05SkuWX3kkMvAKeBoPxa12CdMvUCa+9vUjaOaeQqnJ5CGXG69LFMsbOEl6fdgNoRvwQ/CTW1qjHRr4Cmv7DSxLODf1P4luA8/V120Ppj3Vfj0lQWag5QtkgRlHVzPW3qQcJn8kJfKt7RgHwn4Ep3bvTz/VTjfPnRpCeYKGDrIub0cfLPLzDx/ZzlkHTApLJ9w4w3u3jqw5GhnCbg3ZZ11vTwqUR1AsSB+w6KgYpbkpsCxs+AM7ZO4EhQvRBgUCotPZkPjlh9ONd77jB5RIsLDGorlJislZrxCg/VHd8TYyYujijuNVSd9ZW5i+2D2eDrs8mZrFwe7+L4lPG6e8IpnH/jt52Q18= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB0774BE80A4424D41D0C8C4138C440CY4PR21MB0774namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: f4192fc6-00a1-424d-03ac-08d5e5c5d374 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jul 2018 18:00:16.0555 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0279 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 18:00:23 -0000 --_000_CY4PR21MB0774BE80A4424D41D0C8C4138C440CY4PR21MB0774namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gdGhlIHJlY2VudCBXaW5kb3dzIHZlcnNpb25zLCBUTFMgMS4wIGlzIG5lZ290aWF0ZWQgbW9y ZSB0aGFuIDEwJSBvZiB0aGUgdGltZSBvbiB0aGUgY2xpZW50IHNpZGUgKHRoaXMgaW5jbHVkZXMg bm9uLWJyb3dzZXIgY29ubmVjdGlvbnMgZnJvbSBhbGwgc29ydHMgb2YgYXBwcywgc29tZSBoYXJk LWNvZGluZyBUTFMgdmVyc2lvbnMpLCBhbmQgVExTIDEuMSBhY2NvdW50cyBmb3IgfjAuMyUgb2Yg Y2xpZW50IGNvbm5lY3Rpb25zLg0KV2luZG93cyBzZXJ2ZXIgbmVnb3RpYXRlcyBUTFMgMS4wIH4x LjUlIG9mIHRoZSB0aW1lIChhbGwgc2VydmVyIGFwcHMsIG5vdCBqdXN0IElJUyksIGFuZCB0aGUg dXNlIG9mIFRMUyAxLjEgaXMgbmVnbGlnaWJsZS4NCg0KVGhlcmVmb3JlLCB3ZSBjYW5ub3QgZGlz YWJsZSBUTFMgMS4wIGJ5IGRlZmF1bHQgaW4gV2luZG93cyBqdXN0IHlldCwgYnV0IHdpbGwga2Vl cCBsb29raW5nIGF0IHRoZSB0ZWxlbWV0cnkuIElmIFBDSS9OSVNUL2RpZWRpZWRpZSBSRkMgbWFr ZSBhIGRpZmZlcmVuY2UsIEnigJlsbCBiZSBoYXBweSB0byByZWR1Y2UgdGhlIHNldCBvZiBlbmFi bGVkLWJ5LWRlZmF1bHQgVExTIHZlcnNpb25zLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9t OiBUTFMgPHRscy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0K U2VudDogTW9uZGF5LCBKdWx5IDksIDIwMTggOTo1NyBBTQ0KVG86IEthdGhsZWVuIE1vcmlhcnR5 IDxrYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbT4NCkNjOiA8dGxzQGlldGYub3JnPiA8 dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIEZ3ZDogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1tb3JpYXJ0eS10bHMtb2xkdmVyc2lvbnMtZGllZGllZGllLTAwLnR4 dA0KDQoNCg0KT24gTW9uLCBKdWwgOSwgMjAxOCBhdCA5OjU0IEFNLCBFcmljIFJlc2NvcmxhIDxl a3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciB3cml0 aW5nIHRoaXMuDQoNCkkgd291bGQgYmUgaW4gZmF2b3Igb2YgZGVwcmVjYXRpbmcgb2xkIHZlcnNp b25zIG9mIFRMUyBwcmlvciB0byAxLjIuIEZpcmVmb3ggVGVsZW1ldHJ5IHNob3dzIHRoYXQgYWJv dXQgMSUgb2Ygb3VyIGNvbm5lY3Rpb25zIGFyZSBUTFMgMS4xDQoNClRoaXMgc2hvdWxkIGJlIDEu MC4NCg0KDQoob24gdGhlIHNhbWUgZGF0YSBzZXQsIFRMUyAxLjMgaXMgPiA1JSksIGFuZCBUTFMg MS4xIGlzIG5lZ2xpZ2libGUuDQoNClRoaXMgaXMgcHJvYmFibHkgYSBoaWdoZXIgbnVtYmVyIHRo YW4gd2UnZCBiZSBjb21mb3J0YWJsZSB0dXJuaW5nIG9mZiBpbW1lZGlhdGVseSwgYnV0IGl0IGlz IHByb2JhYmx5IHdvcnRoIHN0YXJ0aW5nIHRoZSBwcm9jZXNzLg0KDQotRWtyDQoNCg0KT24gTW9u LCBKdWwgOSwgMjAxOCBhdCA5OjQwIEFNLCBLYXRobGVlbiBNb3JpYXJ0eSA8a2F0aGxlZW4ubW9y aWFydHkuaWV0ZkBnbWFpbC5jb208bWFpbHRvOmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwu Y29tPj4gd3JvdGU6DQoNCkhlbGxvLA0KDQpTdGVwaGVuIGFuZCBJIHBvc3RlZCB0aGUgZHJhZnQg YmVsb3cgdG8gc2VlIGlmIHRoZSBUTFMgd29ya2luZyBncm91cA0KaXMgcmVhZHkgdG8gdGFrZSBz dGVwcyB0byBkZXByZWNhdGUgVExTdjEuMCBhbmQgVExTdjEuMS4gIFRoZXJlIGhhcw0KYmVlbiBh IHJlY2VudCBkcm9wIG9mZiBpbiB1c2FnZSBmb3Igd2ViIGFwcGxpY2F0aW9ucyBkdWUgdG8gdGhl IFBDSQ0KQ291bmNpbCByZWNvbW1lbmRhdGlvbiB0byBtb3ZlIG9mZiBUTFN2MS4wLCB3aXRoIGEg cmVjb21tZW5kYXRpb24gdG8NCmdvIHRvIFRMU3YxLjIgYnkgSnVuZSAzMHRoLiAgTklTVCBoYXMg YWxzbyBiZWVuIHJlY29tbWVuZGluZyBUTFN2MS4yDQphcyBhIGJhc2VsaW5lLiAgQXBwbGljYXRp b25zIG90aGVyIHRoYW4gdGhvc2UgdXNpbmcgSFRUUCBtYXkgbm90IGhhdmUNCmhhZCB0aGUgc2Ft ZSByZWR1Y3Rpb24gaW4gdXNhZ2UuICBJZiB5b3UgYXJlIHJlc3BvbnNpYmxlIGZvciBzZXJ2aWNl cw0Kd2hlcmUgeW91IGhhdmUgYSByZWFzb25hYmxlIHZhbnRhZ2UgcG9pbnQgdG8gZ2F0aGVyIGFu ZCBzaGFyZQ0Kc3RhdGlzdGljcyB0byBhc3Nlc3MgdXNhZ2UgZnVydGhlciwgdGhhdCBjb3VsZCBi ZSBoZWxwZnVsIGZvciB0aGUNCmRpc2N1c3Npb24uICBXZSd2ZSByZWNlaXZlZCBzb21lIGZlZWRi YWNrIHRoYXQgaGFzIGJlZW4gaW5jb3Jwb3JhdGVkDQppbnRvIHRoZSB3b3JraW5nIGRyYWZ0IGFu ZCBmZWVsZXJzIGluIGdlbmVyYWwgaGF2ZSBiZWVuIHBvc2l0aXZlLiAgSXQNCndvdWxkIGJlIGdv b2QgdG8ga25vdyBpZiB0aGVyZSBhcmUgYW55IHNob3cgc3RvcHBlcnMgdGhhdCBoYXZlIG5vdA0K YmVlbiBjb25zaWRlcmVkLg0KDQpodHRwczovL2dpdGh1Yi5jb20vc2Z0Y2QvdGxzLW9sZHZlcnNp b25zLWRpZWRpZWRpZTxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZzZnRjZCUyRnRscy1vbGR2ZXJzaW9u cy1kaWVkaWVkaWUmZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3 QzMwYjdjZmQ2YzExMTQwOWY0NDJiMDhkNWU1YmQzNzc3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY2NzUyMzIxNTAwMTUxNCZzZGF0YT02SlNRWmU5M25X bkFFTHZPZ0czS3lJY1BvcFFsZU1EdE5GNnY4TFdGWFdVJTNEJnJlc2VydmVkPTA+DQoNClRoYW5r cyBpbiBhZHZhbmNlLA0KS2F0aGxlZW4NCg0KDQotLS0tLS0tLS0tIEZvcndhcmRlZCBtZXNzYWdl IC0tLS0tLS0tLS0NCkZyb206ICA8aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uLCBKdW4gMTgsIDIwMTggYXQgMzowNSBQ TQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvcg0KZHJhZnQtbW9yaWFydHkt dGxzLW9sZHZlcnNpb25zLWRpZWRpZWRpZS0wMC50eHQNClRvOiBTdGVwaGVuIEZhcnJlbGwgPHN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8bWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+ PiwgS2F0aGxlZW4gTW9yaWFydHkNCjxLYXRobGVlbi5Nb3JpYXJ0eS5pZXRmQGdtYWlsLmNvbTxt YWlsdG86S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+Pg0KDQoNCg0KQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LW1vcmlhcnR5LXRscy1vbGR2ZXJzaW9ucy1kaWVkaWVkaWUtMDAu dHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFN0ZXBoZW4gRmFycmVsbCBh bmQgcG9zdGVkIHRvIHRoZQ0KSUVURiByZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJh ZnQtbW9yaWFydHktdGxzLW9sZHZlcnNpb25zLWRpZWRpZWRpZQ0KUmV2aXNpb246ICAgICAgIDAw DQpUaXRsZTogICAgICAgICAgRGVwcmVjYXRpbmcgVExTdjEuMCBhbmQgVExTdjEuMQ0KRG9jdW1l bnQgZGF0ZTogIDIwMTgtMDYtMTgNCkdyb3VwOiAgICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Np b24NClBhZ2VzOiAgICAgICAgICAxMA0KVVJMOg0KaHR0cHM6Ly93d3cuaWV0Zi4ub3JnL2ludGVy bmV0LWRyYWZ0cy9kcmFmdC1tb3JpYXJ0eS10bHMtb2xkdmVyc2lvbnMtZGllZGllZGllLTAwLnR4 dDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRnd3dy5pZXRmLm9yZyUyRmludGVybmV0LWRyYWZ0cyUyRmRyYWZ0LW1vcmlhcnR5 LXRscy1vbGR2ZXJzaW9ucy1kaWVkaWVkaWUtMDAudHh0JmRhdGE9MDIlN0MwMSU3Q0FuZHJlaS5Q b3BvdiU0MG1pY3Jvc29mdC5jb20lN0MzMGI3Y2ZkNmMxMTE0MDlmNDQyYjA4ZDVlNWJkMzc3NyU3 QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2Njc1MjMyMTUw MTE1MTgmc2RhdGE9JTJCQlJHbU1iZjdyNG1Yb3lXcUhtVDZrZ05qSHc3RHJoN2xkRGNlRzVncWZR JTNEJnJlc2VydmVkPTA+DQpTdGF0dXM6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv Yy9kcmFmdC1tb3JpYXJ0eS10bHMtb2xkdmVyc2lvbnMtZGllZGllZGllLzxodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmRhdGF0 cmFja2VyLmlldGYub3JnJTJGZG9jJTJGZHJhZnQtbW9yaWFydHktdGxzLW9sZHZlcnNpb25zLWRp ZWRpZWRpZSUyRiZkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdD MzBiN2NmZDZjMTExNDA5ZjQ0MmIwOGQ1ZTViZDM3NzclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJk N2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjY3NTIzMjE1MDExNTE4JnNkYXRhPVFnZTJudmN4OGZ6 MTA1VXV4MXJsMWVNMnlIaUk3emJ2eEE4UHZwczEwejglM0QmcmVzZXJ2ZWQ9MD4NCkh0bWxpemVk Og0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vcmlhcnR5LXRscy1vbGR2ZXJz aW9ucy1kaWVkaWVkaWUtMDA8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZkcmFmdC1t b3JpYXJ0eS10bHMtb2xkdmVyc2lvbnMtZGllZGllZGllLTAwJmRhdGE9MDIlN0MwMSU3Q0FuZHJl aS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN0MzMGI3Y2ZkNmMxMTE0MDlmNDQyYjA4ZDVlNWJkMzc3 NyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2Njc1MjMy MTUwMjE1MzUmc2RhdGE9Qno2RnJ2dmlQb1NJeGtCODNib0d4Y094VmcyTnZycVMzQTFiVWluTm9k YyUzRCZyZXNlcnZlZD0wPg0KSHRtbGl6ZWQ6DQpodHRwczovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9odG1sL2RyYWZ0LW1vcmlhcnR5LXRscy1vbGR2ZXJzaW9ucy1kaWVkaWVkaWU8aHR0cHM6 Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYl MkZkYXRhdHJhY2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1tb3JpYXJ0eS10bHMt b2xkdmVyc2lvbnMtZGllZGllZGllJmRhdGE9MDIlN0MwMSU3Q0FuZHJlaS5Qb3BvdiU0MG1pY3Jv c29mdC5jb20lN0MzMGI3Y2ZkNmMxMTE0MDlmNDQyYjA4ZDVlNWJkMzc3NyU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2Njc1MjMyMTUwMjE1MzUmc2RhdGE9 TTFPNDh5UFRQa2QlMkJiMyUyRkUzejAlMkZBbmlCVU1vekR3ZlF6cDJSYTVzTFJiUSUzRCZyZXNl cnZlZD0wPg0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBbaWYgYXBwcm92ZWRdIGZv cm1hbGx5IGRlcHJlY2F0ZXMgVHJhbnNwb3J0IExheWVyDQogICBTZWN1cml0eSAoVExTKSB2ZXJz aW9ucyAxLjAgW1JGQzIyNDZdIGFuZCAxLjEgW1JGQzQzNDZdIGFuZCBtb3Zlcw0KICAgdGhlc2Ug ZG9jdW1lbnRzIHRvIHRoZSBoaXN0b3JpYyBzdGF0ZS4gIFRoZXNlIHZlcnNpb25zIGxhY2sgc3Vw cG9ydA0KICAgZm9yIGN1cnJlbnQgYW5kIHJlY29tbWVuZGVkIGNpcGhlciBzdWl0ZXMsIGFuZCB2 YXJpb3VzIGdvdmVybm1lbnQgYW5kDQogICBpbmR1c3RyeSBwcm9maWlsZXMgb2YgYXBwbGljYXRp b25zIHVzaW5nIFRMUyBub3cgbWFuZGF0ZSBhdm9pZGluZw0KICAgdGhlc2Ugb2xkIFRMUyB2ZXJz aW9ucy4gIFRMU3YxLjIgaGFzIGJlZW4gdGhlIHJlY29tbWVuZGVkIHZlcnNpb24gZm9yDQogICBJ RVRGIHByb3RvY29scyBzaW5jZSAyMDA4LCBwcm92aWRpbmcgc3VmZmljaWVudCB0aW1lIHRvIHRy YW5zaXRpb24NCiAgIGF3YXkgZnJvbSBvbGRlciB2ZXJzaW9ucy4gIFByb2R1Y3RzIGhhdmluZyB0 byBzdXBwb3J0IG9sZGVyIHZlcnNpb25zDQogICBpbmNyZWFzZSB0aGUgYXR0YWNrIHN1cmZhY2Ug dW5uZWNlc3NhcmlseSBhbmQgaW5jcmVhc2Ugb3Bwb3J0dW5pdGllcw0KICAgZm9yIG1pc2NvbmZp Z3VyYXRpb25zLiAgU3VwcG9ydGluZyB0aGVzZSBvbGRlciB2ZXJzaW9ucyBhbHNvIHJlcXVpcmVz DQogICBhZGRpdGlvbmFsIGVmZm9ydCBmb3IgbGlicmFyeSBhbmQgcHJvZHVjdCBtYWludGVuYW5j ZS4NCg0KICAgVGhpcyBkb2N1bWVudCB1cGRhdGVzIHRoZSBiYWNrd2FyZCBjb21wYXRpYmlsaXR5 IHNlY3Rpb25zIG9mIFRMUyBSRkNzDQogICBbW2xpc3QgVEJEXV0gdG8gcHJvaGliaXQgZmFsbGJh Y2sgdG8gVExTdjEuMCBhbmQgVExTdjEuMS4gIFRoaXMNCiAgIGRvY3VtZW50IGFsc28gdXBkYXRl cyBSRkMgNzUyNS4NCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBs ZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZzxodHRw czovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwJTNBJTJG JTJGdG9vbHMuaWV0Zi5vcmcmZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0 LmNvbSU3QzMwYjdjZmQ2YzExMTQwOWY0NDJiMDhkNWU1YmQzNzc3JTdDNzJmOTg4YmY4NmYxNDFh ZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY2NzUyMzIxNTAzMTUzOSZzZGF0YT1peEVQ QVplNTFkMUZodmRCOXNROG16UkhZMDRCbHl4JTJCSVlqbEZDJTJGbzBkdyUzRCZyZXNlcnZlZD0w Pi4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCi0tDQoNCkJlc3QgcmVnYXJkcywNCkth dGhsZWVuDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPGh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYu b3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGxzJmRhdGE9MDIlN0MwMSU3Q0FuZHJlaS5Qb3Bv diU0MG1pY3Jvc29mdC5jb20lN0MzMGI3Y2ZkNmMxMTE0MDlmNDQyYjA4ZDVlNWJkMzc3NyU3Qzcy Zjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2Njc1MjMyMTUwNDE1 NTImc2RhdGE9R2tJWHJzM3pWZVVCYUVVMkVVTDglMkZYSmREZGtEVWxRNzBpS3IwckRKUVJVJTNE JnJlc2VydmVkPTA+DQoNCg0K --_000_CY4PR21MB0774BE80A4424D41D0C8C4138C440CY4PR21MB0774namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4ubTMwNjA5NTA2MzU5NDYwODA2 ODhob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6bV8zMDYwOTUwNjM1OTQ2MDgwNjg4aG9lbnpiO30N CnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiB0aGUgcmVjZW50IFdpbmRvd3MgdmVyc2lvbnMsIFRM UyAxLjAgaXMgbmVnb3RpYXRlZCBtb3JlIHRoYW4gMTAlIG9mIHRoZSB0aW1lIG9uIHRoZSBjbGll bnQgc2lkZSAodGhpcyBpbmNsdWRlcyBub24tYnJvd3NlciBjb25uZWN0aW9ucyBmcm9tIGFsbCBz b3J0cyBvZiBhcHBzLCBzb21lIGhhcmQtY29kaW5nIFRMUyB2ZXJzaW9ucyksIGFuZCBUTFMgMS4x IGFjY291bnRzIGZvciB+MC4zJSBvZiBjbGllbnQgY29ubmVjdGlvbnMuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaW5kb3dzIHNlcnZlciBuZWdvdGlhdGVzIFRMUyAxLjAg fjEuNSUgb2YgdGhlIHRpbWUgKGFsbCBzZXJ2ZXIgYXBwcywgbm90IGp1c3QgSUlTKSwgYW5kIHRo ZSB1c2Ugb2YgVExTIDEuMSBpcyBuZWdsaWdpYmxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGVyZWZvcmUsIHdlIGNhbm5vdCBkaXNhYmxlIFRMUyAxLjAgYnkgZGVmYXVsdCBpbiBXaW5kb3dz IGp1c3QgeWV0LCBidXQgd2lsbCBrZWVwIGxvb2tpbmcgYXQgdGhlIHRlbGVtZXRyeS4gSWYgUENJ L05JU1QvZGllZGllZGllIFJGQyBtYWtlIGEgZGlmZmVyZW5jZSwgSeKAmWxsIGJlIGhhcHB5IHRv IHJlZHVjZSB0aGUgc2V0IG9mIGVuYWJsZWQtYnktZGVmYXVsdCBUTFMgdmVyc2lvbnMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kcmVp PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUTFMgJmx0O3Rscy1ib3VuY2Vz QGlldGYub3JnJmd0OyA8Yj5PbiBCZWhhbGYgT2YgPC9iPg0KRXJpYyBSZXNjb3JsYTxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEp1bHkgOSwgMjAxOCA5OjU3IEFNPGJyPg0KPGI+VG86PC9iPiBL YXRobGVlbiBNb3JpYXJ0eSAmbHQ7a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20mZ3Q7 PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7dGxzQGlldGYub3JnJmd0OyAmbHQ7dGxzQGlldGYub3JnJmd0 Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gRndkOiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LW1vcmlhcnR5LXRscy1vbGR2ZXJzaW9ucy1kaWVkaWVkaWUtMDAudHh0 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIEp1bCA5LCAyMDE4IGF0IDk6NTQgQU0sIEVyaWMg UmVzY29ybGEgJmx0OzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5r Ij5la3JAcnRmbS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRp bmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyBmb3Igd3JpdGluZyB0 aGlzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIHdvdWxkIGJlIGluIGZhdm9yIG9mIGRlcHJlY2F0aW5nIG9sZCB2ZXJzaW9ucyBvZiBUTFMg cHJpb3IgdG8gMS4yLiBGaXJlZm94IFRlbGVtZXRyeSBzaG93cyB0aGF0IGFib3V0IDElIG9mIG91 ciBjb25uZWN0aW9ucyBhcmUgVExTIDEuMTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgc2hvdWxk IGJlIDEuMC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihvbiB0aGUgc2FtZSBkYXRhIHNldCwgVExTIDEu MyBpcyAmZ3Q7IDUlKSwgYW5kIFRMUyAxLjEgaXMgbmVnbGlnaWJsZS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyBwcm9iYWJseSBh IGhpZ2hlciBudW1iZXIgdGhhbiB3ZSdkIGJlIGNvbWZvcnRhYmxlIHR1cm5pbmcgb2ZmIGltbWVk aWF0ZWx5LCBidXQgaXQgaXMgcHJvYmFibHkgd29ydGggc3RhcnRpbmcgdGhlIHByb2Nlc3MuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9uIE1vbiwgSnVsIDksIDIwMTggYXQgOTo0MCBBTSwgS2F0aGxlZW4gTW9y aWFydHkgJmx0OzxhIGhyZWY9Im1haWx0bzprYXRobGVlbi5tb3JpYXJ0eS5pZXRmQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPmthdGhsZWVuLm1vcmlhcnR5LmlldGZAZ21haWwuY29tPC9hPiZn dDsgd3JvdGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IZWxsbyw8YnI+DQo8YnI+DQpTdGVwaGVuIGFuZCBJIHBvc3RlZCB0 aGUgZHJhZnQgYmVsb3cgdG8gc2VlIGlmIHRoZSBUTFMgd29ya2luZyBncm91cDxicj4NCmlzIHJl YWR5IHRvIHRha2Ugc3RlcHMgdG8gZGVwcmVjYXRlIFRMU3YxLjAgYW5kIFRMU3YxLjEuJm5ic3A7 IFRoZXJlIGhhczxicj4NCmJlZW4gYSByZWNlbnQgZHJvcCBvZmYgaW4gdXNhZ2UgZm9yIHdlYiBh cHBsaWNhdGlvbnMgZHVlIHRvIHRoZSBQQ0k8YnI+DQpDb3VuY2lsIHJlY29tbWVuZGF0aW9uIHRv IG1vdmUgb2ZmIFRMU3YxLjAsIHdpdGggYSByZWNvbW1lbmRhdGlvbiB0bzxicj4NCmdvIHRvIFRM U3YxLjIgYnkgSnVuZSAzMHRoLiZuYnNwOyBOSVNUIGhhcyBhbHNvIGJlZW4gcmVjb21tZW5kaW5n IFRMU3YxLjI8YnI+DQphcyBhIGJhc2VsaW5lLiZuYnNwOyBBcHBsaWNhdGlvbnMgb3RoZXIgdGhh biB0aG9zZSB1c2luZyBIVFRQIG1heSBub3QgaGF2ZTxicj4NCmhhZCB0aGUgc2FtZSByZWR1Y3Rp b24gaW4gdXNhZ2UuJm5ic3A7IElmIHlvdSBhcmUgcmVzcG9uc2libGUgZm9yIHNlcnZpY2VzPGJy Pg0Kd2hlcmUgeW91IGhhdmUgYSByZWFzb25hYmxlIHZhbnRhZ2UgcG9pbnQgdG8gZ2F0aGVyIGFu ZCBzaGFyZTxicj4NCnN0YXRpc3RpY3MgdG8gYXNzZXNzIHVzYWdlIGZ1cnRoZXIsIHRoYXQgY291 bGQgYmUgaGVscGZ1bCBmb3IgdGhlPGJyPg0KZGlzY3Vzc2lvbi4mbmJzcDsgV2UndmUgcmVjZWl2 ZWQgc29tZSBmZWVkYmFjayB0aGF0IGhhcyBiZWVuIGluY29ycG9yYXRlZDxicj4NCmludG8gdGhl IHdvcmtpbmcgZHJhZnQgYW5kIGZlZWxlcnMgaW4gZ2VuZXJhbCBoYXZlIGJlZW4gcG9zaXRpdmUu Jm5ic3A7IEl0PGJyPg0Kd291bGQgYmUgZ29vZCB0byBrbm93IGlmIHRoZXJlIGFyZSBhbnkgc2hv dyBzdG9wcGVycyB0aGF0IGhhdmUgbm90PGJyPg0KYmVlbiBjb25zaWRlcmVkLjxicj4NCjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRnNmdGNkJTJGdGxzLW9sZHZlcnNpb25zLWRp ZWRpZWRpZSZhbXA7ZGF0YT0wMiU3QzAxJTdDQW5kcmVpLlBvcG92JTQwbWljcm9zb2Z0LmNvbSU3 QzMwYjdjZmQ2YzExMTQwOWY0NDJiMDhkNWU1YmQzNzc3JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIy ZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjY2NzUyMzIxNTAwMTUxNCZhbXA7c2RhdGE9NkpTUVpl OTNuV25BRUx2T2dHM0t5SWNQb3BRbGVNRHRORjZ2OExXRlhXVSUzRCZhbXA7cmVzZXJ2ZWQ9MCIg dGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9zZnRjZC90bHMtb2xkdmVyc2lvbnMt ZGllZGllZGllPC9hPjxicj4NCjxicj4NClRoYW5rcyBpbiBhZHZhbmNlLDxicj4NCkthdGhsZWVu PGJyPg0KPGJyPg0KPGJyPg0KLS0tLS0tLS0tLSBGb3J3YXJkZWQgbWVzc2FnZSAtLS0tLS0tLS0t PGJyPg0KRnJvbTombmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0 Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+Jmd0Ozxi cj4NCkRhdGU6IE1vbiwgSnVuIDE4LCAyMDE4IGF0IDM6MDUgUE08YnI+DQpTdWJqZWN0OiBOZXcg VmVyc2lvbiBOb3RpZmljYXRpb24gZm9yPGJyPg0KZHJhZnQtbW9yaWFydHktdGxzLW9sZHZlcnNp b25zLWRpZWRpZWRpZS0wMC50eHQ8YnI+DQpUbzogU3RlcGhlbiBGYXJyZWxsICZsdDs8YSBocmVm PSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSIgdGFyZ2V0PSJfYmxhbmsiPnN0ZXBo ZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0OywgS2F0aGxlZW4gTW9yaWFydHk8YnI+DQombHQ7 PGEgaHJlZj0ibWFpbHRvOkthdGhsZWVuLk1vcmlhcnR5LmlldGZAZ21haWwuY29tIiB0YXJnZXQ9 Il9ibGFuayI+S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxi cj4NCjxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1tb3JpYXJ0eS10bHMt b2xkdmVyc2lvbnMtZGllZGllZGllLTAwLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBz dWJtaXR0ZWQgYnkgU3RlcGhlbiBGYXJyZWxsIGFuZCBwb3N0ZWQgdG8gdGhlPGJyPg0KSUVURiBy ZXBvc2l0b3J5Ljxicj4NCjxicj4NCk5hbWU6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDtkcmFmdC1tb3JpYXJ0eS10bHMtb2xkdmVyc2lvbnMtZGllZGllZGllPGJyPg0K UmV2aXNpb246Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7MDA8YnI+DQpUaXRsZTombmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IERlcHJlY2F0aW5nIFRMU3YxLjAgYW5kIFRMU3Yx LjE8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE4LTA2LTE4PGJyPg0KR3JvdXA6Jm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQ YWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDEwPGJyPg0KVVJMOjxicj4N CjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGd3d3LmlldGYub3JnJTJGaW50ZXJuZXQtZHJhZnRzJTJGZHJhZnQt bW9yaWFydHktdGxzLW9sZHZlcnNpb25zLWRpZWRpZWRpZS0wMC50eHQmYW1wO2RhdGE9MDIlN0Mw MSU3Q0FuZHJlaS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN0MzMGI3Y2ZkNmMxMTE0MDlmNDQyYjA4 ZDVlNWJkMzc3NyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzY2Njc1MjMyMTUwMTE1MTgmYW1wO3NkYXRhPSUyQkJSR21NYmY3cjRtWG95V3FIbVQ2a2dOakh3 N0RyaDdsZERjZUc1Z3FmUSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYuLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbW9yaWFydHktdGxzLW9sZHZl cnNpb25zLWRpZWRpZWRpZS0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZGF0YXRyYWNrZXIuaWV0Zi5vcmclMkZkb2MlMkZkcmFmdC1tb3JpYXJ0eS10bHMtb2xk dmVyc2lvbnMtZGllZGllZGllJTJGJmFtcDtkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBt aWNyb3NvZnQuY29tJTdDMzBiN2NmZDZjMTExNDA5ZjQ0MmIwOGQ1ZTViZDM3NzclN0M3MmY5ODhi Zjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjY3NTIzMjE1MDExNTE4JmFt cDtzZGF0YT1RZ2UybnZjeDhmejEwNVV1eDFybDFlTTJ5SGlJN3pidnhBOFB2cHMxMHo4JTNEJmFt cDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtbW9yaWFydHktdGxzLW9sZHZlcnNpb25zLWRpZWRpZWRpZS88L2E+PGJyPg0K SHRtbGl6ZWQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9u Lm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmh0bWwlMkZk cmFmdC1tb3JpYXJ0eS10bHMtb2xkdmVyc2lvbnMtZGllZGllZGllLTAwJmFtcDtkYXRhPTAyJTdD MDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdDMzBiN2NmZDZjMTExNDA5ZjQ0MmIw OGQ1ZTViZDM3NzclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2NjY3NTIzMjE1MDIxNTM1JmFtcDtzZGF0YT1CejZGcnZ2aVBvU0l4a0I4M2JvR3hjT3hWZzJO dnJxUzNBMWJVaW5Ob2RjJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LW1vcmlhcnR5LXRscy1vbGR2ZXJzaW9ucy1kaWVk aWVkaWUtMDA8L2E+PGJyPg0KSHRtbGl6ZWQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZkYXRhdHJh Y2tlci5pZXRmLm9yZyUyRmRvYyUyRmh0bWwlMkZkcmFmdC1tb3JpYXJ0eS10bHMtb2xkdmVyc2lv bnMtZGllZGllZGllJmFtcDtkYXRhPTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQu Y29tJTdDMzBiN2NmZDZjMTExNDA5ZjQ0MmIwOGQ1ZTViZDM3NzclN0M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NjY3NTIzMjE1MDIxNTM1JmFtcDtzZGF0YT1N MU80OHlQVFBrZCUyQmIzJTJGRTN6MCUyRkFuaUJVTW96RHdmUXpwMlJhNXNMUmJRJTNEJmFtcDty ZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1tb3JpYXJ0eS10bHMtb2xkdmVyc2lvbnMtZGllZGllZGllPC9hPjxicj4N Cjxicj4NCjxicj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IFtp ZiBhcHByb3ZlZF0gZm9ybWFsbHkgZGVwcmVjYXRlcyBUcmFuc3BvcnQgTGF5ZXI8YnI+DQombmJz cDsgJm5ic3A7U2VjdXJpdHkgKFRMUykgdmVyc2lvbnMgMS4wIFtSRkMyMjQ2XSBhbmQgMS4xIFtS RkM0MzQ2XSBhbmQgbW92ZXM8YnI+DQombmJzcDsgJm5ic3A7dGhlc2UgZG9jdW1lbnRzIHRvIHRo ZSBoaXN0b3JpYyBzdGF0ZS4mbmJzcDsgVGhlc2UgdmVyc2lvbnMgbGFjayBzdXBwb3J0PGJyPg0K Jm5ic3A7ICZuYnNwO2ZvciBjdXJyZW50IGFuZCByZWNvbW1lbmRlZCBjaXBoZXIgc3VpdGVzLCBh bmQgdmFyaW91cyBnb3Zlcm5tZW50IGFuZDxicj4NCiZuYnNwOyAmbmJzcDtpbmR1c3RyeSBwcm9m aWlsZXMgb2YgYXBwbGljYXRpb25zIHVzaW5nIFRMUyBub3cgbWFuZGF0ZSBhdm9pZGluZzxicj4N CiZuYnNwOyAmbmJzcDt0aGVzZSBvbGQgVExTIHZlcnNpb25zLiZuYnNwOyBUTFN2MS4yIGhhcyBi ZWVuIHRoZSByZWNvbW1lbmRlZCB2ZXJzaW9uIGZvcjxicj4NCiZuYnNwOyAmbmJzcDtJRVRGIHBy b3RvY29scyBzaW5jZSAyMDA4LCBwcm92aWRpbmcgc3VmZmljaWVudCB0aW1lIHRvIHRyYW5zaXRp b248YnI+DQombmJzcDsgJm5ic3A7YXdheSBmcm9tIG9sZGVyIHZlcnNpb25zLiZuYnNwOyBQcm9k dWN0cyBoYXZpbmcgdG8gc3VwcG9ydCBvbGRlciB2ZXJzaW9uczxicj4NCiZuYnNwOyAmbmJzcDtp bmNyZWFzZSB0aGUgYXR0YWNrIHN1cmZhY2UgdW5uZWNlc3NhcmlseSBhbmQgaW5jcmVhc2Ugb3Bw b3J0dW5pdGllczxicj4NCiZuYnNwOyAmbmJzcDtmb3IgbWlzY29uZmlndXJhdGlvbnMuJm5ic3A7 IFN1cHBvcnRpbmcgdGhlc2Ugb2xkZXIgdmVyc2lvbnMgYWxzbyByZXF1aXJlczxicj4NCiZuYnNw OyAmbmJzcDthZGRpdGlvbmFsIGVmZm9ydCBmb3IgbGlicmFyeSBhbmQgcHJvZHVjdCBtYWludGVu YW5jZS48YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7VGhpcyBkb2N1bWVudCB1cGRhdGVzIHRoZSBi YWNrd2FyZCBjb21wYXRpYmlsaXR5IHNlY3Rpb25zIG9mIFRMUyBSRkNzPGJyPg0KJm5ic3A7ICZu YnNwO1tbbGlzdCBUQkRdXSB0byBwcm9oaWJpdCBmYWxsYmFjayB0byBUTFN2MS4wIGFuZCBUTFN2 MS4xLiZuYnNwOyBUaGlzPGJyPg0KJm5ic3A7ICZuYnNwO2RvY3VtZW50IGFsc28gdXBkYXRlcyBS RkMgNzUyNS48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpQbGVhc2Ugbm90ZSB0aGF0IGl0 IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9u PGJyPg0KdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBh dCA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20v P3VybD1odHRwJTNBJTJGJTJGdG9vbHMuaWV0Zi5vcmcmYW1wO2RhdGE9MDIlN0MwMSU3Q0FuZHJl aS5Qb3BvdiU0MG1pY3Jvc29mdC5jb20lN0MzMGI3Y2ZkNmMxMTE0MDlmNDQyYjA4ZDVlNWJkMzc3 NyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY2Njc1MjMy MTUwMzE1MzkmYW1wO3NkYXRhPWl4RVBBWmU1MWQxRmh2ZEI5c1E4bXpSSFkwNEJseXglMkJJWWps RkMlMkZvMGR3JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQp0b29scy5pZXRm Lm9yZzwvYT4uPGJyPg0KPGJyPg0KVGhlIElFVEYgU2VjcmV0YXJpYXQ8YnI+DQo8c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9Im0zMDYwOTUw NjM1OTQ2MDgwNjg4aG9lbnpiIj4tLSA8L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9Im0z MDYwOTUwNjM1OTQ2MDgwNjg4aG9lbnpiIj5CZXN0IHJlZ2FyZHMsPC9zcGFuPjxicj4NCjxzcGFu IGNsYXNzPSJtMzA2MDk1MDYzNTk0NjA4MDY4OGhvZW56YiI+S2F0aGxlZW48L3NwYW4+PGJyPg0K PGJyPg0KPHNwYW4gY2xhc3M9Im0zMDYwOTUwNjM1OTQ2MDgwNjg4aG9lbnpiIj5fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0ibTMwNjA5NTA2MzU5NDYwODA2ODhob2VuemIiPlRMUyBtYWlsaW5nIGxpc3Q8L3NwYW4+ PGJyPg0KPHNwYW4gY2xhc3M9Im0zMDYwOTUwNjM1OTQ2MDgwNjg4aG9lbnpiIj48YSBocmVmPSJt YWlsdG86VExTQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+VExTQGlldGYub3JnPC9hPjwvc3Bh bj48YnI+DQo8c3BhbiBjbGFzcz0ibTMwNjA5NTA2MzU5NDYwODA2ODhob2VuemIiPjxhIGhyZWY9 Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGd3d3LmlldGYub3JnJTJGbWFpbG1hbiUyRmxpc3RpbmZvJTJGdGxzJmFtcDtkYXRh PTAyJTdDMDElN0NBbmRyZWkuUG9wb3YlNDBtaWNyb3NvZnQuY29tJTdDMzBiN2NmZDZjMTExNDA5 ZjQ0MmIwOGQ1ZTViZDM3NzclN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzEl N0MwJTdDNjM2NjY3NTIzMjE1MDQxNTUyJmFtcDtzZGF0YT1Ha0lYcnMzelZlVUJhRVUyRVVMOCUy RlhKZERka0RVbFE3MGlLcjByREpRUlUlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5r Ij5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RsczwvYT48L3NwYW4+PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR21MB0774BE80A4424D41D0C8C4138C440CY4PR21MB0774namp_-- From nobody Mon Jul 9 11:14:47 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89E2130E51 for ; Mon, 9 Jul 2018 11:14:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvPZoQFe_H-H for ; Mon, 9 Jul 2018 11:14:42 -0700 (PDT) Received: from blastoise.ghedini.me (blastoise.ghedini.me [IPv6:2001:19f0:6c01:a56:5400:1ff:fe4a:5694]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746C51277D2 for ; Mon, 9 Jul 2018 11:14:42 -0700 (PDT) Received: from localhost (185-33-211-9.g3ns.net [185.33.211.9]) by blastoise.ghedini.me (Postfix) with ESMTPSA id 77DA0DF30C; Mon, 9 Jul 2018 18:14:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ghedini.me; s=mail; t=1531160080; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=bokS3k/jW5auVeo4YwrXJwnl1ZcWjY0O2J1pFjUbhyc=; b=kiVOIaoq85AmbOhu1Abg/EB0cWBu/hCgynFgFBAVTYIHy/XL6ZOsua6noJxes8iJAwHw8E yPGo1Y8INpD3iXd6/tG/WgB0mbSl8J0TJ5uofrystKt4LBXfBLaKz1nLOXw8HOvELlwScr M+crTHBwFBjOa72mRPqmpMjUUVEnyB0= Date: Mon, 9 Jul 2018 19:14:38 +0100 From: Alessandro Ghedini To: Kathleen Moriarty Cc: "" Message-ID: <20180709181438.GA28316@mandy> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 18:14:45 -0000 On Mon, Jul 09, 2018 at 12:40:54PM -0400, Kathleen Moriarty wrote: > Hello, > > Stephen and I posted the draft below to see if the TLS working group > is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has > been a recent drop off in usage for web applications due to the PCI > Council recommendation to move off TLSv1.0, with a recommendation to > go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 > as a baseline. Applications other than those using HTTP may not have > had the same reduction in usage. If you are responsible for services > where you have a reasonable vantage point to gather and share > statistics to assess usage further, that could be helpful for the > discussion. We've received some feedback that has been incorporated > into the working draft and feelers in general have been positive. It > would be good to know if there are any show stoppers that have not > been considered. > > https://github.com/sftcd/tls-oldversions-diediedie I'm very much in favour of deprecating pre-TLSv1.2 versions, and this seems like a good time to start. As far as usage goes, it's still quite significant, at least as far as Cloudflare is concerned. See the chart from a couple of months ago at: https://blog.cloudflare.com/you-get-tls-1-3-you-get-tls-1-3-everyone-gets-tls-1-3/ Particularly for TLSv1.0, which is still at ~10% of all TLS connections we see, while TLSv1.1 is at ~0.2%. Given this it's unlikely we (Cloudflare) will be able to disable them by default any time soon, but we might be able to understand the situation better once we do a more thorough analysis. Cheers From nobody Mon Jul 9 11:42:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2C4131051 for ; Mon, 9 Jul 2018 11:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 355SwQMhZdlN for ; Mon, 9 Jul 2018 11:42:37 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7245F130F03 for ; Mon, 9 Jul 2018 11:42:37 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w69IgFm2021505; Mon, 9 Jul 2018 19:42:36 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=FYGxxM4FS3qtcNpZISgMsB+b7gxdYCRRvUg4vn+mzl8=; b=IhtSJ+nempdXx3kuTaSGG2w9zpq5/zVQh0m1ljg7EVKF4sWmNNEZWLNekT9uFx5vwUC9 J3ehDtzYLv47sQVKRTSpi1lyosLTuZtk6xsARhP4N4cm/NQWSwmFX0ojqPx5NHCwsMVP HmkEHVtL17BuWso0zlGlvM7TmO2Q7mVQSXewRfBIn1LUNxmoq1ZLaHC3SlHENSdv47Ht UxGEldWP/jnCh7sKOAUR0EcQT8a7LPyVwqV7WKxNgRWEkPMcNh08IYJwWZVpLoefU0o/ AhwkhneaWCeo20V3FhOWuYC6njAFu+ouOrUN6TkJ2zkdcIP1JbD0e+lyqpd+TR60w1qr QQ== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2k2pb1xbv9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Jul 2018 19:42:36 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w69IZIGD009394; Mon, 9 Jul 2018 14:42:35 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2k2ruvq5n4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Jul 2018 14:42:33 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 9 Jul 2018 14:42:26 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Mon, 9 Jul 2018 14:42:26 -0400 From: "Salz, Rich" To: Kathleen Moriarty , "" Thread-Topic: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt Thread-Index: AQHUF6PG+cob+lmdCEitxYvNmL6MC6SHOd8A Date: Mon, 9 Jul 2018 18:42:25 +0000 Message-ID: <0222419E-A87A-4781-A981-DA95ADD6A550@akamai.com> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.92] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807090210 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807090211 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 18:42:40 -0000 RldJVywgVGhlIG5leHQgcmVsZWFzZSBvZiBPcGVuU1NMIGlzIGFuIExUUyByZWxlYXNlIGFuZCB3 aWxsIGJlIHN1cHBvcnRlZCBmb3IgZml2ZSB5ZWFycy4gIEl0IGRpc2FibGVzIFNTTHYzIGJ5IGRl ZmF1bHQsIGJ1dCBkb2VzIGVuYWJsZSBUTFMxLjAgYW5kIFRMUzEuMSBieSBkZWZhdWx0LiAgKEl0 IGFsc28gaW5jbHVkZXMgVExTMS4zLCBudWRnZSBudWRnZSBSRkMgZWRpdG9yIHF1ZXVlLikNCg0K DQoNCu+7v09uIDcvOS8xOCwgMTI6NDIgUE0sICJLYXRobGVlbiBNb3JpYXJ0eSIgPGthdGhsZWVu Lm1vcmlhcnR5LmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIEhlbGxvLA0KICAgIA0KICAg IFN0ZXBoZW4gYW5kIEkgcG9zdGVkIHRoZSBkcmFmdCBiZWxvdyB0byBzZWUgaWYgdGhlIFRMUyB3 b3JraW5nIGdyb3VwDQogICAgaXMgcmVhZHkgdG8gdGFrZSBzdGVwcyB0byBkZXByZWNhdGUgVExT djEuMCBhbmQgVExTdjEuMS4gIFRoZXJlIGhhcw0KICAgIGJlZW4gYSByZWNlbnQgZHJvcCBvZmYg aW4gdXNhZ2UgZm9yIHdlYiBhcHBsaWNhdGlvbnMgZHVlIHRvIHRoZSBQQ0kNCiAgICBDb3VuY2ls IHJlY29tbWVuZGF0aW9uIHRvIG1vdmUgb2ZmIFRMU3YxLjAsIHdpdGggYSByZWNvbW1lbmRhdGlv biB0bw0KICAgIGdvIHRvIFRMU3YxLjIgYnkgSnVuZSAzMHRoLiAgTklTVCBoYXMgYWxzbyBiZWVu IHJlY29tbWVuZGluZyBUTFN2MS4yDQogICAgYXMgYSBiYXNlbGluZS4gIEFwcGxpY2F0aW9ucyBv dGhlciB0aGFuIHRob3NlIHVzaW5nIEhUVFAgbWF5IG5vdCBoYXZlDQogICAgaGFkIHRoZSBzYW1l IHJlZHVjdGlvbiBpbiB1c2FnZS4gIElmIHlvdSBhcmUgcmVzcG9uc2libGUgZm9yIHNlcnZpY2Vz DQogICAgd2hlcmUgeW91IGhhdmUgYSByZWFzb25hYmxlIHZhbnRhZ2UgcG9pbnQgdG8gZ2F0aGVy IGFuZCBzaGFyZQ0KICAgIHN0YXRpc3RpY3MgdG8gYXNzZXNzIHVzYWdlIGZ1cnRoZXIsIHRoYXQg Y291bGQgYmUgaGVscGZ1bCBmb3IgdGhlDQogICAgZGlzY3Vzc2lvbi4gIFdlJ3ZlIHJlY2VpdmVk IHNvbWUgZmVlZGJhY2sgdGhhdCBoYXMgYmVlbiBpbmNvcnBvcmF0ZWQNCiAgICBpbnRvIHRoZSB3 b3JraW5nIGRyYWZ0IGFuZCBmZWVsZXJzIGluIGdlbmVyYWwgaGF2ZSBiZWVuIHBvc2l0aXZlLiAg SXQNCiAgICB3b3VsZCBiZSBnb29kIHRvIGtub3cgaWYgdGhlcmUgYXJlIGFueSBzaG93IHN0b3Bw ZXJzIHRoYXQgaGF2ZSBub3QNCiAgICBiZWVuIGNvbnNpZGVyZWQuDQogICAgDQogICAgaHR0cHM6 Ly9naXRodWIuY29tL3NmdGNkL3Rscy1vbGR2ZXJzaW9ucy1kaWVkaWVkaWUNCiAgICANCiAgICBU aGFua3MgaW4gYWR2YW5jZSwNCiAgICBLYXRobGVlbg0KICAgIA0KICAgIA0KICAgIC0tLS0tLS0t LS0gRm9yd2FyZGVkIG1lc3NhZ2UgLS0tLS0tLS0tLQ0KICAgIEZyb206ICA8aW50ZXJuZXQtZHJh ZnRzQGlldGYub3JnPg0KICAgIERhdGU6IE1vbiwgSnVuIDE4LCAyMDE4IGF0IDM6MDUgUE0NCiAg ICBTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQogICAgZHJhZnQtbW9yaWFy dHktdGxzLW9sZHZlcnNpb25zLWRpZWRpZWRpZS0wMC50eHQNCiAgICBUbzogU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPiwgS2F0aGxlZW4gTW9yaWFydHkNCiAgICA8 S2F0aGxlZW4uTW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+DQogICAgDQogICAgDQogICAgDQogICAg QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LW1vcmlhcnR5LXRscy1vbGR2ZXJzaW9ucy1kaWVk aWVkaWUtMDAudHh0DQogICAgaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBTdGVw aGVuIEZhcnJlbGwgYW5kIHBvc3RlZCB0byB0aGUNCiAgICBJRVRGIHJlcG9zaXRvcnkuDQogICAg DQogICAgTmFtZTogICAgICAgICAgIGRyYWZ0LW1vcmlhcnR5LXRscy1vbGR2ZXJzaW9ucy1kaWVk aWVkaWUNCiAgICBSZXZpc2lvbjogICAgICAgMDANCiAgICBUaXRsZTogICAgICAgICAgRGVwcmVj YXRpbmcgVExTdjEuMCBhbmQgVExTdjEuMQ0KICAgIERvY3VtZW50IGRhdGU6ICAyMDE4LTA2LTE4 DQogICAgR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KICAgIFBhZ2VzOiAg ICAgICAgICAxMA0KICAgIFVSTDoNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvZHJhZnQtbW9yaWFydHktdGxzLW9sZHZlcnNpb25zLWRpZWRpZWRpZS0wMC50eHQNCiAg ICBTdGF0dXM6DQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbW9y aWFydHktdGxzLW9sZHZlcnNpb25zLWRpZWRpZWRpZS8NCiAgICBIdG1saXplZDoNCiAgICBodHRw czovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbW9yaWFydHktdGxzLW9sZHZlcnNpb25zLWRp ZWRpZWRpZS0wMA0KICAgIEh0bWxpemVkOg0KICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2h0bWwvZHJhZnQtbW9yaWFydHktdGxzLW9sZHZlcnNpb25zLWRpZWRpZWRpZQ0KICAg IA0KICAgIA0KICAgIEFic3RyYWN0Og0KICAgICAgIFRoaXMgZG9jdW1lbnQgW2lmIGFwcHJvdmVk XSBmb3JtYWxseSBkZXByZWNhdGVzIFRyYW5zcG9ydCBMYXllcg0KICAgICAgIFNlY3VyaXR5IChU TFMpIHZlcnNpb25zIDEuMCBbUkZDMjI0Nl0gYW5kIDEuMSBbUkZDNDM0Nl0gYW5kIG1vdmVzDQog ICAgICAgdGhlc2UgZG9jdW1lbnRzIHRvIHRoZSBoaXN0b3JpYyBzdGF0ZS4gIFRoZXNlIHZlcnNp b25zIGxhY2sgc3VwcG9ydA0KICAgICAgIGZvciBjdXJyZW50IGFuZCByZWNvbW1lbmRlZCBjaXBo ZXIgc3VpdGVzLCBhbmQgdmFyaW91cyBnb3Zlcm5tZW50IGFuZA0KICAgICAgIGluZHVzdHJ5IHBy b2ZpaWxlcyBvZiBhcHBsaWNhdGlvbnMgdXNpbmcgVExTIG5vdyBtYW5kYXRlIGF2b2lkaW5nDQog ICAgICAgdGhlc2Ugb2xkIFRMUyB2ZXJzaW9ucy4gIFRMU3YxLjIgaGFzIGJlZW4gdGhlIHJlY29t bWVuZGVkIHZlcnNpb24gZm9yDQogICAgICAgSUVURiBwcm90b2NvbHMgc2luY2UgMjAwOCwgcHJv dmlkaW5nIHN1ZmZpY2llbnQgdGltZSB0byB0cmFuc2l0aW9uDQogICAgICAgYXdheSBmcm9tIG9s ZGVyIHZlcnNpb25zLiAgUHJvZHVjdHMgaGF2aW5nIHRvIHN1cHBvcnQgb2xkZXIgdmVyc2lvbnMN CiAgICAgICBpbmNyZWFzZSB0aGUgYXR0YWNrIHN1cmZhY2UgdW5uZWNlc3NhcmlseSBhbmQgaW5j cmVhc2Ugb3Bwb3J0dW5pdGllcw0KICAgICAgIGZvciBtaXNjb25maWd1cmF0aW9ucy4gIFN1cHBv cnRpbmcgdGhlc2Ugb2xkZXIgdmVyc2lvbnMgYWxzbyByZXF1aXJlcw0KICAgICAgIGFkZGl0aW9u YWwgZWZmb3J0IGZvciBsaWJyYXJ5IGFuZCBwcm9kdWN0IG1haW50ZW5hbmNlLg0KICAgIA0KICAg ICAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyB0aGUgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBzZWN0 aW9ucyBvZiBUTFMgUkZDcw0KICAgICAgIFtbbGlzdCBUQkRdXSB0byBwcm9oaWJpdCBmYWxsYmFj ayB0byBUTFN2MS4wIGFuZCBUTFN2MS4xLiAgVGhpcw0KICAgICAgIGRvY3VtZW50IGFsc28gdXBk YXRlcyBSRkMgNzUyNS4NCiAgICANCiAgICANCiAgICANCiAgICANCiAgICBQbGVhc2Ugbm90ZSB0 aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJt aXNzaW9uDQogICAgdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCiAgICANCiAgICBUaGUgSUVURiBTZWNyZXRhcmlhdA0K ICAgIA0KICAgIA0KICAgIA0KICAgIC0tIA0KICAgIA0KICAgIEJlc3QgcmVnYXJkcywNCiAgICBL YXRobGVlbg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQogICAgVExTIG1haWxpbmcgbGlzdA0KICAgIFRMU0BpZXRmLm9yZw0KICAgIGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQogICAgDQoNCg== From nobody Mon Jul 9 11:46:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49C94130E84 for ; Mon, 9 Jul 2018 11:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ClpOhSm292Dk for ; Mon, 9 Jul 2018 11:46:17 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D30761277BB for ; Mon, 9 Jul 2018 11:46:16 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w69IgIb3030398; Mon, 9 Jul 2018 19:46:14 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=cES0pvkLwJzhoHuLElaFSRdKx1eaTbskv6sVo2BD4v8=; b=CZsi0Q7E/ZmRwy36SoApZ98Ri5qsPqUyhXyvf7DIthnt9PWlF74uif5XyqgPNvH/AKJ9 JVL4mRcDrDNlQqXWynyt97D9opIT2jH1f7gLDElRAfFu1xAttmKw9qiQHDV1tmw/oCec pmBz8mGzNjypyJSh2PIYuhHXAkPli9JcBancOzeDUdwK+N1yzsVNnQWRPvqhbFva7JL9 uMdgonDneRazeNnh1h7NdHAQTDZTz8XgsE+ieG2le17kESpf7nk1NThfrMrCmAMjAF/P JtdI9vTcAGOAH6pGnRO5XMys3NHNuBkPz1utYSv0H/t5mh/VRSpEhuhf3WRo0RLStPD4 QQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2k2pbnpxbs-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 09 Jul 2018 19:46:14 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w69IZIf8028003; Mon, 9 Jul 2018 14:46:13 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2k2ruuuv47-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 09 Jul 2018 14:46:13 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Mon, 9 Jul 2018 14:46:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Mon, 9 Jul 2018 14:46:13 -0400 From: "Salz, Rich" To: Kathleen Moriarty CC: "" Thread-Topic: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt Thread-Index: AQHUF6PG+cob+lmdCEitxYvNmL6MC6SHdSsA///Fw4A= Date: Mon, 9 Jul 2018 18:46:12 +0000 Message-ID: <1EFA765A-76D1-43AE-9375-3F81B8B89F0D@akamai.com> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <20180709181438.GA28316@mandy> In-Reply-To: <20180709181438.GA28316@mandy> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.e.1.180613 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.92] Content-Type: text/plain; charset="utf-8" Content-ID: <465511659487924584BEB8780DBC1472@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=864 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807090210 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-09_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=783 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807090211 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 18:46:19 -0000 V2l0aG91dCBxdW90aW5nIGFueSBzcGVjaWZpYyBudW1iZXJzLCBJIHNoYXJlIEFsZXNzYW5kcm8n cyBzdXBwb3J0IGZvciB0aGlzLCB3aGlsZSBhbHNvIGVtcGhhc2l6aW5nIHRoYXQgaXQgd2lsbCBi ZSBxdWl0ZSBzb21lIHRpbWUgYmVmb3JlIG15IGVtcGxveWVyIHN0b3BzIHN1cHBvcnRpbmcgdGhv c2UgdmVyc2lvbnMuDQoNCg0K From nobody Mon Jul 9 11:50:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D51D013104C for ; Mon, 9 Jul 2018 11:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuZNfSZEaATd for ; Mon, 9 Jul 2018 11:50:08 -0700 (PDT) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285C2130E73 for ; Mon, 9 Jul 2018 11:50:08 -0700 (PDT) Received: by mail-io0-x241.google.com with SMTP id v26-v6so17993615iog.5 for ; Mon, 09 Jul 2018 11:50:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2jBay/XdZzEd37AqJRUF1qs0bZU5PwxDQE44gIEJ4NY=; b=iV7I0czjfy0OeXX2ih+k352DVehBJBkwi07+2dF/WhjRzDRw3XdJP1B/5oa3ycxGWy dKdWJePfzEWg7RNwoCJuvveIKpt5WPJBLhVPIEGf9EnKbD+HB+D5rCxDCbmH3lE4kQs8 rDLfGO67ocmT0KfpsvORNRtdwwsdaPouXkgDydnLpSXF4dN1GpOLtv7rXsItB3VI0ZZS BK/lqAfkJwJezUu/Oe9VjSidXEuwASwn8vPKPjY9cHBCSSwljZSNjri0bqbRuwgtRbm7 F/cMtuNjpSbvwAgT1No6pvCG02mm35t/kYwPNlVr1TF1PsO76dFUo933xO/1JiwsLgBR SYww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2jBay/XdZzEd37AqJRUF1qs0bZU5PwxDQE44gIEJ4NY=; b=oov72o01BMaKgpe5doF3RSjNNyi/JE0LU/1r/xwtKLKQQcUoxe7uCsWBYqKfh1Cw69 UbQlRMGzf0liO3g6o3175eCPDpbp4BnuosWEcTuW+BVs3dWXfyUNuF1sBpup9Av3asQH HYh9Fqyjk4XfeyoLWHzrs/V8m/MOvp+Sg1DdSVwc1U3kl7CMpDdpIKl5PRHdj0ddouXQ he8lrnYUZDGfzqhvzk09Cn60PM+sJi7cFqIq08ZYmdd9rBHnIB1WZEqSuOlQxA1eYeDc XJWZNhOi5S6hWh9OpW3Kx50R366g6P8dwdJqmN270pFys+bbrLW8QGJnqoX5klY78dQ1 eJjA== X-Gm-Message-State: AOUpUlGW9WATU10yQ/8ZLHh19DVZUtMm9vQiKpwYmDRnt5xWqDjj9SFG rJtFBT4qoEIqDUy70KbOaGpQoxTa3h83wEF9ub8= X-Google-Smtp-Source: AAOMgpedE/FdHeg8Xe6mQfPHz+Opyl/KbxpYJXZgnaW8seiGejaRYUcTustFvkZJg0Xb1vPL7nrnWxSoJ4qP2utu+e0= X-Received: by 2002:a6b:310d:: with SMTP id j13-v6mr2106963ioa.250.1531162207518; Mon, 09 Jul 2018 11:50:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:90cd:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 11:50:06 -0700 (PDT) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> From: Loganaden Velvindron Date: Mon, 9 Jul 2018 22:50:06 +0400 Message-ID: To: Eric Rescorla Cc: Kathleen Moriarty , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 18:50:11 -0000 On Mon, Jul 9, 2018 at 8:54 PM, Eric Rescorla wrote: > Thanks for writing this. > > I would be in favor of deprecating old versions of TLS prior to 1.2. Firefox > Telemetry shows that about 1% of our connections are TLS 1.1 (on the same > data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. > > This is probably a higher number than we'd be comfortable turning off > immediately, but it is probably worth starting the process. > I'm also in favour. Many banks/instituion in developing countries are moving to deprecate tls v1.0 and tls v1.1. As I commented on github: SSLpulse shows how many top websites support tls 1.2 (92.8%) and this number is increasing (0.5%): https://www.ssllabs.com/ssl-pulse/ KeyCDN and digicert have also announced their intentions to deprecate tls 1.0 and tls 1.1. https://github.com/sftcd/tls-oldversions-diediedie/commit/a0d6c160d922bd7f52a917884823114c90932291 > -Ekr > > > On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty > wrote: >> >> Hello, >> >> Stephen and I posted the draft below to see if the TLS working group >> is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has >> been a recent drop off in usage for web applications due to the PCI >> Council recommendation to move off TLSv1.0, with a recommendation to >> go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 >> as a baseline. Applications other than those using HTTP may not have >> had the same reduction in usage. If you are responsible for services >> where you have a reasonable vantage point to gather and share >> statistics to assess usage further, that could be helpful for the >> discussion. We've received some feedback that has been incorporated >> into the working draft and feelers in general have been positive. It >> would be good to know if there are any show stoppers that have not >> been considered. >> >> https://github.com/sftcd/tls-oldversions-diediedie >> >> Thanks in advance, >> Kathleen >> >> >> ---------- Forwarded message ---------- >> From: >> Date: Mon, Jun 18, 2018 at 3:05 PM >> Subject: New Version Notification for >> draft-moriarty-tls-oldversions-diediedie-00.txt >> To: Stephen Farrell , Kathleen Moriarty >> >> >> >> >> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt >> has been successfully submitted by Stephen Farrell and posted to the >> IETF repository. >> >> Name: draft-moriarty-tls-oldversions-diediedie >> Revision: 00 >> Title: Deprecating TLSv1.0 and TLSv1.1 >> Document date: 2018-06-18 >> Group: Individual Submission >> Pages: 10 >> URL: >> >> https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt >> >> Status: >> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/ >> Htmlized: >> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 >> Htmlized: >> >> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie >> >> >> Abstract: >> This document [if approved] formally deprecates Transport Layer >> Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves >> these documents to the historic state. These versions lack support >> for current and recommended cipher suites, and various government and >> industry profiiles of applications using TLS now mandate avoiding >> these old TLS versions. TLSv1.2 has been the recommended version for >> IETF protocols since 2008, providing sufficient time to transition >> away from older versions. Products having to support older versions >> increase the attack surface unnecessarily and increase opportunities >> for misconfigurations. Supporting these older versions also requires >> additional effort for library and product maintenance. >> >> This document updates the backward compatibility sections of TLS RFCs >> [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This >> document also updates RFC 7525. >> >> >> >> >> 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 >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Mon Jul 9 14:08:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E897130DF0 for ; Mon, 9 Jul 2018 14:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.com header.b=yb41EDxf; dkim=neutral reason="invalid (public key: not available)" header.d=konklone.com header.b=zjLOHNeZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CRUbLnRaLLPj for ; Mon, 9 Jul 2018 14:08:22 -0700 (PDT) Received: from pb-smtp2.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2771130E5D for ; Mon, 9 Jul 2018 14:08:22 -0700 (PDT) Received: from pb-smtp2.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 56E5FF1890 for ; Mon, 9 Jul 2018 17:08:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :references:in-reply-to:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=+/gXlVKzQ4TdPm2gtXhHXgfX9Zs=; b=yb41ED xf1Avoztaoxa2nUQarTxG776n7A+teQ2mz3A4ThUdS9plf76kJVV/iS8vY8L++zl 3Ulcfu5HIfHbtwCXPpfAiBqvScB7ova6N+sZF45+SDDdIQsZdXg5T+9U2x1X4KYh /nlpYPzasTupsXlLpALdGgXt9GcyU52yrTc4c= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id 4F135F188E for ; Mon, 9 Jul 2018 17:08:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=konklone.com; h=mime-version:references:in-reply-to:from:date:message-id:subject:to:cc:content-type; s=2016-12.pbsmtp; bh=CchkdlhJ65OKiumCZDmJESp8PfWGSc2GT0KkNVvOxzE=; b=zjLOHNeZEPPkYZOSDRvj79O93UMlRFZ3XY9BQo7s7vmEzjpeyq/GOkAfgL4iEmNXrH8lntXHCWwZXyjvCMLKS8fxYjPFD7pYbyiMZ4tu1IkTxGB+RBuqMSN011buQJJkHO3L9UhWAGpdvF5riQT38PdLTqIULW2DssVAZtECCvM= Received: from mail-io0-f179.google.com (unknown [209.85.223.179]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id C226CF188C for ; Mon, 9 Jul 2018 17:08:18 -0400 (EDT) Received: by mail-io0-f179.google.com with SMTP id y10-v6so3531199ioa.10 for ; Mon, 09 Jul 2018 14:08:18 -0700 (PDT) X-Gm-Message-State: AOUpUlGovF0GoM9pksYhbin5UO+PlG06FHQM6ZMkhFBYR/xViv6eyfrE HwfIE+hV7hKkak2O+wnVB6H5Huy4E5DWO9PZDo4= X-Google-Smtp-Source: AAOMgpfb51DSIXI1ACpbJSvHJipXBrEhDLlrwqIzJXg+4woSOwkqLFVd4iD67STU1WSiXOrpe80wBuOXWvGPtZ3XofM= X-Received: by 2002:a5e:8a45:: with SMTP id o5-v6mr7986352iom.88.1531170498096; Mon, 09 Jul 2018 14:08:18 -0700 (PDT) MIME-Version: 1.0 References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> In-Reply-To: From: Eric Mill Date: Mon, 9 Jul 2018 17:07:53 -0400 X-Gmail-Original-Message-ID: Message-ID: To: loganaden@gmail.com Cc: Eric Rescorla , "" Content-Type: multipart/alternative; boundary="000000000000a134e30570976977" X-Pobox-Relay-ID: 34399816-83BC-11E8-964C-40570C78B957-82875391!pb-smtp2.pobox.com Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 21:08:27 -0000 --000000000000a134e30570976977 Content-Type: text/plain; charset="UTF-8" If we're looking for precedent and support, the Canadian government recently (like in the last week or two) issued a policy requiring TLS 1.0 and 1.1 be disabled: https://www.canada.ca/en/treasury-board-secretariat/services/information-technology/policy-implementation-notices/implementing-https-secure-web-connections-itpin.html It's effective immediately for new services, and has a deadline of September 30, 2019 for existing services. -- Eric On Mon, Jul 9, 2018 at 3:02 PM Loganaden Velvindron wrote: > On Mon, Jul 9, 2018 at 8:54 PM, Eric Rescorla wrote: > > Thanks for writing this. > > > > I would be in favor of deprecating old versions of TLS prior to 1.2. > Firefox > > Telemetry shows that about 1% of our connections are TLS 1.1 (on the same > > data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. > > > > This is probably a higher number than we'd be comfortable turning off > > immediately, but it is probably worth starting the process. > > > > I'm also in favour. Many banks/instituion in developing countries are > moving to deprecate tls v1.0 and tls v1.1. > > As I commented on github: > SSLpulse shows how many top websites support tls 1.2 (92.8%) and this > number is increasing (0.5%): > > https://www.ssllabs.com/ssl-pulse/ > > KeyCDN and digicert have also announced their intentions to deprecate > tls 1.0 and tls 1.1. > > > https://github.com/sftcd/tls-oldversions-diediedie/commit/a0d6c160d922bd7f52a917884823114c90932291 > > > > > -Ekr > > > > > > On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty > > wrote: > >> > >> Hello, > >> > >> Stephen and I posted the draft below to see if the TLS working group > >> is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has > >> been a recent drop off in usage for web applications due to the PCI > >> Council recommendation to move off TLSv1.0, with a recommendation to > >> go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 > >> as a baseline. Applications other than those using HTTP may not have > >> had the same reduction in usage. If you are responsible for services > >> where you have a reasonable vantage point to gather and share > >> statistics to assess usage further, that could be helpful for the > >> discussion. We've received some feedback that has been incorporated > >> into the working draft and feelers in general have been positive. It > >> would be good to know if there are any show stoppers that have not > >> been considered. > >> > >> https://github.com/sftcd/tls-oldversions-diediedie > >> > >> Thanks in advance, > >> Kathleen > >> > >> > >> ---------- Forwarded message ---------- > >> From: > >> Date: Mon, Jun 18, 2018 at 3:05 PM > >> Subject: New Version Notification for > >> draft-moriarty-tls-oldversions-diediedie-00.txt > >> To: Stephen Farrell , Kathleen Moriarty > >> > >> > >> > >> > >> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt > >> has been successfully submitted by Stephen Farrell and posted to the > >> IETF repository. > >> > >> Name: draft-moriarty-tls-oldversions-diediedie > >> Revision: 00 > >> Title: Deprecating TLSv1.0 and TLSv1.1 > >> Document date: 2018-06-18 > >> Group: Individual Submission > >> Pages: 10 > >> URL: > >> > >> https://www.ietf. > .org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt > >> > >> Status: > >> > https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/ > >> Htmlized: > >> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 > >> Htmlized: > >> > >> > https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie > >> > >> > >> Abstract: > >> This document [if approved] formally deprecates Transport Layer > >> Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves > >> these documents to the historic state. These versions lack support > >> for current and recommended cipher suites, and various government and > >> industry profiiles of applications using TLS now mandate avoiding > >> these old TLS versions. TLSv1.2 has been the recommended version for > >> IETF protocols since 2008, providing sufficient time to transition > >> away from older versions. Products having to support older versions > >> increase the attack surface unnecessarily and increase opportunities > >> for misconfigurations. Supporting these older versions also requires > >> additional effort for library and product maintenance. > >> > >> This document updates the backward compatibility sections of TLS RFCs > >> [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This > >> document also updates RFC 7525. > >> > >> > >> > >> > >> 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 > >> > >> > >> > >> -- > >> > >> Best regards, > >> Kathleen > >> > >> _______________________________________________ > >> 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 > -- konklone.com | @konklone --000000000000a134e30570976977 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
If we're looking for precedent and support, the Canadi= an government recently (like in the last week or two) issued a policy requi= ring TLS 1.0 and 1.1 be disabled:


It'= ;s effective immediately for new services, and has a deadline of September = 30, 2019 for existing services.

-- Eric

On Mon, Jul 9, 2018 = at 3:02 PM Loganaden Velvindron <loganaden@gmail.com> wrote:
On Mon, Jul 9, 2018 at 8:54 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> Thanks for writing this.
>
> I would be in favor of deprecating old versions of TLS prior to 1.2. F= irefox
> Telemetry shows that about 1% of our connections are TLS 1.1 (on the s= ame
> data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible.
>
> This is probably a higher number than we'd be comfortable turning = off
> immediately, but it is probably worth starting the process.
>

I'm also in favour. Many banks/instituion in developing countries are moving to deprecate tls v1.0 and tls v1.1.

As I commented on github:
SSLpulse shows how many top websites support tls 1.2 (92.8%) and this
number is increasing (0.5%):

https://www.ssllabs.com/ssl-pulse/

KeyCDN and digicert have also announced their intentions to deprecate
tls 1.0 and tls 1.1.

ht= tps://github.com/sftcd/tls-oldversions-diediedie/commit/a0d6c160d922bd7f52a= 917884823114c90932291



> -Ekr
>
>
> On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty
> <kathleen.moriarty.ietf@gmail.com> wrote:
>>
>> Hello,
>>
>> Stephen and I posted the draft below to see if the TLS working gro= up
>> is ready to take steps to deprecate TLSv1.0 and TLSv1.1.=C2=A0 The= re has
>> been a recent drop off in usage for web applications due to the PC= I
>> Council recommendation to move off TLSv1.0, with a recommendation = to
>> go to TLSv1.2 by June 30th.=C2=A0 NIST has also been recommending = TLSv1.2
>> as a baseline.=C2=A0 Applications other than those using HTTP may = not have
>> had the same reduction in usage.=C2=A0 If you are responsible for = services
>> where you have a reasonable vantage point to gather and share
>> statistics to assess usage further, that could be helpful for the<= br> >> discussion.=C2=A0 We've received some feedback that has been i= ncorporated
>> into the working draft and feelers in general have been positive.= =C2=A0 It
>> would be good to know if there are any show stoppers that have not=
>> been considered.
>>
>> https://github.com/sftcd/tls-oldversions-= diediedie
>>
>> Thanks in advance,
>> Kathleen
>>
>>
>> ---------- Forwarded message ----------
>> From:=C2=A0 <internet-drafts@ietf.org>
>> Date: Mon, Jun 18, 2018 at 3:05 PM
>> Subject: New Version Notification for
>> draft-moriarty-tls-oldversions-diediedie-00.txt
>> To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Kathleen Moriarty >> <Kathleen.Moriarty.ietf@gmail.com>
>>
>>
>>
>> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.= txt
>> has been successfully submitted by Stephen Farrell and posted to t= he
>> IETF repository.
>>
>> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-moriarty-tls-o= ldversions-diediedie
>> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
>> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecating TLSv1.0 and T= LSv1.1
>> Document date:=C2=A0 2018-06-18
>> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
>> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
>> URL:
>>
>> https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions-d= iediedie-00.txt
>>
>> Status:
>> https://datatrack= er.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/
>> Htmlized:
>> https://tools.ietf.o= rg/html/draft-moriarty-tls-oldversions-diediedie-00
>> Htmlized:
>>
>> https://datat= racker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie
>>
>>
>> Abstract:
>>=C2=A0 =C2=A0 This document [if approved] formally deprecates Trans= port Layer
>>=C2=A0 =C2=A0 Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC434= 6] and moves
>>=C2=A0 =C2=A0 these documents to the historic state.=C2=A0 These ve= rsions lack support
>>=C2=A0 =C2=A0 for current and recommended cipher suites, and variou= s government and
>>=C2=A0 =C2=A0 industry profiiles of applications using TLS now mand= ate avoiding
>>=C2=A0 =C2=A0 these old TLS versions.=C2=A0 TLSv1.2 has been the re= commended version for
>>=C2=A0 =C2=A0 IETF protocols since 2008, providing sufficient time = to transition
>>=C2=A0 =C2=A0 away from older versions.=C2=A0 Products having to su= pport older versions
>>=C2=A0 =C2=A0 increase the attack surface unnecessarily and increas= e opportunities
>>=C2=A0 =C2=A0 for misconfigurations.=C2=A0 Supporting these older v= ersions also requires
>>=C2=A0 =C2=A0 additional effort for library and product maintenance= .
>>
>>=C2=A0 =C2=A0 This document updates the backward compatibility sect= ions of TLS RFCs
>>=C2=A0 =C2=A0 [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv= 1.1.=C2=A0 This
>>=C2=A0 =C2=A0 document also updates RFC 7525.
>>
>>
>>
>>
>> Please note that it may take a couple of minutes from the time of<= br> >> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> The IETF Secretariat
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>>
>> _______________________________________________
>> 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


--
<= a href=3D"https://konklone.com" target=3D"_blank">konklone.com | @konklone
--000000000000a134e30570976977-- From nobody Mon Jul 9 15:20:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B1B130DC3 for ; Mon, 9 Jul 2018 15:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFa14dciAXJF for ; Mon, 9 Jul 2018 15:20:16 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45474130E92 for ; Mon, 9 Jul 2018 15:20:12 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 41PfsP50vQz42; Tue, 10 Jul 2018 00:20:09 +0200 (CEST) X-purgate-ID: 152705::1531174809-0000081F-091DFC3F/0/0 X-purgate-size: 1962 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 41PfsM5VL8zGpYp; Tue, 10 Jul 2018 00:20:07 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id AF5BD409B; Tue, 10 Jul 2018 00:20:07 +0200 (CEST) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> To: Andrei Popov Date: Tue, 10 Jul 2018 00:20:07 +0200 (CEST) CC: Eric Rescorla , Kathleen Moriarty , "" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20180709222007.AF5BD409B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 22:20:19 -0000 Andrei Popov wrote: > > On the recent Windows versions, TLS 1.0 is negotiated more than 10% > of the time on the client side (this includes non-browser connections > from all sorts of apps, some hard-coding TLS versions), > and TLS 1.1 accounts for ~0.3% of client connections. "On recent Windows versions" sounds like figure might not account for Windows 7 and Windows Server 2008R2, about half of the installed base of Windows, and where the numbers are likely *MUCH* higher. When troubleshooting TLS handshake failures, I sometimes trying alternative SSL/TLS clients on customer machines through remote support, and it seems when I run this command on a Windows 2012R2 server: powershell "$web=New-Object System.Net.WebClient ; $web.DownloadString('https://www.example.com/')" 2>&1 it connects with TLSv1.0 only, and this is a client-side limitation. To make it use TLSv1.2, I would have to use powershell "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 ; $web=New-Object System.Net.WebClient ; $web.DownloadString('https://www.example.com/')" 2>&1 i.e. explicit opt-in. I already have a long list of stuff that uses TLSv1.0 for outgoing communication by default, and that list is constantly growing, and that is not just stuff running with JavaSE 1.6 or JavaSE 1.7. Btw. lots of J2EE Servers are still on JavaSE 1.6, without the non-public TLSv1.2-capable update. We also had customer incidents about hardware stuff, they called it "RF Gun", probably some RFID scanner, that seems to be limited to TLSv1.0 and TLSv1.0 cipher suites (either 3DES-EDE-CBC-SHA or RC4-128). I would really hate it to see the IETF enter the "planned/forced obsolence" market, growing the dumpsters of electronic equipment that would still work just fine, but has to be retired for the sole purpose of economic growth. -Martin From nobody Mon Jul 9 15:56:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0500127333 for ; Mon, 9 Jul 2018 15:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SfyphFzx8on5 for ; Mon, 9 Jul 2018 15:56:27 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF7F7127332 for ; Mon, 9 Jul 2018 15:56:26 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id k12-v6so39015792oiw.8 for ; Mon, 09 Jul 2018 15:56:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=82Mt6naNQdtOHJO1NtSM4ixlYBIioCta17Qhy2BxcSw=; b=HLPKKHx4EWzH+UArXstmU+7dSHRKqCa8vqCG40EHdMKHZa8uZgKmKfQFS9AMSCEe5g cegiBUz3Bha4oPmkkREySe2XkpFkIt4gMwmY+Mltq6GmkH1qT0gXSK/j2rc7DxrR7bgT P6dm8PoIciy7sKbZhoF8Pd5yhDOVQ5V3u8szSL4ObJiTpZ3HhiVyJBKgQTHU0RRwPCDQ cvwUtfskifXlUGd1B/QTLf3SAqZUPdAKlgGydQHlghpWOESxzrAJb8Mdev5iVIhFTNpo urfSWIhRip6ouP8kp/51zEjBf11gVOIQfeXz/ciuD7q6iGmIZ2FT9Db6vWik2fi3Lr0i f2Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=82Mt6naNQdtOHJO1NtSM4ixlYBIioCta17Qhy2BxcSw=; b=YWPGBT8kSHFefBYo6saK/P+41pwGI8V6vUm+sTjU9sUIRimy+W33k9D+QWpGyNtzQu TnUrpWN1FGzKCbYyqPFyzAX5T6tzNIQRlg/8YvFxyjw+VHDb/zB4Wqy+Uj34FqN+vc2R ca96JG0iS+FaT88htUXyhHRU4uaHxfQl4K50BsLtF8NwgummQuOT17DvUNrLwsRz8pby 8usvygInppykPEXrfy3Kbnj9cHnYiA5woynZq+tM/rW+nioLw8aWV666z9KFuaZ1k3Rc BPcXVO+TdeVJUUk/ZpvABcEWVtAJB2JWz9MIW3OoCNdEolFoNZvM0LUlykUboZMhSKUu Omnw== X-Gm-Message-State: AOUpUlEOXjWMH9VYewi4D3tZxBn8avoY60y2JBJD98fMp5xNYW65Zxw6 RWKFQ/mwVF744eQGwBipliFSB1EE39o5OEre+KQ= X-Google-Smtp-Source: AAOMgpeRcgBuJ/W5GLLjq46P+69vRKaS2ENRUKKUEBfDZcOqogVQ2GyT+MhHQICAPdZRxAruv0Qc5rU7M1rc3Cwc6jE= X-Received: by 2002:aca:df42:: with SMTP id w63-v6mr6811727oig.295.1531176986073; Mon, 09 Jul 2018 15:56:26 -0700 (PDT) MIME-Version: 1.0 References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> In-Reply-To: From: Martin Thomson Date: Tue, 10 Jul 2018 08:56:14 +1000 Message-ID: To: Kathleen Moriarty Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 09 Jul 2018 22:56:30 -0000 I want to see these disappear, but I am guessing that there is still some time before many products can make the move. For websites, like the ones mentioned in the draft, that time is already here. As a site operator, you do not want to talk to a browser that doesn't talk TLS 1.2. Is there any reason why we wouldn't also consider deprecating cipher suites we don't like? For instance, RFC 5246 mandates the implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probably agree isn't ideal for several reasons. The ECDHE suites with AES-GCM are widely available, perhaps widely enough that we might consider a stronger move and update 5246 to modern suites. Our numbers for AES-CBC are not anywhere near as low as TLS <1.2, but they are definitely trending in the right direction. 3DES still exists too, which is a little sad, but there you are. On Tue, Jul 10, 2018 at 2:42 AM Kathleen Moriarty wrote: > > Hello, > > Stephen and I posted the draft below to see if the TLS working group > is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has > been a recent drop off in usage for web applications due to the PCI > Council recommendation to move off TLSv1.0, with a recommendation to > go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 > as a baseline. Applications other than those using HTTP may not have > had the same reduction in usage. If you are responsible for services > where you have a reasonable vantage point to gather and share > statistics to assess usage further, that could be helpful for the > discussion. We've received some feedback that has been incorporated > into the working draft and feelers in general have been positive. It > would be good to know if there are any show stoppers that have not > been considered. > > https://github.com/sftcd/tls-oldversions-diediedie > > Thanks in advance, > Kathleen > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jun 18, 2018 at 3:05 PM > Subject: New Version Notification for > draft-moriarty-tls-oldversions-diediedie-00.txt > To: Stephen Farrell , Kathleen Moriarty > > > > > A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt > has been successfully submitted by Stephen Farrell and posted to the > IETF repository. > > Name: draft-moriarty-tls-oldversions-diediedie > Revision: 00 > Title: Deprecating TLSv1.0 and TLSv1.1 > Document date: 2018-06-18 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf.org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt > Status: > https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/ > Htmlized: > https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie > > > Abstract: > This document [if approved] formally deprecates Transport Layer > Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves > these documents to the historic state. These versions lack support > for current and recommended cipher suites, and various government and > industry profiiles of applications using TLS now mandate avoiding > these old TLS versions. TLSv1.2 has been the recommended version for > IETF protocols since 2008, providing sufficient time to transition > away from older versions. Products having to support older versions > increase the attack surface unnecessarily and increase opportunities > for misconfigurations. Supporting these older versions also requires > additional effort for library and product maintenance. > > This document updates the backward compatibility sections of TLS RFCs > [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This > document also updates RFC 7525. > > > > > 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 > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 9 17:33:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB869130E70 for ; Mon, 9 Jul 2018 17:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l9w0vEMypuEP for ; Mon, 9 Jul 2018 17:33:22 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 14DFD127148 for ; Mon, 9 Jul 2018 17:33:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1531182802; x=1562718802; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KzTNp6qjbkFF6b06zZxCZieyxbryvkT+28KYeyu5SDc=; b=1xOQfv52Bpa4auTkj5Xuvi4hIEwRkKsdkWd0bXbLYghx1HOCoIYraNns KogpBX1TFVK3drn7TlykhufHoio+wZ108st0ffIKekwyguvAqsqrfplhE Qd3eLNkL1B4MeRvEe47MWsyadXDvPoOrl87YcTlUKA/PyCCqSOcJzIkVz e3CZpyxbe1krQOKf+r4gJ6m4LyEWZSROMUcLQutaoTyJDiXVyM7MN+ldj 6bBSaGuDbg0RB5gL2ifujTwWGj8Q4r4y1z5Pz4PSlwA4FBgByhCSfhCcz dLMh5vfcteVjwIVy4IwKLPsJDrjoj1p9qUWLq11UFcjvYPFsA9nFwiij2 A==; X-IronPort-AV: E=Sophos;i="5.51,332,1526299200"; d="scan'208";a="20452134" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 10 Jul 2018 12:33:19 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 10 Jul 2018 12:33:19 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Tue, 10 Jul 2018 12:33:19 +1200 From: Peter Gutmann To: Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAAHUoCAAG4mgIABhdIIgAYN+oCAAawvkA== Date: Tue, 10 Jul 2018 00:33:19 +0000 Message-ID: <1531182771058.21025@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <1530757910178.45400@cs.auckland.ac.nz>, <8417187.FtxZZQNsAt@pintsize.usersys.redhat.com> In-Reply-To: <8417187.FtxZZQNsAt@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 00:33:25 -0000 Hubert Kario writes:=0A= =0A= >There Is No Such Thing As A Trusted Network=0A= =0A= I didn't say "trusted network", I said "isolated, private network". The ty= pe=0A= where, if an attacker has got to the point where they have physical access = to=0A= the area where the network is, they can do far more damage via any kind of= =0A= non-network attack than they could by hauling in computing equipment and=0A= sitting there for hours or days trying to attack the crypto on a particular= =0A= endpoint.=0A= =0A= In addition, the security doesn't have to be theoretically perfect, just go= od=0A= enough. An isolated network is frequently deemed secure enough, taking int= o=0A= account the resources being protected, cost to an attacker, likelihood of a= n=0A= attack via that channel, etc. It's typically much easier to control access= to=0A= a network than to secure every single endpoint on that network, particularl= y=0A= when half of them are a zoo of ethernet-to-something-else converters (if yo= u=0A= want to see a mess of interesting TLS, look at industrial=0A= RS422/485/Profibus/Modbus/Fieldbus/etc to ethernet converters and TCP=0A= gateways, some of those are examples I've used - anonymously - in previous= =0A= messages).=0A= =0A= The best example of this, which I've mentioned in the past because it's nic= ely=0A= illustrative, was a ventilator control that used a 512-bit key for its TLS= =0A= (16-bit device, and it took about 30s for the connection to be established,= =0A= the key size was chosen because it was all the hardware could handle).=0A= =0A= This was perfectly adequate, to get access to it you'd need to break into t= he=0A= facility, get to a network port, grab the key from the device, break out=0A= again, go away and factor it, break in again, get to the network port, fire= up=0A= your attack device, and then... you could switch a ventilator on or off.=0A= =0A= You could also do that by walking down the corridor and flipping a switch.= =0A= =0A= In either case, you've now turned a ventilator in an occasionally-used stoc= k=0A= room on or off. Even the 512-bit key was overkill.=0A= =0A= Peter.=0A= From nobody Mon Jul 9 20:50:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E886F13110C for ; Mon, 9 Jul 2018 20:50:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.203 X-Spam-Level: * X-Spam-Status: No, score=1.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, URI_HEX=1.122] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOgkKPu0oASB for ; Mon, 9 Jul 2018 20:50:51 -0700 (PDT) Received: from mail-lf0-x244.google.com (mail-lf0-x244.google.com [IPv6:2a00:1450:4010:c07::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6309B130EF4 for ; Mon, 9 Jul 2018 20:50:50 -0700 (PDT) Received: by mail-lf0-x244.google.com with SMTP id v22-v6so3524344lfe.8 for ; Mon, 09 Jul 2018 20:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2vIgWT65e/jgJo9SzPMyh7tLVKzQ5kFWfbobNnkPUm0=; b=YSnncr/bqrtBPFeaH8LLeYtkMNw2j7mzR5n1YOIogoAZ5AJUtNhhjwr8GT2dA02knk Kv3ZAeQCl2ajLqdFAxlNf2u5w20o9UYq/99PiYxmplQwwgKpWRh/6pUxUP5m0cykFnp1 /QWHWgnO3pqRlLJgG7s23XYI2XsBLSIVNBIu5vdSK4FTM3dkDZLDZd1isTM1zpPXBiba y5gd98tUrFFvJCTFWJrFsWVDZHTxdAxrZ8q7BrZV1LSh7hLNIY9AFbZu71+HHlF/+yHP VscxQ1SrOBAv9iaBcPizCxT36OZM/AyzGkCfHeslGPek6Ej2vfnLfpVuZO+/hn1GDZC9 h6Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2vIgWT65e/jgJo9SzPMyh7tLVKzQ5kFWfbobNnkPUm0=; b=gTURUf2Y21bcSo9sZrAhc0L7SBr8uI8b7xkfQ43S616S/irgANTL/M4EJ2BKbb74dz 37mA5P4WV021rZRoHGDsCMiFs112KhK0nQco0SmMakNZzmQQmFLgTMfgaUnYycO2vsxz RTYG6zfUtsCakwrj5F63UvqHp+2IqA5sVsyyLTgs9sXOHB4LWpCkLhXrIcFFfNg8wJzR f/6aUM0+9cA66GOHCdX1eMjzQextqC0gYvfE+jwUnwrnAcwfJ2AEz3dHAyIqDu2rmOef STZdRapTVpW2mZtJavgYObMGhN2242DEDOgFLj0GYZt/NsEWyXoGvjrR8//YGbMSNTKG qbNQ== X-Gm-Message-State: APt69E1kqhaZI/+XD26B/1o12RwpfWlTiYkCwSMPAZ7JCssJsrq70vce JBwU33aWu+rJT+K/9VPMz2hnSNOh9mBDdAerHcCLqA== X-Google-Smtp-Source: AAOMgpfupoguCIOTKGwy/OjYILA2XouB/YL44XEyEiMKlQpWQXM6Q0/terBa9kfNUKV2O7OFFZbHTE23YPEDk582eYw= X-Received: by 2002:a19:5a56:: with SMTP id o83-v6mr1275334lfb.50.1531194648438; Mon, 09 Jul 2018 20:50:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:f8d:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 20:50:47 -0700 (PDT) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> From: nalini elkins Date: Tue, 10 Jul 2018 09:20:47 +0530 Message-ID: To: Andrei Popov Cc: Eric Rescorla , Kathleen Moriarty , "" Content-Type: multipart/alternative; boundary="0000000000001a588505709d0902" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 03:50:54 -0000 --0000000000001a588505709d0902 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable >On the recent Windows versions, TLS 1.0 is negotiated more than 10% of the time on the client side (this includes non-browser connections from all sorts of apps, some hard-coding TLS versions), and TLS 1.1 accounts for ~0.3% of client >connections. Windows server negotiates TLS 1.0 ~1.5% of the time (all server apps, not just IIS), and the use of TLS 1.1 is negligible. >Therefore, we cannot disable TLS 1.0 by default in Windows just yet, but will keep looking at the telemetry. If PCI/NIST/diediedie RFC make a difference, I=E2=80=99ll be happy to reduce the set of enabled-by-default T= LS versions. While I support the move to more secure versions of TLS, I would say that in the U.S. at least, is that people are trying as hard as they can to get current. It is not that easy. My data points are the Fortune 500 and equivalent sized government agencies, including city and county governments, even large school districts such as Los Angeles Unified. For at least the last two to four years, quite a few of the people that I know have been trying to get upgraded to TLS1.2 on their own - with no incentive needed. A while back, I was talking to someone I know about the PCI mandate for June 30th. These guys run quite a large network with millions of clients coming in via business partner and other networks. By the time, they get to his applications, he really has no idea what the actual IP address of the end user is and how to reach out to them to get them to upgrade whatever client software they have that is not current. He has a number of his staff devoted to doing just this. The endpoints are not just running browsers. They may have Telnet, FTP, SMTP, MQSeries or any one of a thousand different applications. Each with their own client software which has to be upgraded individually. Keeping endpoints and applications patched and current takes a huge amount of effort - maybe the bulk of the effort - spent by staff at enterprises. The manager of the above site said to me that he knows the PCI date is June 30 to get off of earlier versions of TLS but he said, "You know, Nalini, we may not make it." Those guys are very smart. I have known them for many years My guess would be that it is in the 10 - 20% range for clients using versions pre-TLS1.2. It would be nice to see some of this reflected in the draft rather than only statistics on browsers. The real usage of these protocols is far more complex. Nalini On Mon, Jul 9, 2018 at 11:30 PM, Andrei Popov < Andrei.Popov=3D40microsoft.com@dmarc.ietf.org> wrote: > On the recent Windows versions, TLS 1.0 is negotiated more than 10% of th= e > time on the client side (this includes non-browser connections from all > sorts of apps, some hard-coding TLS versions), and TLS 1.1 accounts for > ~0.3% of client connections. > > Windows server negotiates TLS 1.0 ~1.5% of the time (all server apps, not > just IIS), and the use of TLS 1.1 is negligible. > > > > Therefore, we cannot disable TLS 1.0 by default in Windows just yet, but > will keep looking at the telemetry. If PCI/NIST/diediedie RFC make a > difference, I=E2=80=99ll be happy to reduce the set of enabled-by-default= TLS > versions. > > > > Cheers, > > > > Andrei > > > > *From:* TLS *On Behalf Of * Eric Rescorla > *Sent:* Monday, July 9, 2018 9:57 AM > *To:* Kathleen Moriarty > *Cc:* > *Subject:* Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls= - > oldversions-diediedie-00.txt > > > > > > > > On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla wrote: > > Thanks for writing this. > > > > I would be in favor of deprecating old versions of TLS prior to 1.2. > Firefox Telemetry shows that about 1% of our connections are TLS 1.1 > > > > This should be 1.0. > > > > > > (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. > > > > This is probably a higher number than we'd be comfortable turning off > immediately, but it is probably worth starting the process. > > > > -Ekr > > > > > > On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty < > kathleen.moriarty.ietf@gmail.com> wrote: > > Hello, > > Stephen and I posted the draft below to see if the TLS working group > is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has > been a recent drop off in usage for web applications due to the PCI > Council recommendation to move off TLSv1.0, with a recommendation to > go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 > as a baseline. Applications other than those using HTTP may not have > had the same reduction in usage. If you are responsible for services > where you have a reasonable vantage point to gather and share > statistics to assess usage further, that could be helpful for the > discussion. We've received some feedback that has been incorporated > into the working draft and feelers in general have been positive. It > would be good to know if there are any show stoppers that have not > been considered. > > https://github.com/sftcd/tls-oldversions-diediedie > > > Thanks in advance, > Kathleen > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jun 18, 2018 at 3:05 PM > Subject: New Version Notification for > draft-moriarty-tls-oldversions-diediedie-00.txt > To: Stephen Farrell , Kathleen Moriarty > > > > > A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt > has been successfully submitted by Stephen Farrell and posted to the > IETF repository. > > Name: draft-moriarty-tls-oldversions-diediedie > Revision: 00 > Title: Deprecating TLSv1.0 and TLSv1.1 > Document date: 2018-06-18 > Group: Individual Submission > Pages: 10 > URL: > https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions- > diediedie-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie= / > > Htmlized: > https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 > > Htmlized: > https://datatracker.ietf.org/doc/html/draft-moriarty-tls- > oldversions-diediedie > > > > Abstract: > This document [if approved] formally deprecates Transport Layer > Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves > these documents to the historic state. These versions lack support > for current and recommended cipher suites, and various government and > industry profiiles of applications using TLS now mandate avoiding > these old TLS versions. TLSv1.2 has been the recommended version for > IETF protocols since 2008, providing sufficient time to transition > away from older versions. Products having to support older versions > increase the attack surface unnecessarily and increase opportunities > for misconfigurations. Supporting these older versions also requires > additional effort for library and product maintenance. > > This document updates the backward compatibility sections of TLS RFCs > [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This > document also updates RFC 7525. > > > > > 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 > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > 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 > > --=20 Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com --0000000000001a588505709d0902 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

>On the recent Windows ver= sions, TLS 1.0 is negotiated more than 10% of the time on the client side (= this includes non-browser connections from all sorts of apps, some hard-cod= ing TLS versions), and TLS 1.1 accounts for ~0.3% of client >connections= .=C2=A0 Windows server negotiates TLS 1.0 ~1.5% of the time (all server app= s, not just IIS), and the use of TLS 1.1 is negligible.

=C2=A0

>Therefore, we cannot disable TLS 1.0 by default in Windows just = yet, but will keep looking at the telemetry. If PCI/NIST/diediedie RFC make= a difference, I=E2=80=99ll be happy to reduce the set of enabled-by-defaul= t TLS versions.



While I support the move to more secure versions of = TLS, I=C2= =A0would say that in the U.S. at least,=C2=A0is that people are trying as hard as they can to= get current.=C2=A0 It is not that easy.=C2=A0 My data points are the Fortu= ne 500 and equivalent sized=C2=A0 =C2=A0

government agencies, including city and county governments, ev= en large school districts such as Los Angeles Unified.=C2=A0 =C2=A0For at l= east the last two to four years, quite a few of the people that I know have= been trying to get upgraded to TLS1.2 on their own - with no incentive nee= ded.


A while back, I was talking to someone I know about the PCI ma= ndate for June 30th.=C2=A0 =C2=A0These guys run quite a large network with millions of clients coming in via bu= siness partner and other networks.=C2=A0 By the time, they get to his appli= cations, he really has no idea what the actual IP address of the end user i= s and how to reach out to them to get them to upgrade whatever client softw= are they have that is not current.=C2=A0 He has a number of his staff devot= ed to doing just this.


<= /span>

The endpoints are not just r= unning browsers.=C2=A0 They may have Telnet, FTP, SMTP, MQSeries or any one= of a thousand different applications.=C2=A0 Each with their own client sof= tware which has to be upgraded individually.


Keepin= g endpoints and applications patched and current takes a huge amount of eff= ort - maybe the bulk of the effort - spent by staff at enterprises.=C2=A0 = =C2=A0The manager of the above site said to me that he knows the PCI date i= s June 30 to get off of earlier versions of TLS but he said, "You know= , Nalini, we may not make it."=C2=A0 =C2=A0Those guys are very smart.= =C2=A0 I have known them for many years


My guess would be that it is in th= e 10 - 20% range for clients using versions pre-TLS1.2.

It would be nice to see some of this r= eflected in the draft rather than only statistics on browsers.=C2=A0 =C2=A0= The real usage of these protocols is far more complex.


Nalini=C2=A0

=C2=A0



On Mon,= Jul 9, 2018 at 11:30 PM, Andrei Popov <Andrei= .Popov=3D40microsoft.com@dmarc.ietf.org> wrote:

On the recent Windows versions, TLS 1.0 is negotiate= d more than 10% of the time on the client side (this includes non-browser c= onnections from all sorts of apps, some hard-coding TLS versions), and TLS = 1.1 accounts for ~0.3% of client connections.

Windows server negotiates TLS 1.0 ~1.5% of the time = (all server apps, not just IIS), and the use of TLS 1.1 is negligible.

=C2=A0

Therefore, we cannot disable TLS 1.0 by default in W= indows just yet, but will keep looking at the telemetry. If PCI/NIST/diedie= die RFC make a difference, I=E2=80=99ll be happy to reduce the set of enabl= ed-by-default TLS versions.

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: TLS <tls-bounces@ietf.org> On Behalf Of Eric Rescorla
Sent: Monday, July 9, 2018 9:57 AM
To: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Cc: <tls@ietf.o= rg> <tls@ietf.o= rg>
Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-= tls-oldversions-diediedie-00.txt

=C2=A0

=C2=A0

=C2=A0

On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla <ekr@rtfm.com> wrote:=

Thanks for writing this.

=C2=A0

I would be in favor of deprecating old versions of T= LS prior to 1.2. Firefox Telemetry shows that about 1% of our connections a= re TLS 1.1

=C2=A0

This should be 1.0.

=C2=A0

=C2=A0

(on the same data set, TLS 1.3 is > 5%), and TLS = 1.1 is negligible.

=C2=A0

This is probably a higher number than we'd be co= mfortable turning off immediately, but it is probably worth starting the pr= ocess.

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty &l= t;kat= hleen.moriarty.ietf@gmail.com> wrote:

Hello,

Stephen and I posted the draft below to see if the TLS working group
is ready to take steps to deprecate TLSv1.0 and TLSv1.1.=C2=A0 There has been a recent drop off in usage for web applications due to the PCI
Council recommendation to move off TLSv1.0, with a recommendation to
go to TLSv1.2 by June 30th.=C2=A0 NIST has also been recommending TLSv1.2 as a baseline.=C2=A0 Applications other than those using HTTP may not have<= br> had the same reduction in usage.=C2=A0 If you are responsible for services<= br> where you have a reasonable vantage point to gather and share
statistics to assess usage further, that could be helpful for the
discussion.=C2=A0 We've received some feedback that has been incorporat= ed
into the working draft and feelers in general have been positive.=C2=A0 It<= br> would be good to know if there are any show stoppers that have not
been considered.

https:= //github.com/sftcd/tls-oldversions-diediedie

Thanks in advance,
Kathleen


---------- Forwarded message ----------
From:=C2=A0 <internet-drafts@ietf.org>
Date: Mon, Jun 18, 2018 at 3:05 PM
Subject: New Version Notification for
draft-moriarty-tls-oldversions-diediedie-00.txt
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Kathleen Moriarty
<K= athleen.Moriarty.ietf@gmail.com>



A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt<= br> has been successfully submitted by Stephen Farrell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-moriarty-tls-oldve= rsions-diediedie
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecating TLSv1.0 and TLSv1.1 Document date:=C2=A0 2018-06-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:
https://www.ietf..org/internet-drafts/dr= aft-moriarty-tls-oldversions-diediedie-00.txt
Status:
https://datatracker.ietf.org/doc/draft-moriarty-tl= s-oldversions-diediedie/
Htmlized:
https://tools.ietf.org/html/draft-moriarty-tls-old= versions-diediedie-00
Htmlized:
https://datatracker.ietf.org/doc/html/dr= aft-moriarty-tls-oldversions-diediedie


Abstract:
=C2=A0 =C2=A0This document [if approved] formally deprecates Transport Laye= r
=C2=A0 =C2=A0Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and mo= ves
=C2=A0 =C2=A0these documents to the historic state.=C2=A0 These versions la= ck support
=C2=A0 =C2=A0for current and recommended cipher suites, and various governm= ent and
=C2=A0 =C2=A0industry profiiles of applications using TLS now mandate avoid= ing
=C2=A0 =C2=A0these old TLS versions.=C2=A0 TLSv1.2 has been the recommended= version for
=C2=A0 =C2=A0IETF protocols since 2008, providing sufficient time to transi= tion
=C2=A0 =C2=A0away from older versions.=C2=A0 Products having to support old= er versions
=C2=A0 =C2=A0increase the attack surface unnecessarily and increase opportu= nities
=C2=A0 =C2=A0for misconfigurations.=C2=A0 Supporting these older versions a= lso requires
=C2=A0 =C2=A0additional effort for library and product maintenance.

=C2=A0 =C2=A0This document updates the backward compatibility sections of T= LS RFCs
=C2=A0 =C2=A0[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.=C2= =A0 This
=C2=A0 =C2=A0document also updates RFC 7525.




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

The IETF Secretariat



-- =

Best regar= ds,
Kathleen

__________= _____________________________________
TLS mailin= g list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls

=C2=A0

=C2=A0


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




--
=
Thanks,
Nalini Elkins
= President
Enterprise Data Center Opera= tors

<= /div>
--0000000000001a588505709d0902-- From nobody Mon Jul 9 21:18:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4697A130EF6 for ; Mon, 9 Jul 2018 21:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z_iK6E-9LG6P for ; Mon, 9 Jul 2018 21:17:57 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13629130DC6 for ; Mon, 9 Jul 2018 21:17:56 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 23CCB29AF43; Tue, 10 Jul 2018 00:17:56 -0400 (EDT) Date: Tue, 10 Jul 2018 00:17:56 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180710041755.GD85096@straasha.imrryr.org> Reply-To: tls@ietf.org References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 04:17:59 -0000 On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote: > Is there any reason why we wouldn't also consider deprecating cipher > suites we don't like? For instance, RFC 5246 mandates the > implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probably > agree isn't ideal for several reasons. Is the objection primarily to AES-128-CBC or to RSA key exchange? With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it outperforms AES-256-CBC, and the various CBC issues are resolved via EtM. > The ECDHE suites with AES-GCM > are widely available, perhaps widely enough that we might consider a > stronger move and update 5246 to modern suites. More generally, as noted in RFC7435, you get more security by raising the ceiling than by raising the floor. Breaking the ability to communicate with legacy systems may feel satisfying, but does not generally improve the security of the up-to-date systems, barring downgrade issues in the protocol. Therefore, we should focus on remediating any downgrade exposures, those are serious issues regardless of the mix of supported algorithms, and with downgrade under control, and up-to-date systems preferring stronger algorithms, removal of obsolete algorithms becomes considerably less urgent. They can fade out of use gradually with minimal disruption. Setting the bar too high creates barriers to adoption of security mechanisms. Detailed example below, TL;DR turning off trust in SHA-1 certificates is not always a good idea. For example, I recently learned that current GnuTLS versions by default no longer validate certificates with SHA-1 issuer signatures, and that current versions of Exim linked with these GnuTLS releases fail to validate some DANE-TA(2) chains issued by private-CAs that still use SHA-1. And yet: * CA/B forum public CAs in the various browser bundles no longer issue SHA-1 certificates. https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/ * Furthermore, they now also employ high-entropy unpredictabl serial numbers: https://cabforum.org/2016/03/31/ballot-164/ Thus there is no practical exposure to SHA-1 via the public CA ecosystem, and as the issue is comprehensively addressed on the issuer side. Non-public CAs, on the other hand, are typically already compromised by the time they can be convinced to issue certificates to untrusted strangers, even if the hash algorithm is impeccably strong. If an organization designates its own private CA (that still issues SHA-1 signed certificates) as the trust-anchor for its SMTP servers, it is counter-productive for the verifier[*] to demand greater security connections to that site than the site deems necessary. Thus, ideally, either general purpose TLS libraries (such as GnuTLS) should not yet disable verification of SHA-1 certs in their chain verification code, or else, Exim and other applications need to explicitly override the default settings and re-enable SHA-1. Yes, in practice, given that getting the world to change their deployed systems is hard, also the private CAs using SHA-1 will need to switch to SHA-2 to regain interoperability, despite no actual risk from SHA-1. For the record, SHA-1 use is not common. From the SMTP DANE adoption survey, looking at the 537 distinct leaf certificates of the 655 MX hosts with DANE-TA(2) (issuer-CA rather than the much more popular DANE-EE(3) leaf cert) TLSA records I observe the below signature algorithm frequency: 496 Signature Algorithm: sha256WithRSAEncryption 27 Signature Algorithm: sha512WithRSAEncryption 8 Signature Algorithm: sha1WithRSAEncryption 4 Signature Algorithm: ecdsa-with-SHA256 2 Signature Algorithm: sha384WithRSAEncryption So Exim with recent GnuTLS fails to authenticate 8 MX hosts, serving around 30 domains, due to deprecation of SHA-1 in a context where it is largely unnecessary and is somewhat counter-productive. -- Viktor. [*] The verifier is almost always employing opportunistic DANE TLS, and is even willing to send cleartext when DNSSEC-secure DANE TLSA records are absent and STARTTLS is absent or stripped. Thus the use of mandatory TLS is at the receiving domains's prerogative. Holding the receiing system to a higher security bar than it provisioned is counter-productive. From nobody Tue Jul 10 01:21:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4222130F20 for ; Tue, 10 Jul 2018 01:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wqW8lvBiDuXg for ; Tue, 10 Jul 2018 01:21:09 -0700 (PDT) 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 86040130F25 for ; Tue, 10 Jul 2018 01:21:08 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 212CDBE2F; Tue, 10 Jul 2018 09:21:07 +0100 (IST) 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 qGMEjRE1jGbK; Tue, 10 Jul 2018 09:21:05 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 57DDDBDD8; Tue, 10 Jul 2018 09:21:05 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1531210865; bh=w1hiTCaRctGCDDFaJUcuakdcdnUNMZoo/bhloAa9U+c=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=R6/d12HJXFv26U/ybgfE+z1easCHucSB4zujILCJ++pU5Qsw/2TQF5YvRZNR4by9U A7hNdxvChLZM0g2NkxmRmbtxtK5dPvWL3PAbOmGhsODRD1TbmL05GUI2cf2btm56m3 r+0mliGqiPhz2A984siHVb/5aLDRNHLwvJq+xwGA= To: nalini elkins Cc: "" References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> Date: Tue, 10 Jul 2018 09:21:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="nOM2cpJS94A2R2sca47k5nfSfaFMeGzFQ" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 08:21:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --nOM2cpJS94A2R2sca47k5nfSfaFMeGzFQ Content-Type: multipart/mixed; boundary="pMXvRJxsosykowvyTkP2TNi2lIqHVDcYD"; protected-headers="v1" From: Stephen Farrell To: nalini elkins Cc: "" Message-ID: <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> In-Reply-To: --pMXvRJxsosykowvyTkP2TNi2lIqHVDcYD Content-Type: multipart/mixed; boundary="------------C93C9D33738491B179171406" Content-Language: en-GB This is a multi-part message in MIME format. --------------C93C9D33738491B179171406 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Nalini, On 10/07/18 04:50, nalini elkins wrote: > It would be nice to see some of this reflected in the draft rather than= > only statistics on browsers. The real usage of these protocols is far= > more complex. I didn't have time before the I-D cutoff but have since added a section on mail to the repo pre-01 version. (See [1] section 3.2.) I'd love to add more detail like that and/or more sections for other protocols if folks have data to offer with references. Consistent with other folks' numbers sent to the list yesterday, (though based on a much smaller sat of data I guess;-) my data shows 10.6% use of TLSv1.0 when talking SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K IP addresses that listen on port 25 (mail servers). What I don't currently have is a rate of change for that figure. I think that rate of change is the important number for figuring out what to do in the next while. E.g. The WG might conclude that if the percentage of TLSv1.0 is moving down nicely, we should be a bit patient. If it's not moving at all, we can probably move now or in 5 years without that being different. If we're not sure, then get more data... Cheers, S. [1] https://github.com/sftcd/tls-oldversions-diediedie/blob/master/draft-mori= arty-tls-oldversions-diediedie.txt --------------C93C9D33738491B179171406 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------C93C9D33738491B179171406-- --pMXvRJxsosykowvyTkP2TNi2lIqHVDcYD-- --nOM2cpJS94A2R2sca47k5nfSfaFMeGzFQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAltEbHAACgkQWrL68XsX K+oBfg//e8bK/xG7EPF3c3SKOwDEnJQi5aFbGjyyWSqFHTNFQyrLNLGGytOH1izV 8+r9A9c3nCtuFaJKw7eOQ6gMai176bggOjEOZVmnXN40OUMAMw7Elus0o+1RtC3r UXoRMqihEEHzwxpZl2wqY0Sa2rcxn2CdZAFZV/6pvjTXwaUI6mRoag5DA5in06Yd r9Q5klrXJrFqtjMDPE/E4y3iqMgvIOk/v0RAAvGupDdvsDAlmjJ5IfPxtCdJFVvH Kh0nXxD/uVkgJvwkfZ4pCC92k9u5B0403BZSWhuEEh7V3ZjeqbRh5rxMhthCaf+j 2SWqDau2arWfFUWsVa8UJIopSh/IXumplNLRfoWJawpwUwPrJCaT8Z3AdDNV1CRw trVSTZe8FS4WoKmSF6kPdeXsZt8G+8dXxMCcamhJqHTrZbJgoP1hqkE//u/Fugik iffDzSiGn+k4ex1N301PCZM0b2+9Xfzhy/CHQOoL5Kaccjs3Ytko7Wztp1yIt+xd r0W9heDa4MqrYf8rwt5bpfWWK7xCvNe9eIeZUWAoH+5VE9DB/K0yMyPFAeKcL68m O4sjfVqVa6NK94eot0yZ71vrmDm+3Hn/7BmVmV+RVbgI3p5sAK17D/ZHCmkacNJC MniaJlJJch+LrocPdJSor3c2oqUMRN0I1W3Ss59EQumxHhK5LKA= =HlVw -----END PGP SIGNATURE----- --nOM2cpJS94A2R2sca47k5nfSfaFMeGzFQ-- From nobody Tue Jul 10 05:45:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8FA127598 for ; Tue, 10 Jul 2018 05:45:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vDw0w_FZja3y for ; Tue, 10 Jul 2018 05:45:18 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDBA126BED for ; Tue, 10 Jul 2018 05:45:18 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 328BA4070486; Tue, 10 Jul 2018 12:45:17 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1A45A111AF1D; Tue, 10 Jul 2018 12:45:15 +0000 (UTC) From: Hubert Kario To: =?ISO-8859-1?Q?Bj=F6rn?= Haase Cc: Peter Gutmann , "tls@ietf.org" Date: Tue, 10 Jul 2018 14:45:05 +0200 Message-ID: <5229868.Eh3Akk7WAq@pintsize.usersys.redhat.com> In-Reply-To: References: <1530687136897.97792@cs.auckland.ac.nz> <1531182771058.21025@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2942853.07V4BSAYrt"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 10 Jul 2018 12:45:17 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 10 Jul 2018 12:45:17 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 12:45:20 -0000 --nextPart2942853.07V4BSAYrt Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 10 July 2018 08:47:15 CEST Bj=C3=B6rn Haase wrote: > > Peter Gutmann wrote: > >In addition, the security doesn't have to be theoretically perfect, just > >good enough. An isolated network is frequently deemed secure enough, > Mostly in my analysis the assumption of the "isolation" of the network is= a > security-misconception making setups vulnerable. You just need a network > plug and an own wireless device for making the plant remotely vulnerable. > While I agree that in most cases permanent physical access to a plant by = an > attacker is unlikely, I consider it clearly feasible for the adversary to > have short-time access to an installation. exactly, and plopping down an Ethernet to M2M gateway is something that wil= l=20 require access once and doesn't even require a knowledgeable attacker (vari= ant=20 of Evil Maid attack essentially) > >(16-bit device, and it took about 30s for the connection to be establish= ed, > >the key size was chosen because it was all the hardware could handle). > BTW, This is actually why we in the ICS business need TLS1.3 with its fast > options on tiny devices such as X25519 and Ed25519. That's by integer > factors faster on devices such as the M0 or the MSP430 than all of the > fastest legacy options, such as P256! >=20 > Yours, >=20 > Bj=C3=B6rn >=20 > P.S.: >=20 > Also in my perception, we clearly need a PAKE option for ICS use, both as > replacement for PSK for machine2machine interfaces and for true > operator-account logins. We currently cannot to rely on a properly > installed PKI in ICS environments. given what you said above, it sounds to me, like the PAKE in question shoul= d=20 use negotiation for group (curve) selection, wouldn't it? =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2942853.07V4BSAYrt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltEqlEACgkQkqjRuAHS 9fWxHA//fHeHGHvqWVG8mWeVCxuaJvHZtcjt43MsOX2vdFXSy0JrEWIgZaEcdyu3 +c2ei3HiRov2u0qz61jx7I8l04SfZyl/YOKZCxMps3Plw7bnEEHbB0wRcStDEs8W hU7+SbsP6BzPGYyM4ZWKOYgZfgeCOYomG3+gBiKt3TaKRSVBWxyVKGfTnRwVygmN ZhHPrhtKP2ClYWWM/hTg/w3HYQRDswkKI55B3SWbCSOcWy4ERVUU5ywXFqSfKDb7 Wl5SzorNVvcHysxyqQOzEXS+EvmQ7BzgchYUezIPS7ZI+1xhhAf0Km1yWBOJYtfk cYXB3ULBUGIwg6JlMdMlxTqvbSOX4PQNr2CuWKXFpCjVZrXVHxQ781t3oLgp79f3 SfiIIq2eC6zcGzWjNaATXNQI0k2TCp1LeS70FdBfijhBT7dcGIMq2BoSL7zuhXyA W8dBhs0pN8xIeEL/3jlipMf0Cp8I0I1+8PdzXgoiJTtQspHfN+Ol/KPou1VF0H0t KHJO3e/TBP9E19ae/9UxkXa/XKhVZSfR2X3mek7JxpbtG6IWRM9NavdSgE++lDuP whQg7vbV462L6K4gXrkAForGUgmAMef9rzzqtfqML9xfSK3k23Nxnpi4pHt4u/xa TcRge8CvRUXlfVWaftGlUlFO75TS8YknuknyMmhSjZBP3+XQK0E= =WTsR -----END PGP SIGNATURE----- --nextPart2942853.07V4BSAYrt-- From nobody Tue Jul 10 06:27:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93D95130E78 for ; Tue, 10 Jul 2018 06:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ra5XptyBeWkh for ; Tue, 10 Jul 2018 06:27:47 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 2849D130E9F for ; Tue, 10 Jul 2018 06:27:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1531229266; x=1562765266; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lxlbLXQraw6C66VaGbkHLSiKyZZE85W8+gWgY0Y9gnE=; b=zNpWPKaQE4Kz4cdvO0Q8qmK1tc9/dX8UTWVOJYuPpNyxm+jzkPQD3pM/ vVj97qaGKGSozDRwEAoWRNH4DrAuwYCUebBRXLJDXbTjyHmV4WewDAGlg x53LylQk+M0hyNptakMekiRQy2qRBv0B+YkCS6ahommmU0UwBu7+wCZ8i Sy1RZprzppLxJB9IclTSRV0NG1Z9qrXSWdgxAKJxVlF9yxI7zJzvoFZXk Me1k/zS4SwhpaZhElsmK058ek93VBMN2PAtaXE4Wcy3TcIhFSUh6PEXGI QChMA+t6mjx3ALVbZP6GCsQBmqzpmgkmBhOKZ48DMfhF2pm5LQohxqhcg A==; X-IronPort-AV: E=Sophos;i="5.51,334,1526299200"; d="scan'208";a="20546415" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jul 2018 01:27:41 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 11 Jul 2018 01:27:40 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 11 Jul 2018 01:27:40 +1200 From: Peter Gutmann To: =?iso-8859-1?Q?Bj=F6rn_Haase?= , "Hubert Kario" , "tls@ietf.org" Thread-Topic: [TLS] Broken browser behaviour with SCADA TLS Thread-Index: AQHUE2JmEGgXYKCP9EqF19k6tdX1YKR92r8AgAAKB4CAAM2CYv//PBOAgAAHUoCAAG4mgIABhdIIgAYN+oCAAawvkP//n++AgAE4ogk= Date: Tue, 10 Jul 2018 13:27:40 +0000 Message-ID: <1531229231537.52372@cs.auckland.ac.nz> References: <1530687136897.97792@cs.auckland.ac.nz> <1530757910178.45400@cs.auckland.ac.nz>, <8417187.FtxZZQNsAt@pintsize.usersys.redhat.com> <1531182771058.21025@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Broken browser behaviour with SCADA TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 13:27:51 -0000 Bj=F6rn Haase writes:=0A= =0A= >BTW, This is actually why we in the ICS business need TLS1.3 with its fast= =0A= >options on tiny devices such as X25519 and Ed25519. That's by integer fact= ors=0A= >faster on devices such as the M0 or the MSP430 than all of the fastest leg= acy=0A= >options, such as P256!=0A= =0A= How are you going to get TLS running on an MSP430 or even an M0? You can= =0A= barely do anything on an MSP430 (it's enough of a challenge getting a TCP/I= P=0A= stack going on that, uIP is a rather clever piece of programming but beyond= =0A= that you can barely serve web pages from it), and an M0 isn't much better.= =0A= =0A= See specifically p.12 of=0A= https://www.cs.auckland.ac.nz/~pgut001/pubs/problems.pdf for the MSP430 (th= ose=0A= slides predate this thread by a number of years, so it's not something I've= =0A= set up just for this thread).=0A= =0A= I would actually love to see a TLS 1.3 implementation on an MSP430. As far= as=0A= I know it's physically impossible, but if someone did it it'd be both=0A= fascinating and horrifying to see what they had to do to make it work.=0A= =0A= In any case it's not the crypto that's the problem, the biggest code and=0A= memory issues are, in order:=0A= =0A= 1. Certificates.=0A= 2. The TLS protocol.=0A= 3. The crypto.=0A= =0A= where (1) >> (2) >> (3). That's why I mentioned in a previous message=0A= implementations that use memcpy() for their cert management, which eliminat= es=0A= (1). To process the cert / cert chain, you scan the network read buffer fo= r=0A= the string "\x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x01" and copy out the = two=0A= integers that follow, so your cert processing is reduced to a few pages of= =0A= code (the thinking behind this is explained on p.23 of the same slide set).= =0A= =0A= Then you've got (2), which has been getting more and more problematic with= =0A= each rev of the spec as more and more options get added with each new rev.= =0A= Luckily you can fast-path the single option you want to support, for exampl= e=0A= for TLS 1.2 with DHE+RSA you don't need extensions, and if you can do ECC a= nd=0A= see an ECC suite in the client hello then you ignore the incoming TLS=0A= extensions and write back a fixed blob specifying -256 for everything (P256= ,=0A= SHA256, etc), uncompressed points, and so on. Another thread mentioned tha= t=0A= you can't do TLS 1.2 without extensions, when in fact you can, you just rel= y=0A= on the fact that everything supports -256 by default. (This is also why -L= TS=0A= makes the -256 otions a MTI, it's the de facto default anyway).=0A= =0A= This is where 1.3 is a problem, not a feature. It's now got so much MTI=0A= complexity, most of which is completely unnecessary for SCADA, that any min= or=0A= gain you might make in the crypto implementation is completely lost in the = TLS=0A= protocol implementation overhead.=0A= =0A= I don't know how vendors are going to deal with this. There'll be some tri= cks=0A= used, like the TLS 1.2 "extension handling", but I don't know about the res= t.=0A= My guess is they'll stay with 1.2, in the same way that they're staying wit= h=0A= HTTP 1.1 when 2.0 exhibited the same problems.=0A= =0A= Having said that: "Predictions are always difficult to make, especially abo= ut=0A= the future".=0A= =0A= Peter.=0A= From nobody Tue Jul 10 06:38:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B490130E9D for ; Tue, 10 Jul 2018 06:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cMzCtSaaQp-T for ; Tue, 10 Jul 2018 06:38:45 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CEC021277BB for ; Tue, 10 Jul 2018 06:38:44 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 23E8C8A3CE; Tue, 10 Jul 2018 13:38:44 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 9A6D7111AF22; Tue, 10 Jul 2018 13:38:43 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 10 Jul 2018 15:38:42 +0200 Message-ID: <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> In-Reply-To: <20180710041755.GD85096@straasha.imrryr.org> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <20180710041755.GD85096@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2876690.A7iOJg2S2i"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 10 Jul 2018 13:38:44 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.2]); Tue, 10 Jul 2018 13:38:44 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 13:38:48 -0000 --nextPart2876690.A7iOJg2S2i Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote: > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote: > > Is there any reason why we wouldn't also consider deprecating cipher > > suites we don't like? For instance, RFC 5246 mandates the > > implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probably > > agree isn't ideal for several reasons. >=20 > Is the objection primarily to AES-128-CBC or to RSA key exchange? > With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it > outperforms AES-256-CBC, and the various CBC issues are resolved > via EtM. >=20 > > The ECDHE suites with AES-GCM > > are widely available, perhaps widely enough that we might consider a > > stronger move and update 5246 to modern suites. >=20 > More generally, as noted in RFC7435, you get more security by raising > the ceiling than by raising the floor. Breaking the ability to > communicate with legacy systems may feel satisfying, but does not > generally improve the security of the up-to-date systems, barring > downgrade issues in the protocol. The github version of the document points out that the security of TLS 1.2= =20 downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1. that is the downgrade issue in the protocol https://github.com/sftcd/tls-oldversions-diediedie/blob/ bd6bdc37ec258094f1e1010fba19e8763f2beaee/draft-moriarty-tls-oldversions- diediedie.txt#L142-L145 =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2876690.A7iOJg2S2i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltEtuIACgkQkqjRuAHS 9fXF0A/8C90ij0jLJyEdIKyBVohWi9Xen5aOOXsexL5yqyrNmWXXIuJuZIZK6FWi a5jqC9btNWYZVzTJfwrDff0A81xzjIgkIU4mJZwNrCsfKtsvTLr/bUCBLcZ/qoEc pCMH8k+dmC52trY7UOibAXIRIp5WW4HY/LEhnumEpRREom8ym49k8JEFEd8h7naO NbqMiwEuV3csLeGew5fip0a089tnSizIfGchsiNxDGIPQq+IGcNcGB8xteEbvq+y 0aKj920MiKpRa7FQpEjsH/buIYc0eZ9Ex8VPqOl9TO3gem2ue35QmlUjMUglom2E f8Q/NC/PNnZd7qDAiSUA/oNpxD9uaG4DVxmBWMbFOkkTKIe0dP3Irx25G2DHi1ne Z1Jc2XgnwbQFOQiE5Q3O5/O+Ia1EbxzdxdnTvdyKA/pf/xwrg3w5nuTAnQ6L8tIL KNNLSs7kCO6+yl8Fz6yPlZQYzb46CfaEo5yhwTJuX3yShtHCn9ng4Ztopza16AXb f2EfGfq/METtpkLZdFAxfxLYJt0KRZXd27fSA4BgHqjJI2onE2d1Pu457DKIk7sl lgr2gx1PiXrLeO/nRi0RJZufsNuTC4TBTUqZJjmZs9+NU37hVANPs4sn8yo6hYmH JMqjW4KbHxR0fhLyOsMvJkzHTArtJ0bj+djQcbZtmEU9USW3juw= =R8YV -----END PGP SIGNATURE----- --nextPart2876690.A7iOJg2S2i-- From nobody Tue Jul 10 07:04:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7242B130EBB for ; Tue, 10 Jul 2018 07:04:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MufFR52esHqC for ; Tue, 10 Jul 2018 07:04:06 -0700 (PDT) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED54F130E8C for ; Tue, 10 Jul 2018 07:04:05 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id s1-v6so8637959ybk.3 for ; Tue, 10 Jul 2018 07:04:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+n6c1v5+nxrOFg8DGrf0N3MTVcZTBo+9mQKPvz4pnYE=; b=mx1bxyhFerQQQhO6f5hG/feKdSqGWjOqKc1jOq4k/F7Gu5yC8aX+IWF9EjNn6lEcrR 9sfeOgX8pkOifTZOiCII3aqiC2v+N+kXCUl0xMFJJ+QC5JeR76YJ1VzvI+Y24oHy9oUF pipNHDBvt/e6BoKtHHT4Pluuc9Lkg0sjOcz9G7mBqsXCW4TL6mn7JDDGYAHErYDTRPW9 ppO2ftvaNjLNa6DqteUCChykJEO/Y+0J+k036YKKc4jY0m2XrtPqGJYHSCQBZ0NwQC5+ Mlf/EIFQaPBxOnyNw29Q5iFFkoYkki7N2xlFh59+NGQu3hunJlKFVbMz3VP0meoAu9BP 4bsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+n6c1v5+nxrOFg8DGrf0N3MTVcZTBo+9mQKPvz4pnYE=; b=AM1EumHgHbxnNEKTqo832hmpmfL/F57qZ+vw2Kk+/OOo9m7ZDIywOvJZK21AWJXx5B kfxfNbvJdFYHVQAcZjK7BYf/9lTDR3xh1g/vROhRQ7/UlDzYdP/+1GaIEuVPvkucuIws lZZ8DF06rfhBtmKjmLvp+V/QMb+J6HRoeDHpcKBY+rd2haq2zHLHFo9wxY28CnPYjj4w Pj7mGPN2N8rB9xgt+ipevaY10CbHXG1mPHTCV9G/0WG3cwfh1t9fo/5s9D27iS8kGX1z c/e9Qn7Gz+uFnbB+lmPT/z+yeC75XnOsljbTGlerWlKyfHXP/1NZXYiuaW6kXDhbso8O 6dBw== X-Gm-Message-State: APt69E11Oa4o7TthYJx5uleuGHkhZWeal7Fq1lfzBEk107nZ8w3Tuw98 iFZCEeOc2a/A6XPt0nFWntULqdPlu2c4jGJuDWoEoQ== X-Google-Smtp-Source: AAOMgpc/w2agjADwdhv5Gpo0VUtvJ/iew9bVeV3gKAKrP9B3XnDsUSvL40o8nNvx947FH8YT1qE0eG4Lq7rMb9X8Spo= X-Received: by 2002:a25:9a49:: with SMTP id r9-v6mr12710313ybo.451.1531231445139; Tue, 10 Jul 2018 07:04:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 07:03:24 -0700 (PDT) In-Reply-To: <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <20180710041755.GD85096@straasha.imrryr.org> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Tue, 10 Jul 2018 07:03:24 -0700 Message-ID: To: Hubert Kario Cc: "" Content-Type: multipart/alternative; boundary="0000000000005b63280570a59a8f" Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 14:04:10 -0000 --0000000000005b63280570a59a8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario wrote: > On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote: > > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote: > > > Is there any reason why we wouldn't also consider deprecating cipher > > > suites we don't like? For instance, RFC 5246 mandates the > > > implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probably > > > agree isn't ideal for several reasons. > > > > Is the objection primarily to AES-128-CBC or to RSA key exchange? > > With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it > > outperforms AES-256-CBC, and the various CBC issues are resolved > > via EtM. > > > > > The ECDHE suites with AES-GCM > > > are widely available, perhaps widely enough that we might consider a > > > stronger move and update 5246 to modern suites. > > > > More generally, as noted in RFC7435, you get more security by raising > > the ceiling than by raising the floor. Breaking the ability to > > communicate with legacy systems may feel satisfying, but does not > > generally improve the security of the up-to-date systems, barring > > downgrade issues in the protocol. > > The github version of the document points out that the security of TLS 1.= 2 > downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1. > Well, yes and no. If you allow static RSA, then yes. If you require (EC)DHE, then the anti-downgrade measures in the TLS 1.3 random values are intended to protect against downgrade even if SHA-1 is compromised (because the randoms are signed). -Ekr > that is the downgrade issue in the protocol > > https://github.com/sftcd/tls-oldversions-diediedie/blob/ > bd6bdc37ec258094f1e1010fba19e8763f2beaee/draft-moriarty-tls-oldversions- > diediedie.txt#L142-L145 > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --0000000000005b63280570a59a8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario <hkario@redhat.com&g= t; wrote:
On Tues= day, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote:
> On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:
> > Is there any reason why we wouldn't also consider deprecating= cipher
> > suites we don't like?=C2=A0 For instance, RFC 5246 mandates t= he
> > implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can prob= ably
> > agree isn't ideal for several reasons.
>
> Is the objection primarily to AES-128-CBC or to RSA key exchange?
> With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it > outperforms AES-256-CBC, and the various CBC issues are resolved
> via EtM.
>
> > The ECDHE suites with AES-GCM
> > are widely available, perhaps widely enough that we might conside= r a
> > stronger move and update 5246 to modern suites.
>
> More generally, as noted in RFC7435, you get more security by raising<= br> > the ceiling than by raising the floor.=C2=A0 Breaking the ability to > communicate with legacy systems may feel satisfying, but does not
> generally improve the security of the up-to-date systems, barring
> downgrade issues in the protocol.

The github version of the document points out that the security of T= LS 1.2
downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.

Well, yes and no. If you allow static RSA, then yes.= =C2=A0 If you require (EC)DHE, then the anti-downgrade measures in the TLS = 1.3 random values are intended to protect against downgrade even if SHA-1 i= s compromised (because the randoms are signed).

-Ekr


that is the downgrade issue in the protocol

https://github.com/sftcd/tls-oldversion= s-diediedie/blob/
bd6bdc37ec258094f1e1010fba19e8763f2beaee/draft-moriarty-tls-oldve= rsions-
diediedie.txt#L142-L145
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--0000000000005b63280570a59a8f-- From nobody Tue Jul 10 07:07:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26D3E130ED8 for ; Tue, 10 Jul 2018 07:07:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MHTnkAWanTw for ; Tue, 10 Jul 2018 07:07:12 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 E312A130E8C for ; Tue, 10 Jul 2018 07:07:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1531231632; x=1562767632; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zpSpHXezA+aPurgfZkhgSM0rTNC4GhSMwRr7JTZvugE=; b=TYrH7AwwiClnVShLrJ5GqJa9gWqI5GNFvaMPLQqIjr7oGMgEdEKMFDRN LyqLj6N4X+So2PudwU5CcZiZrf0xqGEmafrtB0yVJNj6iRFdWnLbywD8m cWSv49jweOlMSBUlrar0zmO1OvOrRMymzTE5ajlTo4ITfnBFvK8aVlcsg zPFAxRUsw9nmnob/E3QkZsuuIY+088nmMLuojnueUVfuUu1YcKcKeZiiX 3xMfigGAs3BzaNiO3Mt2nWTlAPP/KLgcQ7A/e0Hp6qSLFrYlwzgFFPIYs /y5XoePUDabDaRQIrmu7ITWdtkv+dgsLwhO1h/zvouOWwjNo4sJRAUVHl A==; X-IronPort-AV: E=Sophos;i="5.51,334,1526299200"; d="scan'208";a="20549578" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-d.UoA.auckland.ac.nz) ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jul 2018 02:07:07 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 11 Jul 2018 02:07:07 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 11 Jul 2018 02:07:07 +1200 From: Peter Gutmann To: nalini elkins , Andrei Popov CC: "" Thread-Topic: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt Thread-Index: AQHUF6PVAxx3DOA9AUm84Ewr2PjBn6SGUp+AgAAAxoCAABGKAIAApP2AgAF0KNo= Date: Tue, 10 Jul 2018 14:07:06 +0000 Message-ID: <1531231597254.2616@cs.auckland.ac.nz> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 14:07:14 -0000 nalini elkins writes:=0A= =0A= >It would be nice to see some of this reflected in the draft rather than on= ly=0A= >statistics on browsers. The real usage of these protocols is far more=0A= >complex.=0A= =0A= +1. It often seems that the only possible use for TLS that gets considered= in=0A= these things is web browsers and web servers, or big-iron type servers in= =0A= general. There's a vast amount of TLS that never goes anywhere near a brow= ser=0A= or server of this kind. In particular, the assumptions that are no longer= =0A= valid in this case are:=0A= =0A= - CPU and memory is nearly unlimited and nearly free.=0A= =0A= - Anything can be easily upgraded at the touch of a button.=0A= =0A= - Everyone gets their certs from a commercial CA (that's present in a trust= =0A= database).=0A= =0A= - People want the most full-featured, complex protocol possible.=0A= =0A= - Users want the latest, trendiest algorithms at all times.=0A= =0A= [Feel free to add more to this list, that's just the stuff that springs=0A= immediately to mind].=0A= =0A= In the case of SCADA/embedded, pretty much the exact opposite of all of tho= se=0A= points is the case (the last may be somewhat debatable, it's a reference to= =0A= the fact that industry groups are very conservative and tend to stick with= =0A= something that has what's regarded as good provenance).=0A= =0A= Peter.=0A= From nobody Tue Jul 10 07:09:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B614B130FB7 for ; Tue, 10 Jul 2018 07:09:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwOUREPosTDW for ; Tue, 10 Jul 2018 07:09:08 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73F46130E9F for ; Tue, 10 Jul 2018 07:09:07 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id y11-v6so8635466ybm.7 for ; Tue, 10 Jul 2018 07:09:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+I9vr3wMRlP0lg2yPTWWKvkHyLt3p71BCdcPMUcGqpY=; b=VThNDjnA16eKOk2Z8J7QSUM3TzWsD9Ng3MX98+4aFADD1xD8VXVk5WsSB6I0TK9LPQ 0d53I/i5Mye/gOE1jrXuQO6gGFAynXYiYEt+VmcYirxugADgZPTdc7dWM1WKs7ssnAyY W0au13avi6Gd0fjA8s22DJhVznlRfQ/M3kXq8oSDrPywtOQHPf2c4OgswAQTo8mJ9Cbc XWrFK4LK2qmRVO811taqKoB/b2i3XLW/RjRSXktvl10xos9S7Tv26zZzPU0xAwS0jPbI 2AO6VlbAD4hZ+gWzuwYuyMztPa4wGX+MQuoI544/IbQEn+QiIfolaPLgkq8GFsfos/Es AHZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+I9vr3wMRlP0lg2yPTWWKvkHyLt3p71BCdcPMUcGqpY=; b=NkJUX+DpRmTtVe98xrfOTOsrIg5OBQSjGK88U+3i+ddcC6rxMMnR/A/9S8NHYhmbqi SwlP/RNznqxKrm74usirhRXAuGw9AGfqWNNW0xABWWoNvB1C4IP/Wxl+sQinFNWCtU7g Uu82D613zbEbneHv/xk5UB44af5WhHYDTPE29dz7NWQiPuN2Sw+QTXhzZmL00hHCC+BC 8ehpsIvqxLhjlmiQLpcjmT8wSKpsrTVz9KE27fi7yamHxMihWmiPERpncE0xJVBYXMkq NG+fhoewo8+toYN/2hyfNvbkkvvjedX9DQkKGiGe/c++0cS8sz3ETB6bi6J83sUkp4yc fDyQ== X-Gm-Message-State: APt69E3can/dYrydDN8JJoQlgu44i2JrqRyNanuVd+JljO9kjaJ75UB7 O0CxBwr7nZPBl7ynJ8Fpc0A4n2jnVP0pbGChj/xbvw== X-Google-Smtp-Source: AAOMgpeIvV86v7K/JyzXhUG1J3RsEUcwwRypl77+FxYXAlcMBOS3WNqfSmZpdfa2qzG6yDdaN7EKgWm2/J0Oc4D9vY4= X-Received: by 2002:a25:adcb:: with SMTP id d11-v6mr13726300ybe.73.1531231746651; Tue, 10 Jul 2018 07:09:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 07:08:25 -0700 (PDT) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <20180710041755.GD85096@straasha.imrryr.org> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Tue, 10 Jul 2018 07:08:25 -0700 Message-ID: To: Hubert Kario Cc: "" Content-Type: multipart/alternative; boundary="000000000000540dcf0570a5acd9" Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 14:09:11 -0000 --000000000000540dcf0570a5acd9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Foillowing up: of course this doesn't protect you from 1.2 -> 1.0 downgrade unless you backport the mechanism to your 1.2 implementation, which I expect many people will not do, despite the specs. -Ekr On Tue, Jul 10, 2018 at 7:03 AM, Eric Rescorla wrote: > > > On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario wrote: > >> On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote: >> > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote: >> > > Is there any reason why we wouldn't also consider deprecating cipher >> > > suites we don't like? For instance, RFC 5246 mandates the >> > > implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probabl= y >> > > agree isn't ideal for several reasons. >> > >> > Is the objection primarily to AES-128-CBC or to RSA key exchange? >> > With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it >> > outperforms AES-256-CBC, and the various CBC issues are resolved >> > via EtM. >> > >> > > The ECDHE suites with AES-GCM >> > > are widely available, perhaps widely enough that we might consider a >> > > stronger move and update 5246 to modern suites. >> > >> > More generally, as noted in RFC7435, you get more security by raising >> > the ceiling than by raising the floor. Breaking the ability to >> > communicate with legacy systems may feel satisfying, but does not >> > generally improve the security of the up-to-date systems, barring >> > downgrade issues in the protocol. >> >> The github version of the document points out that the security of TLS >> 1.2 >> downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1. >> > > Well, yes and no. If you allow static RSA, then yes. If you require > (EC)DHE, then the anti-downgrade measures in the TLS 1.3 random values ar= e > intended to protect against downgrade even if SHA-1 is compromised (becau= se > the randoms are signed). > > -Ekr > > >> that is the downgrade issue in the protocol >> >> https://github.com/sftcd/tls-oldversions-diediedie/blob/ >> bd6bdc37ec258094f1e1010fba19e8763f2beaee/draft-moriarty-tls-oldversions- >> diediedie.txt#L142-L145 >> -- >> Regards, >> Hubert Kario >> Senior Quality Engineer, QE BaseOS Security team >> Web: www.cz.redhat.com >> Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > --000000000000540dcf0570a5acd9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Foillowing up: of course this doesn't protect you= from 1.2 -> 1.0 downgrade unless you backport the mechanism to your 1.2= implementation, which I expect many people will not do, despite the specs.=

-Ekr


On Tue, Jul 10, 2018 at 7:03 AM, Er= ic Rescorla <ekr@rtfm.com> wrote:


On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario <hka= rio@redhat.com> wrote:
On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote:
> On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:
> > Is there any reason why we wouldn't also consider deprecating= cipher
> > suites we don't like?=C2=A0 For instance, RFC 5246 mandates t= he
> > implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can prob= ably
> > agree isn't ideal for several reasons.
>
> Is the objection primarily to AES-128-CBC or to RSA key exchange?
> With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it > outperforms AES-256-CBC, and the various CBC issues are resolved
> via EtM.
>
> > The ECDHE suites with AES-GCM
> > are widely available, perhaps widely enough that we might conside= r a
> > stronger move and update 5246 to modern suites.
>
> More generally, as noted in RFC7435, you get more security by raising<= br> > the ceiling than by raising the floor.=C2=A0 Breaking the ability to > communicate with legacy systems may feel satisfying, but does not
> generally improve the security of the up-to-date systems, barring
> downgrade issues in the protocol.

The github version of the document points out that the security of T= LS 1.2
downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.

Well, yes and no. If you allow static RSA, the= n yes.=C2=A0 If you require (EC)DHE, then the anti-downgrade measures in th= e TLS 1.3 random values are intended to protect against downgrade even if S= HA-1 is compromised (because the randoms are signed).

-Ekr


that is the downgrade issue in the protocol

https://github.com/sftcd/tls-oldversion= s-diediedie/blob/
bd6bdc37ec258094f1e1010fba19e8763f2beaee/draft-moriarty-tls-oldve= rsions-
diediedie.txt#L142-L145
--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00=C2=A0 Brno, Czech Republic=
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--000000000000540dcf0570a5acd9-- From nobody Tue Jul 10 07:17:04 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65457130FB7 for ; Tue, 10 Jul 2018 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0DXrAmboTUH for ; Tue, 10 Jul 2018 07:17:00 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 892B0130DFD for ; Tue, 10 Jul 2018 07:16:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1531232219; x=1562768219; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mhmGDcvCBMNfRO+v/KF7icKdx+7o1IP7CMpw3Q1k/oY=; b=IAHwLOzAgrH496u9K3vO9wmwewYWpHI6XgcrJmAk2GvVP2ggpy+O4Nvg zlpLLt+e8rUGnCBXlg64lUFWjLiGOOo/y5oidKVsXnfVaiY29cnU2ksQW WR8anzherdimnHR6b6EzYYJzBn5c5ca9J/FaiX1/k3NWtLXvdYOTZYhUI tZxgvtpihzf3SdwC/VNVLnY0ihtAvpA+VO7niK6Ng/cCQqMLKgF3jqZFx kDXQY7N6TACon6Mia3A+i5Gg3cnqlgcw/wPDev7Bq6PSOdVP1XVf1WZiG HwraHq+86aJYxo64Hw3CYyR7M5Dyj+zOSukU42SaFhtXI7VNrYq1D4O2R A==; X-IronPort-AV: E=Sophos;i="5.51,334,1526299200"; d="scan'208";a="20550337" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-c.UoA.auckland.ac.nz) ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jul 2018 02:16:57 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.24) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 11 Jul 2018 02:16:57 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 11 Jul 2018 02:16:57 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) Thread-Index: AQHUGAUQdiSASvczzEuVqjvTCb06AaSIgPnd Date: Tue, 10 Jul 2018 14:16:57 +0000 Message-ID: <1531232188822.83601@cs.auckland.ac.nz> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> , <20180710041755.GD85096@straasha.imrryr.org> In-Reply-To: <20180710041755.GD85096@straasha.imrryr.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 14:17:03 -0000 Viktor Dukhovni writes:=0A= =0A= >also the private CAs using SHA-1 will need to switch to SHA-2 to regain=0A= >interoperability, despite no actual risk from SHA-1.=0A= =0A= Another problem with moving to SHA-2 is that when you have a lot of gear th= at=0A= only does SHA-1, you need to run parallel PKIs possibly in perpetuity, one= =0A= using SHA-1 and the other SHA-2. For example if you're signing CRLs then y= ou=0A= have SHA-2-signed ones and SHA-1-signed ones, and then the CA/signing certs= in=0A= turn have to be signed with SHA-1 or SHA-2, and the CA certs for those have= to=0A= be SHA-1 or SHA-2, and you can see what a headache that ends up being, not= =0A= just in terms of running two PKIs but also the fact that you've now got lot= s=0A= of apparently duplicated certs that differ only in their hash algorithm. O= r=0A= you can use different keys, but now you also need to change the DNs otherwi= se=0A= sigs on the SHA-1 branch won't verify on the SHA-2 branch. No matter how y= ou=0A= look at it, you end up with a mess.=0A= =0A= (Luckily this sort of thing is Someone Else's Problem, and I don't envy the= m=0A= for it).=0A= =0A= Peter.=0A= From nobody Tue Jul 10 07:17:40 2018 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 2386F130FC5; Tue, 10 Jul 2018 07:17:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk CC: tls-chairs@ietf.org, Sean Turner , draft-ietf-tls-tls13-vectors@ietf.org, tls@ietf.org, sean@sn3rd.com, kaduk@mit.edu Reply-To: ietf@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <153123224813.2366.16419087371551946868.idtracker@ietfa.amsl.com> Date: Tue, 10 Jul 2018 07:17:28 -0700 Archived-At: Subject: [TLS] Last Call: (Example Handshake Traces for TLS 1.3) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 List-Id: "This is the mailing list 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, 10 Jul 2018 14:17:34 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Example Handshake Traces for TLS 1.3' as Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2018-07-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Examples of TLS 1.3 handshakes are shown. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys and IVs are shown so that implementations might be checked incrementally against these values. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ballot/ No IPR declarations have been submitted directly on this I-D. From nobody Tue Jul 10 08:32:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE169130FF6 for ; Tue, 10 Jul 2018 08:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS7LPtL5lWBJ for ; Tue, 10 Jul 2018 08:32:32 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C729A130E17 for ; Tue, 10 Jul 2018 08:32:31 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 0377C400138A; Tue, 10 Jul 2018 15:32:31 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.34.246.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id 59B072026D6B; Tue, 10 Jul 2018 15:32:30 +0000 (UTC) From: Hubert Kario To: Eric Rescorla Cc: "" Date: Tue, 10 Jul 2018 17:32:29 +0200 Message-ID: <2926046.DTQ3PP0lUg@pintsize.usersys.redhat.com> In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2282465.JO1qnG1hBC"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 10 Jul 2018 15:32:31 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Tue, 10 Jul 2018 15:32:31 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 15:32:34 -0000 --nextPart2282465.JO1qnG1hBC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 10 July 2018 16:03:24 CEST Eric Rescorla wrote: > On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario wrote: > > On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote: > > > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote: > > > > Is there any reason why we wouldn't also consider deprecating cipher > > > > suites we don't like? For instance, RFC 5246 mandates the > > > > implementation of TLS_RSA_WITH_AES_128_CBC_SHA, which we can probab= ly > > > > agree isn't ideal for several reasons. > > >=20 > > > Is the objection primarily to AES-128-CBC or to RSA key exchange? > > > With EtM there's AFAIK/IMHO not much wrong with AES-128-CBC, it > > > outperforms AES-256-CBC, and the various CBC issues are resolved > > > via EtM. > > >=20 > > > > The ECDHE suites with AES-GCM > > > > are widely available, perhaps widely enough that we might consider a > > > > stronger move and update 5246 to modern suites. > > >=20 > > > More generally, as noted in RFC7435, you get more security by raising > > > the ceiling than by raising the floor. Breaking the ability to > > > communicate with legacy systems may feel satisfying, but does not > > > generally improve the security of the up-to-date systems, barring > > > downgrade issues in the protocol. > >=20 > > The github version of the document points out that the security of TLS = 1.2 > > downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1. >=20 > Well, yes and no. If you allow static RSA, then yes. If you require > (EC)DHE, then the anti-downgrade measures in the TLS 1.3 random values are > intended to protect against downgrade even if SHA-1 is compromised (becau= se > the randoms are signed). but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1... =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart2282465.JO1qnG1hBC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltE0Y0ACgkQkqjRuAHS 9fXM2w//RMgUYLiTV5F7ZF6/gUzzgJ1TPKOiQOkDFT8gUsfZ+qwo/yExQFhz+FXa lW8VgjPd6kF7W0dNCMA2b9JSz6kyerbHxqB9AhJJB8O7Rr9aB6fqSxwl5Wy7uE1w +UEbGYBw4+0nreNSwfjvm2H7mbgey3EKPdnzEum5o/8r6seNv2v4BvmkaenPn8jO PkZFzN8Sbz6im0UkcHO2LzX23orYdEzcR0n61u36VeSNRyKCDalJwTgIXeLwa85j kMBqDyxVRSY61aecD+2oOEO54DBPUKKeIF0/7FIKw3KsVoB9oop51kzAUtiAiv8P iUfTF0RuCF9lJQEcZTMusFA+kCmELCbV6S9ZYJ744rHb+GcYBLzNvi3XlZoJhczI dnYctPAFeVzM23AOBgBeH4UrFxW6A9wjaa+GLRUSX1yAG/SANPC12FSnwTvh+OAR Ww984FevwTEPgtdSp3eH8RRkNWRhPRftsIIyCb6DqkUszMDMqhUbS2nCQZXI7rYb L59aMMEMFjkPEoRBz3rk27uXD7El0J/ou3RuEuvrilBtwMuxCCZM2cr5GquaMjCz 3APTRVIibO0Dh5nxZNn6IYruSygzBSsICYsmgnmTlYEUp8egYLOCEx3AW+UQYv6W IQqAbaEkyg8clrN07gE17LMBmEF+llT0RejaJ4ink93ae5btIG4= =5qED -----END PGP SIGNATURE----- --nextPart2282465.JO1qnG1hBC-- From nobody Tue Jul 10 08:45:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47C071311A8 for ; Tue, 10 Jul 2018 08:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beydhLRTXnpR for ; Tue, 10 Jul 2018 08:45:19 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 47097131078 for ; Tue, 10 Jul 2018 08:45:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1531237519; x=1562773519; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gMRcGCKsy8bKHCrlM+EtB4k7945CzoHPxZg1/QAHhHY=; b=OphEYsy8CEG55wW8L6PAGSHaTYVrsjObFOu2+JkWo9afzmX5UNcwEMla WlwYwc/Uc/g1SPFwt0c6qoPA7M4o5pfBN0b9Zxp8egik23139INokCAjX DOJriggSDf39a4XPANi9Lct+2kqcpPyh5OesZq3nHwvf65mY/kJq9qeH0 7NI7zw1VqvQB6vHCXinBcKYhqYlO9NiNNdcTL1Iim5lEzMbs6MVqv//aq Yj8VKIqkD4VKEESfAROTeb7fAnAzBTvrgtR7y5vGemCJqKBnV863zU5yL snZJfK73CF/aL1JndySAsTP0Wv2NM7UfvcVkMEQco79O1oukTwdJcO6Lr g==; X-IronPort-AV: E=Sophos;i="5.51,335,1526299200"; d="scan'208";a="20557260" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jul 2018 03:45:17 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.3) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 11 Jul 2018 03:45:17 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 11 Jul 2018 03:45:16 +1200 From: Peter Gutmann To: Hubert Kario , Eric Rescorla CC: "" Thread-Topic: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) Thread-Index: AQHUGAUQdiSASvczzEuVqjvTCb06AaSHrW0AgAAG5wCAABjjgIAAzKx9 Date: Tue, 10 Jul 2018 15:45:16 +0000 Message-ID: <1531237487290.30133@cs.auckland.ac.nz> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> , <2926046.DTQ3PP0lUg@pintsize.usersys.redhat.com> In-Reply-To: <2926046.DTQ3PP0lUg@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 15:45:32 -0000 Hubert Kario writes:=0A= =0A= >but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1...= =0A= =0A= ... but with EMS or LTS in effect, with a lot more than that.=0A= =0A= Peter.=0A= From nobody Tue Jul 10 09:01:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DB8B130FF7 for ; Tue, 10 Jul 2018 09:01:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrJiDHhYT0Hf for ; Tue, 10 Jul 2018 09:01:52 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94365130FF5 for ; Tue, 10 Jul 2018 09:01:52 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 32CF529B256; Tue, 10 Jul 2018 12:01:50 -0400 (EDT) Date: Tue, 10 Jul 2018 12:01:50 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180710160150.GD33554@straasha.imrryr.org> Reply-To: tls@ietf.org References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <20180710041755.GD85096@straasha.imrryr.org> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 16:01:55 -0000 On Tue, Jul 10, 2018 at 03:38:42PM +0200, Hubert Kario wrote: > The github version of the document points out that the security of TLS 1.2 > downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1. Is this accurate? TLS 1.0 uses a combined SHA-1 + MD5 PRF. Are there known attacks that compromise TLS 1.0 via collisions in its PRF? [ IIRC, one embarrassing feature of TLS 1.2 vs. TLS 1.0 is that in making the signature algorithms negotiable, it became possible to offer and use MD5 where previously TLS 1.0 used SHA-1. ] > that is the downgrade issue in the protocol Keep in mind that my example, illustrating potentially counter-productive raising of the floor, was about SHA-1 signatures in certificates. Does accepting SHA-1 signatures in *certificate chains* create opportunities to downgrade TLS 1.2 to TLS 1.0? For the record, I am not saying that users should not be moving to TLS 1.2 (if they haven't already). Rather, I'm not aware of practical cryptographic downgrade attacks to TLS 1.0 (other than software that might still pessimistically fall back to TLS 1.0 on TLS 1.2 handshake failure). Absent, such downgrade attacks, what's really needed is broader support for TLS 1.2 (raising the ceiling), which does not require removal of support for TLS 1.0 (raising the floor). As a community we're still prone to pursue improved security primarily through removal of weak algorithms, and under-appreciate security improvement via the introduction of stronger algorithms. Of course removal of weak algorithms has its place, if these facilitate downgrade attacks, or present unnecessary attack-surface once no longer used. But we should be careful to not rush into overzealous deprecation that can sometimes do more harm than good. -- Viktor. From nobody Tue Jul 10 09:10:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C7E130E23 for ; Tue, 10 Jul 2018 09:10:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.249 X-Spam-Level: X-Spam-Status: No, score=-9.249 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3_GT4CEsPLsy for ; Tue, 10 Jul 2018 09:10:22 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8966D130FFE for ; Tue, 10 Jul 2018 09:10:22 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id q12-v6so18774555qtp.6 for ; Tue, 10 Jul 2018 09:10:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SITAVgfcQh8SPNGNds6CGmRoHdBphrvhwTR+bkBTv6I=; b=TYbA18PRHy3ZaJjwwaYZfeVW5yPkqQd/jMttCZ/8kUVnx5yuJfnzv4NCT2+ADZ4stM 58jak/v7r2hhjYVI8ph6MM3LSa/tNTrEH1QD3zrZhk2zbT/6499ymTSDsiQOHSgZyBW+ YzxpHyQPPmx5f/fucV4ikbbB4Q6ERvwC/I1fE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SITAVgfcQh8SPNGNds6CGmRoHdBphrvhwTR+bkBTv6I=; b=p+I1yhjS7V/T50GJp8Dc/HUBiBBex5HfaAlmDV+0F0hoi+Ng/C1OmdCW0Q+zkvm7bn O6tMamM+ej7XK7fmbsD24Gl378XB6CYFwol3RNCJmbSBdiXdnwkGkY9sxn02GvGlgOXT Bl+DciinV3nrgHtmZucPdWctxRUu1tDNKCN0l5eUt8Rs2yglgfSz0Z7MZSGnq12BUwlX fnRWkaHoKhqv3N+S0eIvlHHEbo+cgHqy7zkfI0TJW2zukF1lHihUTFmxcZbwPF2LHYFL rxAbIB3J7pklpTcz/cjw8rS6dGG4p2zvAGOelBAKqAQNNX9HyJSTdFS5ap1MRq/Lnocj 2DDQ== X-Gm-Message-State: APt69E0pk5Gv+pTofs6xv65rKdA7b60onQ/FScvu1plrwIG7mL9MTYP8 tkW4Or5uvVCQYET8ybRM3ndh3IpHlZGAKW1iF2u3 X-Google-Smtp-Source: AAOMgpd0O6r203L8tPfpgcIYrIk9fnnH7l5WnXVoXo6vy3zH0MWgtT8gmqHTxlSzp+vjZj7WAQCa0aQP+toYU3hK6F8= X-Received: by 2002:ac8:302e:: with SMTP id f43-v6mr24005833qte.217.1531239021489; Tue, 10 Jul 2018 09:10:21 -0700 (PDT) MIME-Version: 1.0 References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> <2926046.DTQ3PP0lUg@pintsize.usersys.redhat.com> <1531237487290.30133@cs.auckland.ac.nz> In-Reply-To: <1531237487290.30133@cs.auckland.ac.nz> From: David Benjamin Date: Tue, 10 Jul 2018 12:10:08 -0400 Message-ID: To: Peter Gutmann Cc: Hubert Kario , Eric Rescorla , "" Content-Type: multipart/alternative; boundary="000000000000f1ab470570a75d53" Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 16:10:24 -0000 --000000000000f1ab470570a75d53 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 11:46 AM Peter Gutmann wrote: > Hubert Kario writes: > > >but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1... > > .... but with EMS or LTS in effect, with a lot more than that. > EMS does not fix the ServerKeyExchange signature payload. It's still just the randoms and not the full transcript. But, fixed or not, it is still signed with SHA-1. Ironically, while signing the full transcript is indeed preferable, the SLOTH paper (see sections V.A. and V.B.) shows how it actually then becomes *easier* to exploit a weak hash function: https://www.mitls.org/pages/attacks/SLOTH David --000000000000f1ab470570a75d53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 10= , 2018 at 11:46 AM Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
=
Hubert Kario <hkario@redhat.com> writes:

>but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1.= ..

.... but with EMS or LTS in effect, with a lot more than that.

EMS does not fix the ServerKeyExchange signature payload. I= t's still just the randoms and not the full transcript.

<= /div>
But, fixed or not, it is still signed with SHA-1. Ironically, whi= le signing the full transcript is indeed preferable, the SLOTH paper=C2=A0(= see sections V.A. and V.B.) shows how it actually then becomes *easier* to = exploit a weak hash function:

David


--000000000000f1ab470570a75d53-- From nobody Tue Jul 10 09:15:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59610126CC7 for ; Tue, 10 Jul 2018 09:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eL1YJkpRdDK8 for ; Tue, 10 Jul 2018 09:15:34 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEC0A131008 for ; Tue, 10 Jul 2018 09:15:33 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d22-v6so11824566qkc.8 for ; Tue, 10 Jul 2018 09:15:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=e64orGUC7ZQCtqI99ImYH9Ju1kCHEaCP0o2Z9yN9ZK0=; b=fAWOVbUxeiqw/TCyONgwvZJHnhQ9nEy0Ccgu2z7pKmrJ3B6vDMeRxTpOOeqpJeKvP0 b6kmPMWEVQKWIS3iurtFecCDNNijK+VcdMk4W4TOe6Zwe/H09Jh6MsW2606BQKv2h5DE MdlEKWci2K4mMFAxbEbMjN+g/Tvo4aqS7cZCI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=e64orGUC7ZQCtqI99ImYH9Ju1kCHEaCP0o2Z9yN9ZK0=; b=DhyZp1IIFw1eZF6We+T4viIKsqYa7NdrRK3JieIN3qRm1c8wa9VJ04lDSkjOj1+SvR BudzLO92LQoixk947YVAPLzNuIMk1g5Zr7F6ldxhCdGpDVu5l6Mx+7sSEO7UGhk/wFoO yJt48r6vRlRxkBoU4sSVqxK6J5UdOmerLIjEZT3YBefnzag7nL2AGm0yuQsNNF6aLD9M WTYmt8k5Xy7sE5cMt7e6jt593sq1AVn/adEOXS/uwxWsRJkhvyRg5LImwy1bC2SzOcAL /H/K1WyVgTSDFfhE3gEXMQaiUVHLbK5hnTPoAHiw+rRvAnlKmAVU/OCXPDLA1uf73joC FFhA== X-Gm-Message-State: APt69E1/wJfMWacuBdCwV2vTfAjzafpdEzDvO+KkYUbswW5bCXT7dyL+ rkeyn/XbLGQOgELQ8wPeX1wOTZ/xYK8= X-Google-Smtp-Source: AAOMgpdV02Ij8KIhX0xGkbArGfIv2BtI7XvqXzActaEAk5W/ZVejWaVV+TdQhgt9RpZhguYF1h29kQ== X-Received: by 2002:a37:7285:: with SMTP id n127-v6mr22166190qkc.115.1531239332910; Tue, 10 Jul 2018 09:15:32 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id u25-v6sm604890qkk.7.2018.07.10.09.15.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 09:15:32 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <99A6D467-EF66-464F-A26B-940D2198461E@sn3rd.com> Date: Tue, 10 Jul 2018 12:15:31 -0400 To: TLS WG X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TLS] TLS@IETF102 agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 16:15:36 -0000 All, The agenda has been posted: https://datatracker.ietf.org/meeting/102/materials/agenda-102-tls-02 Note that we have two sessions: tls Session 1 (2:00 requested) Monday, 16 July 2018, Afternoon Session I 1330-1530 Room Name: Place du Canada size: 300 --------------------------------------------- tls Session 2 (1:00 requested) Thursday, 19 July 2018, Afternoon Session III 1810-1910 Room Name: Laurier size: 250 --------------------------------------------- spt From nobody Tue Jul 10 09:38:32 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F81A130E4A for ; Tue, 10 Jul 2018 09:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHb6lYZZg0qY for ; Tue, 10 Jul 2018 09:38:27 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 54E7912F1A5 for ; Tue, 10 Jul 2018 09:38:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1531240707; x=1562776707; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=PMbF2J2qlEvprTqDaXVzfUp/4U1BlVuPC0WMWqqSLos=; b=fvvZf0WGtxegW4tT5wJmIOMJHSoA5im6bO6i0rfdfyU3bjWnP1/jZx/k N8i+eF8zpbtt9JZRbONSuAlrcBenOJJ4tmwk/e8eWHsjWnXL+KX8TWo2U zuYT3DIWl92mlOh5CFaPcfFGZnXH+DK7DudQzoMlu1m4YYiBl4xEpthC2 p+DvdR8UpShrxaFJxTJLhLNV59VHnVNP44jyMBmkrJoTnRNUuZegWeuxR iC3C7/bjZPnyK2dyvajL/+KgVwVDFX9+5EeqsMkET5uHY9bG2fzr3KleS VaW9fE9J2/vl/bytroqTFUDWlvzkkzafMClHza67QE3ZjRAU8f47IRNZh w==; X-IronPort-AV: E=Sophos;i="5.51,335,1526299200"; d="scan'208";a="20561261" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from smtp.uoa.auckland.ac.nz (HELO uxcn13-ogg-a.UoA.auckland.ac.nz) ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jul 2018 04:38:23 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.22) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 11 Jul 2018 04:38:23 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 11 Jul 2018 04:38:23 +1200 From: Peter Gutmann To: David Benjamin CC: Hubert Kario , Eric Rescorla , "" Thread-Topic: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) Thread-Index: AQHUGAUQdiSASvczzEuVqjvTCb06AaSHrW0AgAAG5wCAABjjgIAAzKx9//892QCAANB78g== Date: Tue, 10 Jul 2018 16:38:22 +0000 Message-ID: <1531240673739.91065@cs.auckland.ac.nz> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> <2926046.DTQ3PP0lUg@pintsize.usersys.redhat.com> <1531237487290.30133@cs.auckland.ac.nz>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 16:38:31 -0000 David Benjamin writes:=0A= =0A= >EMS does not fix the ServerKeyExchange signature payload. It's still just = the=0A= >randoms and not the full transcript.=0A= =0A= Maybe we're talking about different things here, EMS hashes the full=0A= transcript, for 1.0 and 1.1 with the dual SHA-1 and MD5 hash, for 1.2 with= =0A= whatever's negotiated, hopefully SHA-2 (even if SHA-1 is used, you've now g= ot=0A= two hashes you need to defeat simultaneously, not one). So while the=0A= ServerKeyExchange signature may not detect an attacker able to compromise= =0A= SHA-1 in real time (and that statement alone should tell you how feasible t= he=0A= attack actually is), the later EMS will.=0A= =0A= Peter.=0A= =0A= =0A= =0A= From nobody Tue Jul 10 11:04:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5758C1311CE for ; Tue, 10 Jul 2018 11:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F9g-DWkOwiKX for ; Tue, 10 Jul 2018 11:04:40 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E383A131192 for ; Tue, 10 Jul 2018 11:04:39 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id C54BF29B338; Tue, 10 Jul 2018 14:04:38 -0400 (EDT) Date: Tue, 10 Jul 2018 14:04:38 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180710180438.GG33554@straasha.imrryr.org> Reply-To: tls@ietf.org References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 18:04:53 -0000 On Tue, Jul 10, 2018 at 09:21:04AM +0100, Stephen Farrell wrote: > I didn't have time before the I-D cutoff but have since > added a section on mail to the repo pre-01 version. (See > [1] section 3.2.) I'd love to add more detail like that > and/or more sections for other protocols if folks have > data to offer with references. The numbers for MX hosts with working DANE TLSA records are: 4337 TLS 1.2 63 TLS 1.0 5 TLS 1.1 These are early adopters of enhanced SMTP security, so one would expect to find modern software and an emphasis on security, and yet, for >1% of the MX hosts, their SMTP server libraries fail to negotiate TLS 1.2. Presumably, the broader MTA population has a higher incidence of TLS 1.0-only servers. -- Viktor. From nobody Tue Jul 10 11:11:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45BFF1311B7 for ; Tue, 10 Jul 2018 11:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sOKHvleXYKmf for ; Tue, 10 Jul 2018 11:11:29 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441B8131185 for ; Tue, 10 Jul 2018 11:11:29 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E33DC4025077; Tue, 10 Jul 2018 18:11:26 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 19FEF1C5A6; Tue, 10 Jul 2018 18:11:23 +0000 (UTC) From: Hubert Kario To: Peter Gutmann Cc: David Benjamin , Eric Rescorla , "" Date: Tue, 10 Jul 2018 20:11:14 +0200 Message-ID: <3598313.3mom7Bzgvp@pintsize.usersys.redhat.com> In-Reply-To: <1531240673739.91065@cs.auckland.ac.nz> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <1531240673739.91065@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1728215.ahyFvI94er"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 10 Jul 2018 18:11:28 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Tue, 10 Jul 2018 18:11:28 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 18:11:42 -0000 --nextPart1728215.ahyFvI94er Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 10 July 2018 18:38:22 CEST Peter Gutmann wrote: > David Benjamin writes: > >EMS does not fix the ServerKeyExchange signature payload. It's still just > >the randoms and not the full transcript. >=20 > Maybe we're talking about different things here, EMS hashes the full > transcript, for 1.0 and 1.1 with the dual SHA-1 and MD5 hash, for 1.2 with > whatever's negotiated, hopefully SHA-2 (even if SHA-1 is used, you've now > got two hashes you need to defeat simultaneously, not one). defeating two hashes, when both use use the Merkle-Damg=C3=A5rd constructio= n, is=20 not much harder than breaking just one of them (increase of work factor les= s=20 than 2) read the SLOTH paper for details and references > So while the > ServerKeyExchange signature may not detect an attacker able to compromise > SHA-1 in real time (and that statement alone should tell you how feasible > the attack actually is) yes, _now_ not for "foreseeable future" and not after quantum computers come into play =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1728215.ahyFvI94er Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltE9sIACgkQkqjRuAHS 9fXYGg//e/Kt9ZvSBViDbKMTwXUZmE2zR/OFPwyDn+JVz5qGgXeIsJHaYgh1Jgqc 052tWv6Sg4V/rNNXtq7U+CscN19Fn41fcfMVTXBU2LXdtMEsvVW2rP8pEr6cFImw 8HQv89NZPp9LRwFCZofpx5a6oHEu5M9Y3OVdpDA9F8wXWofqaKLvwClS3mbAJQ8N ZUFdWtnB1N2QVo4IGCrqngTu1CGHgWEC7QNDdI59J4GPLvIcgG6He9h+lXRaXDqU t5NSNMeD8OPq7iA1QSHn2jdPPkQnSmddfSGKFUSlN9fq5PzZbHiun8JBiWi8Gcvx 66jF69+MkLBbUKQem+lWMGdoMd3qyrlxmQu2G7bxcD4cnGFt+LTJlnyIrmhi/qay LfF0xuaNxm91oQ1WLpzQz2ZuCuALiDYMJ3ySaqi6A7MXc0jijdQeUFk7I/2bgn3f +Soi49SP4KMXjVSZtujwad6kebQK0rQaX/Ljr4jm5cqasbwKQHZsyQkqnVUNh7hD LDbMLHrTNkyO+epb1hxsPrjmqx1NlwZKh/TGx1iu8KWQUo8DIRt8FRlG4k4bfy+F mE17oxQCmF/hg9qz7zJ+0yvUII3xrWwxoswMmH7tr/bXwx8ebc1g4lZD94O4j1/F j6GcqtgMogy/N/peux3zAJHyUOZvfpe1EgxdD7LQBA6+7I0bIPw= =Cgt+ -----END PGP SIGNATURE----- --nextPart1728215.ahyFvI94er-- From nobody Tue Jul 10 11:38:02 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53F47131050 for ; Tue, 10 Jul 2018 11:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=spodhuis.org header.b=nLA2VG/n; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=spodhuis.org header.b=0Ms6GTWe Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNhUQaqf1_fy for ; Tue, 10 Jul 2018 11:13:44 -0700 (PDT) Received: from mx.spodhuis.org (smtp.spodhuis.org [IPv6:2a02:898:31:0:48:4558:736d:7470]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D395113102A for ; Tue, 10 Jul 2018 11:13:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201804; h=In-Reply-To:Content-Type:MIME-Version:Message-ID :Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=1uGnGZJZJEN828KacuP9ueiFqdT4A0MhUDeioS10ltA=; b=nLA2VG/nnM9szClE8PJNE3JV7O bmswa0l1A6dLxdvhgbwBQ4bxuFDOUSLqwCW/GZ4ycbSAmm4DGZfguNuFdXdUFvERYLcPBftHHynn1 CsZKfdfPOpwPUBP+KRK8Qhc4zmUlB5W7wZmXb2o9jM5Jh6mPkiK+gFlg5EGQG7gdFO+mUxH/W5QKQ Vzf3Rg3ZstBFymQIbxrnTBxVvVTgY/11KYM1OTUIg/fv5Ijhe7rU9p4ZQhBGLhxwPes45vLNLCpPD IkHzgJ7IWBbZcdaLGCuVDnrrAbk0gRLsj0RmWofwb6GM48wRkEzxYPTMNlOk93tezkPHPlp7Xq5RO BvaLHq4Q==; DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=spodhuis.org; s=d201804e2; h=In-Reply-To:Content-Type:MIME-Version: Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:References:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=1uGnGZJZJEN828KacuP9ueiFqdT4A0MhUDeioS10ltA=; b=0Ms6GTWe/xIgeD4OY9tJXLgTBL 85dBVUOJGhj3HKl+q1wTSIBJPAZKCvhXrs5Q2HMUyqoalOuCyhyH0hAPK5AA==; Received: from authenticated user by smtp.spodhuis.org with esmtpa id 1fcx8t-000Aqy-R9; Tue, 10 Jul 2018 18:13:40 +0000 Date: Tue, 10 Jul 2018 14:13:37 -0400 From: Phil Pennock To: Viktor Dukhovni Cc: tls@ietf.org Message-ID: <20180710181336.GA47412@osmium.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180710044324.GG85096@straasha.imrryr.org> <20180710041755.GD85096@straasha.imrryr.org> OpenPGP: url=https://www.security.spodhuis.org/PGP/keys/0x4D1E900E14C1CC04.asc Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 11:38:00 -0700 Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 18:13:53 -0000 On 2018-07-10 at 00:17 -0400, Viktor Dukhovni wrote: > More generally, as noted in RFC7435, you get more security by raising > the ceiling than by raising the floor. +1, including to the points about SMTP fallback to cleartext, etc. > For example, I recently learned that current GnuTLS > versions by default no longer validate certificates with SHA-1 > issuer signatures, and that current versions of Exim linked with > these GnuTLS releases fail to validate some DANE-TA(2) chains issued > by private-CAs that still use SHA-1. And yet: That's fine by me. Linking against GnuTLS has long had implications for mail delivery. It blocked SSLv3 at a time when SSLv3 was still fairly widespread in corporate circles (Exchange). Folks who care about TLS interop for real mail-systems use OpenSSL. For myself, I think that since SHA-1 has practical collision attacks today, the next break will be second preimage attacks, at which point the use in certificates is dead. Whether that comes tomorrow or three years from now, I don't know. It's appropriate to not re-enable SHA-1 at a point where the entire non-SMTP ecosystem has moved away from it and nobody should be asking _other people outside their own administrative domain_ to trust SHA-1 in certs. If folks want to use it internally, that's fine. If you want to use DANE-TA to expose your internal CA to the outside world, that's fine too, but you need to meet the common minimum bar for protecting chain integrity. > Thus there is no practical exposure to SHA-1 via the public CA > ecosystem, and as the issue is comprehensively addressed on the > issuer side. Today, no. But when SHA-1 is already so broken that 2nd preimage is the only remaining step to fall before it becomes unsuitable for certs, it's certainly not good to encourage its continuing usage. > Non-public CAs, on the other hand, are typically already compromised > by the time they can be convinced to issue certificates to untrusted > strangers, even if the hash algorithm is impeccably strong. And this step then falls because if considering the next break rather than "publicly known today" then the "issuing to untrusted strangers" stops being a prerequisite for attack. > For the record, SHA-1 use is not common. Not common enough for me to do more than update the Exim Specification to include a warning, which I'll do shortly. On 2018-07-10 at 00:43 -0400, Viktor Dukhovni wrote: > All the below have DANE-TA(2) TLSA RRs, with SHA-1 leaf sigs. > > semidefinite.de > iki.fi [ *.iki.fi ] So looks like two organizations total. I'm not encouraging a time-bomb break in TLS security for two orgs. Thanks for bringing this to my attention. I'll update docs shortly. -Phil From nobody Tue Jul 10 11:39:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD9813104D for ; Tue, 10 Jul 2018 11:39:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAyeD84hG1EC for ; Tue, 10 Jul 2018 11:39:31 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0348B131047 for ; Tue, 10 Jul 2018 11:39:31 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 4BDF481663F2; Tue, 10 Jul 2018 18:39:30 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id BB9052026D6B; Tue, 10 Jul 2018 18:39:29 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Tue, 10 Jul 2018 20:39:28 +0200 Message-ID: <9695281.VezRcJznyJ@pintsize.usersys.redhat.com> In-Reply-To: <20180710160150.GD33554@straasha.imrryr.org> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <3161014.mNqxEOqjoE@pintsize.usersys.redhat.com> <20180710160150.GD33554@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1598888.fIEWTU1gaR"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 10 Jul 2018 18:39:30 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Tue, 10 Jul 2018 18:39:30 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 18:39:33 -0000 --nextPart1598888.fIEWTU1gaR Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Tuesday, 10 July 2018 18:01:50 CEST Viktor Dukhovni wrote: > On Tue, Jul 10, 2018 at 03:38:42PM +0200, Hubert Kario wrote: > > The github version of the document points out that the security of TLS = 1.2 > > downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1. >=20 > Is this accurate? TLS 1.0 uses a combined SHA-1 + MD5 PRF. Are > there known attacks that compromise TLS 1.0 via collisions in its > PRF? that's what SLOTH was about (among other things) > [ IIRC, one embarrassing feature of TLS 1.2 vs. TLS 1.0 is that in making > the signature algorithms negotiable, it became possible to offer and > use MD5 where previously TLS 1.0 used SHA-1. ] >=20 > > that is the downgrade issue in the protocol >=20 > Keep in mind that my example, illustrating potentially counter-productive > raising of the floor, was about SHA-1 signatures in certificates. > Does accepting SHA-1 signatures in *certificate chains* create > opportunities to downgrade TLS 1.2 to TLS 1.0? ah, then I misunderstood, sorry for certificates, the answer is "not immediately", and "harder" as that requires either the ability by attacker to get a cert from an inter= nal=20 CA (that it can the calculate collision for) or a preimage attack on SHA-1= =20 signatures (which is significantly harder than chosen prefix) > Absent, such downgrade attacks, what's really needed is broader > support for TLS 1.2 (raising the ceiling), which does not require > removal of support for TLS 1.0 (raising the floor). do we have access to other incentives than breaking compatibility with old= =20 stuff? > As a community we're still prone to pursue improved security primarily > through removal of weak algorithms, and under-appreciate security > improvement via the introduction of stronger algorithms. aren't new strong algorithms only effective when they are actually used=20 though? > Of course removal of weak algorithms has its place, if these > facilitate downgrade attacks, or present unnecessary attack-surface > once no longer used. But we should be careful to not rush into > overzealous deprecation that can sometimes do more harm than good. my opinion is that published RFCs should represent _current_ best practice,= if=20 only because we will have to live with stuff that is deployed new for 10 ye= ars=20 if not more =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1598888.fIEWTU1gaR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltE/WAACgkQkqjRuAHS 9fWAJg/+K9wt8vaf9/qZAvtKnutFN4NoebaJMyKG+l7NZC9+VW7P0IZzaGQ8SVMm FPqbf6WiJZlCcb9KtqKB2zgRRZHICD8uivH2VfOViChfls50TN48crX6VKGFetqY sN1aUfKs/BhYoYLR5OIJbv7GWjhIjNz0uzyy1Z4PJlzDLLIx1s49DCrH5FdYUx7D 4P5nC34uAl263B/EjD4dpCv7q6s9VCstUDcdRYYu1jFjxeDcoraoiBVj1kkGVaRN u2wceArjiJ5myav7SMDDDrkiyyNEkg+ClgEXjuTJbU8pZdTkp+gsNMRzSOjIa5Ai RcBjGinpKMK+aSRsoM0eKk2xuVZDj44D0tmQ9c0dLF3Iudpc/jm5NCgk8QAETyOK 1feltfsyu1GHu2D/mWMtev6RZ3Q+3J0aGAsPfQq35E3AYAGNzN7JytSxtUbHH+hQ aiBl6s/vEgST9j9FP2WZD/ZudB/fEQ4i6TC71Xt8aYvnQJWpZJUnX1qGnhWIvPeT Mh5Y6JmMB180A5dSZV+eeAO4Phz14ykM8uPbpJmPWqIANSv/MBXSn1Gk5O1KSY1d sdtK4fSLZp4rqSekYd0M9s1MZb7mkrsm//fVKkL91hc41IG6ZwHdTOfR5x3u4L/f yvyyj/OZexNimyV2xHc9YoRfoNWkYNTy6UKxqUdFBbSDGRMV6jY= =wLWc -----END PGP SIGNATURE----- --nextPart1598888.fIEWTU1gaR-- From nobody Tue Jul 10 12:51:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E7A1311A3; Tue, 10 Jul 2018 12:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zWFxuHhKixX6; Tue, 10 Jul 2018 12:51:42 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A64F913104C; Tue, 10 Jul 2018 12:51:42 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id C2556B80101; Tue, 10 Jul 2018 12:51:41 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, tls@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20180710195141.C2556B80101@rfc-editor.org> Date: Tue, 10 Jul 2018 12:51:41 -0700 (PDT) Archived-At: Subject: [TLS] =?utf-8?q?Moved_to_Proposed_Standard=3A_RFC_5289_on_TLS_El?= =?utf-8?q?liptic_Curve_Cipher_Suites_with_SHA-256/384_and_AES_Galois_Coun?= =?utf-8?q?ter_Mode_=28GCM=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 19:51:47 -0000 RFC 5289 has been reclassified as Proposed Standard. RFC 5289 Title: TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM) Author: E. Rescorla Status: Standards Track Stream: IETF Date: August 2008 Mailbox: ekr@rtfm.com Pages: 6 Characters: 12195 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-ecc-new-mac-07.txt URL: https://www.rfc-editor.org/info/rfc5289 DOI: 10.17487/RFC5289 RFC 4492 describes elliptic curve cipher suites for Transport Layer Security (TLS). However, all those cipher suites use HMAC-SHA-1 as their Message Authentication Code (MAC) algorithm. This document describes sixteen new cipher suites for TLS that specify stronger MAC algorithms. Eight use Hashed Message Authentication Code (HMAC) with SHA-256 or SHA-384, and eight use AES in Galois Counter Mode (GCM). This memo provides information for the Internet community. This document is a product of the Transport Layer Security Working Group of the IETF. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jul 10 13:25:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D3913104C for ; Tue, 10 Jul 2018 13:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ivIaFgCQwOR for ; Tue, 10 Jul 2018 13:25:34 -0700 (PDT) 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 ADC69130E35 for ; Tue, 10 Jul 2018 13:25:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4DDF3BE39; Tue, 10 Jul 2018 21:25:31 +0100 (IST) 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 Sx_u8OJ-13Qw; Tue, 10 Jul 2018 21:25:30 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E865CBE2F; Tue, 10 Jul 2018 21:25:29 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1531254330; bh=hKqyYdS57tpbTLncIv/dF4Y4vpYHfwqOCkhbNB/odhI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=TYxYuynkMavdxDyQDOsLYookHk2/USGcrkcGPxy/dbAkzw+cYgDXvFQ3oDKH8Uqgv c0T6ws1DzkgEBcc3df0V514Ml5ol6T/uR/3WGci0U294CsVNKr509f/Jj1r0mccfSM kQ2cqBm96gAbvNMecJQ3TCWbCz1LDmNWgX2xex/w= To: tls@ietf.org, Viktor Dukhovni References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> <20180710180438.GG33554@straasha.imrryr.org> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Tue, 10 Jul 2018 21:25:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180710180438.GG33554@straasha.imrryr.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="HTjA1Nk3g7AvyOZOx9FnpYnVQMQKhOvv3" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 20:25:36 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HTjA1Nk3g7AvyOZOx9FnpYnVQMQKhOvv3 Content-Type: multipart/mixed; boundary="gBseDIYveDmxiakbCFXY1adkqRdLJTqsf"; protected-headers="v1" From: Stephen Farrell To: tls@ietf.org, Viktor Dukhovni Message-ID: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> <20180710180438.GG33554@straasha.imrryr.org> In-Reply-To: <20180710180438.GG33554@straasha.imrryr.org> --gBseDIYveDmxiakbCFXY1adkqRdLJTqsf Content-Type: multipart/mixed; boundary="------------C687C447864E19BD12F81149" Content-Language: en-GB This is a multi-part message in MIME format. --------------C687C447864E19BD12F81149 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 10/07/18 19:04, Viktor Dukhovni wrote: > On Tue, Jul 10, 2018 at 09:21:04AM +0100, Stephen Farrell wrote: >=20 >> I didn't have time before the I-D cutoff but have since >> added a section on mail to the repo pre-01 version. (See >> [1] section 3.2.) I'd love to add more detail like that >> and/or more sections for other protocols if folks have >> data to offer with references. >=20 > The numbers for MX hosts with working DANE TLSA records are: >=20 > 4337 TLS 1.2 > 63 TLS 1.0 > 5 TLS 1.1 Thanks. I'll try add text on the above and other usable numbers sent to the list to the repo version before we shoot out a -01. > These are early adopters of enhanced SMTP security, so one would > expect to find modern software and an emphasis on security, and > yet, for >1% of the MX hosts, their SMTP server libraries fail to > negotiate TLS 1.2. Presumably, the broader MTA population has a > higher incidence of TLS 1.0-only servers. Fair point. Cheers, S. >=20 --------------C687C447864E19BD12F81149 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------C687C447864E19BD12F81149-- --gBseDIYveDmxiakbCFXY1adkqRdLJTqsf-- --HTjA1Nk3g7AvyOZOx9FnpYnVQMQKhOvv3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAltFFjkACgkQWrL68XsX K+o8/Q//bY9u0keGJA3R2qtullthAMnlBImoTY+ET+VwPWi7Be+wfLYpDBSGUGrP kCAR1qrZvDldgQFJrByKGUE1tNeO+nGF8Wo2kTY91ibqCYyFj7d6hcluhAE/4kQ/ dcbmLLYbiZfDLW4xi7YSvmFaQQ1qO/xp/iLFjmloRyCjthZQtsUt1tqxzi1hxVg5 E4aoofBP9dXkLCBCuYWQWKO4m5asDiPMbX9/zcF6eLO95BOvG8xM7VrMBIFG1w8a 1tYAcTZYm7cHMVsCQHgAUVW6ffGnq41nXdU0s/loYbpFO/WZ18lgykwbOFFeM1AR 6ZiTy+u7MG4iVHJFBQFooul+tKCAIvtUnNZjIbzUjfP/9DiWF3CkUN7mTNSDXcrn 2BRuIie1E9JzhULfpRefJka7QC2kFKtyWRs51uuc1g+yUlrNKtwu08hlgBEAn/hG TiToqazRvTe7/h6uO3W01ydQE/hwS/xOe4KudicioVLjr39wX3ma6Vf833+CwMh8 iR4b/qps1OUJuqmAjvuaVEBtbOH8iNIO6FfTz42nfbJPKddR3t/5bpuxTberJUOo BhujFw7mgZ5uFsfGjyXbuc0R5GM0lbuPLyWn3j7zNJbBEeIrQRM4dsb/cgUACasA tVllm7Xliw1hGmkqaAwmaJNsHCnlH1jr5syerOvzPZlYu05R/Hg= =adXJ -----END PGP SIGNATURE----- --HTjA1Nk3g7AvyOZOx9FnpYnVQMQKhOvv3-- From nobody Tue Jul 10 13:31:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA63D131051 for ; Tue, 10 Jul 2018 13:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.89 X-Spam-Level: X-Spam-Status: No, score=-6.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_PDS_TO_EQ_FROM_NAME=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gqh2e67QzkK for ; Tue, 10 Jul 2018 13:31:37 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEF17131054 for ; Tue, 10 Jul 2018 13:31:36 -0700 (PDT) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 41QDPg0zXMzyTr; Tue, 10 Jul 2018 22:31:35 +0200 (CEST) X-purgate-ID: 152705::1531254695-000007FB-F9C3404A/0/0 X-purgate-size: 1526 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 41QDPc53QNzGpmM; Tue, 10 Jul 2018 22:31:32 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A21CB409B; Tue, 10 Jul 2018 22:31:32 +0200 (CEST) In-Reply-To: <20180709222007.AF5BD409B@ld9781.wdf.sap.corp> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <20180709222007.AF5BD409B@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Tue, 10 Jul 2018 22:31:32 +0200 (CEST) CC: Andrei Popov , "" Reply-To: mrex@sap.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20180710203132.A21CB409B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] [CAUTION] Re: Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 10 Jul 2018 20:31:41 -0000 mrex@sap.com (Martin Rex) wrote: > Andrei Popov wrote: >> >> On the recent Windows versions, TLS 1.0 is negotiated more than 10% >> of the time on the client side (this includes non-browser connections >> from all sorts of apps, some hard-coding TLS versions), >> and TLS 1.1 accounts for ~0.3% of client connections. > > "On recent Windows versions" sounds like figure might not account > for Windows 7 and Windows Server 2008R2, about half of the installed > base of Windows, and where the numbers are likely *MUCH* higher. > > When troubleshooting TLS handshake failures, I sometimes trying > alternative SSL/TLS clients on customer machines through remote support, > and it seems when I run this command on a Windows 2012R2 server: > > powershell "$web=New-Object System.Net.WebClient ; $web.DownloadString('https://www.example.com/')" 2>&1 > > it connects with TLSv1.0 only, and this is a client-side limitation. > > To make it use TLSv1.2, I would have to use > > powershell "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12 ; $web=New-Object System.Net.WebClient ; $web.DownloadString('https://www.example.com/')" 2>&1 > > i.e. explicit opt-in. btw. I checked this on a Windows 10 (1709) machine, and it's powershell also tries connecting with TLSv1.0 only. To me, it looks more like 100% of the Microsoft Windows installed base not being ready for a TLSv1.2-only world. -Martin From nobody Tue Jul 10 21:58:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2123130ECD for ; Tue, 10 Jul 2018 21:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeY_B9Nohlq4 for ; Tue, 10 Jul 2018 21:58:23 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 B56B1130E11 for ; Tue, 10 Jul 2018 21:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1531285097; x=1562821097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=JPgK/57mPBQ7snm+qkRdZLnwLf9n10NEnHoeBiuIdjg=; b=tuaWqFuHG0w9Pv+eWSG9Mdxmsr197xz4BzuF/6FjGDsxAm3llr/yFWzq gXfVSj+46cO3GBVFeZveKAHLNygaOJWxMAG70mMrnR10Zw0H7ZY3YGOtL qLBrnnLKIQ4n+nzC9ihHYXuYKl8zC6zgY1dlgAaM1lgz4qsFkMJo/ObZU ifByE3JbZzhAK1ei1qXjDyuiYmpzpQbhwlpr+a+PAks/Cg9Wmy8d5CRHD gJl04pjHL2RYZ34hGKF92NslVx/2D8fiz8t0P8E2q/b2D5/BDjtsA7NuH DbbE1Z2zOsE+hRjhK4b2szmIo7rC7TOPbaUQ623UQuLfYx6T9x+A/HNiK g==; X-IronPort-AV: E=Sophos;i="5.51,337,1526299200"; d="scan'208";a="20677669" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from uxcn13-ogg-e.uoa.auckland.ac.nz ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Jul 2018 16:58:00 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.28) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 11 Jul 2018 16:58:00 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 11 Jul 2018 16:57:59 +1200 From: Peter Gutmann To: Hubert Kario CC: David Benjamin , Eric Rescorla , "" Thread-Topic: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) Thread-Index: AQHUGAUQdiSASvczzEuVqjvTCb06AaSHrW0AgAAG5wCAABjjgIAAzKx9//892QCAANB78v//UVsAgAF9peY= Date: Wed, 11 Jul 2018 04:57:59 +0000 Message-ID: <1531285049297.18699@cs.auckland.ac.nz> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <1531240673739.91065@cs.auckland.ac.nz>, <3598313.3mom7Bzgvp@pintsize.usersys.redhat.com> In-Reply-To: <3598313.3mom7Bzgvp@pintsize.usersys.redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 04:58:26 -0000 Hubert Kario writes:=0A= =0A= >defeating two hashes, when both use use the Merkle-Damg=E5rd construction,= is=0A= >not much harder than breaking just one of them (increase of work factor le= ss=0A= >than 2)=0A= =0A= "In theory there is no difference between theory and practice. In practice= =0A= there is".=0A= =0A= I'm aware of this long-standing theoretical weakness around multicollisions= .=0A= I'm just as aware that in the fifteen-odd years since the Joux paper, no-on= e=0A= has ever managed to demonstrate an even remotely practical attack on dual= =0A= hashes, despite the hugely tempting target of all of SSL/TLS being there as= a=0A= reward. In fact the sole (significant) surviving member of the MD5/SHA-1 e= ra,=0A= RIPEMD-160, remains unbroken and uses dual hash chains within the same=0A= function, not even as two independent functions.=0A= =0A= So I'm not losing any sleep over this.=0A= =0A= >not after quantum computers =0A= =0A= ... or captured alien technology, or magic, or anything involving pyramids= or the=0A= Aztecs...=0A= =0A= >come into play=0A= =0A= Yeah, not losing any sleep over those either.=0A= =0A= Peter.=0A= From nobody Tue Jul 10 22:45:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0513126F72 for ; Tue, 10 Jul 2018 22:45:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nVOtrxW-nyLa for ; Tue, 10 Jul 2018 22:45:31 -0700 (PDT) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C10EE130DE9 for ; Tue, 10 Jul 2018 22:45:30 -0700 (PDT) Received: by mail-lf0-x229.google.com with SMTP id f18-v6so4148755lfc.2 for ; Tue, 10 Jul 2018 22:45:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gQM8aCxbgeWzhupEeM0HI9wzR1CnW3oTb5sElS2V7zM=; b=e4lk1xvY3gY8xaOGI0dSStTANrA2zSIf/2ODy2hleJxo+kEqwAe36HLMK5PEPWIKPO WATXmy9ixLZgM2ycUK/dD3RV0k+qhXliJmg0ptB6jtnSf/u7UTJyeAhkX1JAw+Cxn5Un g6+nrF64A9mrvvTIC58uKcsqjqbFYRbxkYpa8peAD3cKcSAtz36xMvAsg9ns85MYVPz7 m6walaD6p2mSzWGTpEYYW3EX8qCx5yk1X/+GcPpuFETTmQJo4kV/rWUezR/vgs+91dc/ Gz57ArfNPd7NYgGbB+R/ZYtHQERlfNqBVTZ8AxLrMiMzhqqn5DDVNPfzOn71vYFo6eDM 0KRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gQM8aCxbgeWzhupEeM0HI9wzR1CnW3oTb5sElS2V7zM=; b=VjKorELKS3BPPi7EA82yIa/qc7w2p0hTMCFvFdeGuWV3UNcHkBLrAiOvJ1vayLtgxg IAO2eRO97atX7aDVC9lxtBo+MA+IP0aSD3NkdftyAjabHPy3VKrTZwAG55vm6ui0cyv4 cBOxafLPWTmOpwnJq1LcbhzKC2F22Y+jw5w2gFx3Iw1aORPek1HL0d03jJaZGNzQ6v7w D7my75YJLDvidIrM6M0s90lS0e+vSZZqzZ1xGKPOns73yoRjny4J6xpzyBA+/ICtLCEa pJbQERJmhjEX8rnGWIzWPQMlH4CID8xIpjP0iTUpdP/qsHs1Zy5K0E3I9h0ENd0CGeh1 qroQ== X-Gm-Message-State: APt69E0AGb5WDenq8SP3jM3/95eCVXzBuJ9uUhnB6AgGao8N7PBT3od7 3KdPceGKa6XBLM6jt1fVkk5qi4fQxb0/9s+Neg7DiF1Y X-Google-Smtp-Source: AAOMgpfI1OJrZdpRGBgtsm8w/Gj5t1CnC+e8cPhGp+PfEDy6Ptqkir8yNyRvSs3AC0JFUWfWp29gCCCUwUEc84XTWz4= X-Received: by 2002:a19:c301:: with SMTP id t1-v6mr4601508lff.45.1531287928907; Tue, 10 Jul 2018 22:45:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:f8d:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 22:45:28 -0700 (PDT) In-Reply-To: <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> From: nalini elkins Date: Wed, 11 Jul 2018 11:15:28 +0530 Message-ID: To: Stephen Farrell Cc: "" Content-Type: multipart/alternative; boundary="0000000000000d3b710570b2c10e" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 05:45:34 -0000 --0000000000000d3b710570b2c10e Content-Type: text/plain; charset="UTF-8" Stephen, > I'd love to add more detail like that and/or more sections for other protocols if folks have data to offer with references. I believe that I can reach out to various people I know. Please comment if my methodology is acceptable and if you think this will be helpful. I am thinking the following: Location: U.S. / Canada (possibly U.K.) - 3 banks (hopefully from the top 5) - 3 large insurance companies (includes back end processing) - 3 U.S. federal government agencies - 3 companies in the Wall Street / Stock brokerage sector (includes back end processing) - 3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.) - 3 in the retail sector (Home Depot, Target, Lowes, et al) Note: I put in "back end processing" because these are the folks that most often have many connections to other business partners and so in some ways have the most complex systems to deal with. Note #2: This is aspirational! I hope I can get all these people to cooperate. I will try at least to get some in each category. I will ask them the following questions: 1. How many applications do you have? (This may end up being only the mission critical ones as otherwise it may be too hard to obtain.) 2. How many are using TLS and how many are still plain text? (We will disregard SSH and other such variants.) 3. What percent of clients are using a pre-TLS1.2 version? (This will be an estimation.) 4. Do you have an active project to migrate off of older versions of TLS? 5. What do you estimate your percent of clients using pre-TLS1.2 versions to be next year? Please let me know if this will be of use & if you have suggestions for improvement. Thanks, Nalini On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell wrote: > > Hi Nalini, > > On 10/07/18 04:50, nalini elkins wrote: > > It would be nice to see some of this reflected in the draft rather than > > only statistics on browsers. The real usage of these protocols is far > > more complex. > > I didn't have time before the I-D cutoff but have since > added a section on mail to the repo pre-01 version. (See > [1] section 3.2.) I'd love to add more detail like that > and/or more sections for other protocols if folks have > data to offer with references. > > Consistent with other folks' numbers sent to the list > yesterday, (though based on a much smaller sat of data I > guess;-) my data shows 10.6% use of TLSv1.0 when talking > SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K > IP addresses that listen on port 25 (mail servers). > > What I don't currently have is a rate of change for that > figure. I think that rate of change is the important number > for figuring out what to do in the next while. E.g. The > WG might conclude that if the percentage of TLSv1.0 is > moving down nicely, we should be a bit patient. If it's > not moving at all, we can probably move now or in 5 years > without that being different. If we're not sure, then get > more data... > > Cheers, > S. > > [1] > https://github.com/sftcd/tls-oldversions-diediedie/blob/mast > er/draft-moriarty-tls-oldversions-diediedie.txt > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com --0000000000000d3b710570b2c10e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stephen,=

> I'd love to add more deta= il like that=C2=A0and/or= more sections for other protocols if folks have=C2=A0data to offer with references.

I believe that I can reach out to various= people I know.=C2=A0 =C2=A0Please comment if my methodology is acceptable = and if you think this will be helpful.

I am thinking the following:

Location: U.S. / Canada (possibly U.K.)
-=C2=A0 3 banks (hopefully from the top 5)
-=C2=A0 3 large insurance companies=C2=A0=C2=A0= (includes back end processing)
-=C2=A0 3 U.S. federal government agencies=
-=C2=A0 3 companies in the Wall Street / Stock broker= age sector (includes back end processing)
-=C2=A0 3 la= rge credit card / processors (ex. Visa, Discover, MasterCard, etc.)
-=C2=A0 3 in the retail sector (Home Depot, Target, Lowes, et= al)

Note: I put in "ba= ck end processing" because these are the folks that most often have ma= ny connections to other business partners and so in some ways have the most= complex systems to deal with.

Note #2:=C2=A0 This is aspirational!=C2=A0 I hope I can get all these pe= ople to cooperate.=C2=A0 I will try at least to get some in each category.<= /div>


I = will ask them the following questions:

1.=C2=A0 How many applications do you have?=C2=A0 (This may end = up being only the mission critical ones as otherwise it may be too hard to = obtain.)


2.=C2=A0 =C2=A0How many are using TLS and how many are still plain t= ext?=C2=A0 (We will disregard SSH and other such variants.)


3.=C2=A0 =C2=A0Wh= at percent of clients are using a pre-TLS1.2 version?=C2=A0 (This will be a= n estimation.)


4.=C2=A0 =C2=A0Do you have an active project to migrate off of= older versions of TLS?


=
5.=C2=A0 =C2=A0What do you estimate your percent of c= lients using pre-TLS1.2 versions to be next year?

=

Please let me know if this = will be of use & if you have suggestions for improvement.

Thanks,
Nalini
=



On Tue, Jul 10, 2018 at 1= :51 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie> = wrote:

Hi Nalini,

On 10/07/18 04:50, nalini elkins wrote:
> It would be nice to see some of this reflected in the draft rather tha= n
> only statistics on browsers.=C2=A0 =C2=A0The real usage of these proto= cols is far
> more complex.

I didn't have time before the I-D cutoff but have since
added a section on mail to the repo pre-01 version. (See
[1] section 3.2.) I'd love to add more detail like that
and/or more sections for other protocols if folks have
data to offer with references.

Consistent with other folks' numbers sent to the list
yesterday, (though based on a much smaller sat of data I
guess;-) my data shows 10.6% use of TLSv1.0 when talking
SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
IP addresses that listen on port 25 (mail servers).

What I don't currently have is a rate of change for that
figure. I think that rate of change is the important number
for figuring out what to do in the next while. E.g. The
WG might conclude that if the percentage of TLSv1.0 is
moving down nicely, we should be a bit patient. If it's
not moving at all, we can probably move now or in 5 years
without that being different. If we're not sure, then get
more data...

Cheers,
S.

[1]
https://github.com/sftcd/tls-oldversions-diediedie/blob/master/draft-moriarty-tls-oldversions-diediedie.txt



--
Thanks,
Nalini Elkins
=
President
Enterprise Data Center Operators
<= a href=3D"http://www.e-dco.com" target=3D"_blank">www.e-dco.com

--0000000000000d3b710570b2c10e-- From nobody Wed Jul 11 02:50:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F73130DFA for ; Wed, 11 Jul 2018 02:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N42XcJTiznf4 for ; Wed, 11 Jul 2018 02:50:51 -0700 (PDT) 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 3464B130DE2 for ; Wed, 11 Jul 2018 02:50:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A1DAEBE55; Wed, 11 Jul 2018 10:50:48 +0100 (IST) 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 O6WfwkMrLWdU; Wed, 11 Jul 2018 10:50:46 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8CCBEBE53; Wed, 11 Jul 2018 10:50:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1531302646; bh=R4VaG18f6S+Wsg8Y/aQdAq21x+Eh/4aWkwQzykQjk5g=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=1Yle4gjGVLZuVVPxMI8zyRDTC/K2o+N/RPtWv7T3yl+mIYMYo6ZSH1KGcrrh/Pl92 j7Y7KDwfmER2oZXhxrZayzbtaxFlZRkup2w6zsLRNO+5p9ZLm7BbPNFZMDGDKEAqWG Ui0AI1HRvlyxLIDRHknGDEunCmhVP9EYQAz4SBHA= To: nalini elkins Cc: "" References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 11 Jul 2018 10:50:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pwX355BJOpBZzv7fVnl1afnTl02krpFTy" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 09:50:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pwX355BJOpBZzv7fVnl1afnTl02krpFTy Content-Type: multipart/mixed; boundary="5m91LpoUq48R7PcztlF1W2LCyqaEkZn7T"; protected-headers="v1" From: Stephen Farrell To: nalini elkins Cc: "" Message-ID: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> In-Reply-To: --5m91LpoUq48R7PcztlF1W2LCyqaEkZn7T Content-Type: multipart/mixed; boundary="------------1350EB941883E77948FCF25D" Content-Language: en-GB This is a multi-part message in MIME format. --------------1350EB941883E77948FCF25D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 11/07/18 06:45, nalini elkins wrote: > Stephen, >=20 >> I'd love to add more detail like that and/or more sections for other > protocols if folks have data to offer with references. >=20 > I believe that I can reach out to various people I know. Please comme= nt > if my methodology is acceptable and if you think this will be helpful. It's not whether the methodology is acceptable to me or not but whether or not the references to the numbers are credible for readers:-) A few comment below, >=20 > I am thinking the following: >=20 > Location: U.S. / Canada (possibly U.K.) >=20 > - 3 banks (hopefully from the top 5) > - 3 large insurance companies (includes back end processing) > - 3 U.S. federal government agencies > - 3 companies in the Wall Street / Stock brokerage sector (includes ba= ck > end processing) > - 3 large credit card / processors (ex. Visa, Discover, MasterCard, et= c.) > - 3 in the retail sector (Home Depot, Target, Lowes, et al) Those are pretty small numbers unless they're interacting with a lot of TLS services. It'd be hard to know if they'd be representative of something or not if they're anonymised in the results. I'd encourage you to try get people to be open about things here - there's no particular shame in having 10% TLSv1.0 sessions after all:-) >=20 > Note: I put in "back end processing" because these are the folks that m= ost > often have many connections to other business partners and so in some w= ays > have the most complex systems to deal with. >=20 > Note #2: This is aspirational! I hope I can get all these people to > cooperate. I will try at least to get some in each category. >=20 >=20 > I will ask them the following questions: >=20 > 1. How many applications do you have? (This may end up being only the= > mission critical ones as otherwise it may be too hard to obtain.) I'm not sure that's so interesting for this question. And I'm not sure that different people would count things as applications in the same way. > 2. How many are using TLS and how many are still plain text? (We wil= l > disregard SSH and other such variants.) Again, that's not so interesting here. > 3. What percent of clients are using a pre-TLS1.2 version? (This wil= l be > an estimation. I don't see why this needs to be estimated, this is kinda the key measurement needed and easy to measure. There should be no need for anyone to stick their thumb in the air for this:-) It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and TLSv1.3) and to say for how many TLS sessions or hosts/IPs the figures apply. And of course providing as much context as possible so that it's possible to understand the numbers and whether or not the numbers from different sources are based on the same or different kinds of measurement. >=20 > 4. Do you have an active project to migrate off of older versions of = TLS? Sure. >=20 > 5. What do you estimate your percent of clients using pre-TLS1.2 vers= ions > to be next year? I don't see how this'd be so useful. Aaking about the historic and current rates of change of use of the various protocol versions would be good though if people have that, but they may not. S. >=20 >=20 > Please let me know if this will be of use & if you have suggestions for= > improvement. >=20 > Thanks, > Nalini >=20 >=20 >=20 >=20 > On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell > wrote: >=20 >> >> Hi Nalini, >> >> On 10/07/18 04:50, nalini elkins wrote: >>> It would be nice to see some of this reflected in the draft rather th= an >>> only statistics on browsers. The real usage of these protocols is f= ar >>> more complex. >> >> I didn't have time before the I-D cutoff but have since >> added a section on mail to the repo pre-01 version. (See >> [1] section 3.2.) I'd love to add more detail like that >> and/or more sections for other protocols if folks have >> data to offer with references. >> >> Consistent with other folks' numbers sent to the list >> yesterday, (though based on a much smaller sat of data I >> guess;-) my data shows 10.6% use of TLSv1.0 when talking >> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K >> IP addresses that listen on port 25 (mail servers). >> >> What I don't currently have is a rate of change for that >> figure. I think that rate of change is the important number >> for figuring out what to do in the next while. E.g. The >> WG might conclude that if the percentage of TLSv1.0 is >> moving down nicely, we should be a bit patient. If it's >> not moving at all, we can probably move now or in 5 years >> without that being different. If we're not sure, then get >> more data... >> >> Cheers, >> S. >> >> [1] >> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast >> er/draft-moriarty-tls-oldversions-diediedie.txt >> >=20 >=20 >=20 --------------1350EB941883E77948FCF25D Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------1350EB941883E77948FCF25D-- --5m91LpoUq48R7PcztlF1W2LCyqaEkZn7T-- --pwX355BJOpBZzv7fVnl1afnTl02krpFTy Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAltF0vYACgkQWrL68XsX K+prZw//SrAxNJ7CjKCTxsHOBJlsL7oadWibO3cIyO0OQ6X/bkCx+F0XkKhj3ua2 SR+VCGAg+AriD8WWRMFZNLfBlrr0Nmr3IbmtBudlikhS5cyujmsNK3hciOloqf/3 gM8H71Dq68qgbbdHFcmkzdlZcFwuSrmuKfc1Myc2dPIpVJBqFg1DybwJMUuaWzcy TD2JtrysvVVdZHjiIZxPcdM8PtAMt4EtYJTteEtpH2IzQVdfKqX2pT1rCIisRXYn riP8fMEyTIgRDrgDf1Wz+BQYsW4ZC0mapf7F2bGx/wdASFrYi6yqAURrchMcyN6y GWcd8g/0hLDRFPi+IaIyE3A1vlJVwKr4kP6NSOCgNNmXFAlPTtBs+03fWDtUuVS1 ByoVoQL211XY2qUDgDhYoWwVpeK+1Z61t0R7GZ+wqbnJZwQEWa/txsStp9L+WreM eAsyxYfF0Uphf8hg40ZIdIbFNbTgsb2WBkTKA9fsH9sTRpfyzeHFi+rfbKR9j7Ga WwYv4jtdLgTE1xK4Wne3uLOsrIps5yQMq/t3I4NuTVMoXtErv/kintLAOvaYDiz/ FLZRvIaDneM/ZrMHUrua7dN7nPrZJbBJrNfxtIq/+Jk4UxvNnkYBn6knNQk1MlZV YVHNvcaVcX20TUYVWn8Z5npcWFFCkOCgTRT2G1vZPm8frwz+E64= =WwQa -----END PGP SIGNATURE----- --pwX355BJOpBZzv7fVnl1afnTl02krpFTy-- From nobody Wed Jul 11 04:06:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A86A130DD1 for ; Wed, 11 Jul 2018 04:06:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlTT_tbxbOwV for ; Wed, 11 Jul 2018 04:06:24 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FED130DD0 for ; Wed, 11 Jul 2018 04:06:24 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6AE2440122BF; Wed, 11 Jul 2018 11:06:23 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 8ADFE20389E0; Wed, 11 Jul 2018 11:06:22 +0000 (UTC) From: Hubert Kario To: Peter Gutmann Cc: David Benjamin , Eric Rescorla , "" Date: Wed, 11 Jul 2018 13:06:21 +0200 Message-ID: <2548022.nG52NxUzuR@pintsize.usersys.redhat.com> In-Reply-To: <1531285049297.18699@cs.auckland.ac.nz> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <3598313.3mom7Bzgvp@pintsize.usersys.redhat.com> <1531285049297.18699@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1952550.CdbyKgmWrf"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 11 Jul 2018 11:06:23 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 11 Jul 2018 11:06:23 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] raising ceiling vs. floor (was: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 11:06:26 -0000 --nextPart1952550.CdbyKgmWrf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 11 July 2018 06:57:59 CEST Peter Gutmann wrote: > Hubert Kario writes: > >defeating two hashes, when both use use the Merkle-Damg=C3=A5rd construc= tion, is > >not much harder than breaking just one of them (increase of work factor > >less than 2) >=20 > "In theory there is no difference between theory and practice. In practi= ce > there is". >=20 > I'm aware of this long-standing theoretical weakness around multicollisio= ns. > I'm just as aware that in the fifteen-odd years since the Joux paper, > no-one has ever managed to demonstrate an even remotely practical attack = on > dual hashes, despite the hugely tempting target of all of SSL/TLS being > there as a reward. 2^77 is a rather high barrier of entry just to prove expected result =E2=80= =93 I'm not=20 surprised about lack of practical attack at all. Nobody has disproved the conclusion of that paper either, so we don't have = the=20 luxury of ignoring it. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1952550.CdbyKgmWrf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltF5K0ACgkQkqjRuAHS 9fWU8RAAkepK3CV6209ZId3xWQk0GkhQoWbUkFQg5teRM3FpVSKdgwOArbkvTYGw rzAJGTvNTMu/VWXEJnXEf+xMT3REn9obB/6I/B/TmeC6XIzojvLdrg2+c7SU2g6C vYHN99TASsksJ6+MtQFC+2DLepRDNzRe75KUS7bbSPGnh7Kt0nnEjxnt0COsZinZ QzJp2KHTWl9uaFfMlntUDuPbPXGmT68xx1PI8sOAG0HhdD20qZ1C/wFXu3sk2bgn MoCxLVoFUka+Jo1H3f06tfwLJd6P6WmGUZcAaSly1X2bvVfY/bq+f7O5/043rl9R eadYLK6qAwMwnmbVaCgt6zlK1XjbjVFA0aq/i/kbfjEY7yJsi58lPD+SjSmk39YP FhoszeEf0Yn4BjZMBWTUrKQIua2Rxwmra30bnL2oiTstESyr3ZvdZWbTkvA1C85U iI4NY694JEbBjZNujg8IFN5jn0RtQbgx6wtTfBqhiGrkLjVG0f0bhF/wMX+TqdeY ojgRce1qhIGi9ut/L4xb8OEDOcLR1ksWtjGxgudWWx33bPiaOtMJMk+1/SA4wcrL nK9PPU4ephByDbf0YXv8VvsswsSnJSEmy0TfS5eOkEngnZuGXN3c7q4Q5/1U9bGc 7feJJWqzpEQxMDIgRxiveXYTTMmfjJ1hfJz5GVXnHU9CDeBlEc8= =WAhQ -----END PGP SIGNATURE----- --nextPart1952550.CdbyKgmWrf-- From nobody Wed Jul 11 06:06:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D45F130DF3 for ; Wed, 11 Jul 2018 06:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KVVD4xdiof9u for ; Wed, 11 Jul 2018 06:06:45 -0700 (PDT) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D24B130E0D for ; Wed, 11 Jul 2018 06:06:45 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id r184-v6so3723099ywg.6 for ; Wed, 11 Jul 2018 06:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IKB1ps57/QT8GDfoHDbQ4rkeYKLyLnndWA/u8YoAxNU=; b=N9DeovBnkz9W6qnJkALdS23GI5Uw8gey2nf1K75ykRWj7cqiliYAAVcaCCjIG40SnY wvdB/YyNR2/xEUD0+KoRhX4NHpGlHEb+XvxlBpOEAsshvumi8Wt9CGBlnCn6aVjQ386+ RXsJ8L+086PD5bHt/8yU9lBSsxO7iuYO+y+PiQyX3EBskffBo8EyWgs83g7F7+44uCIu veifFCOk9oClPLy4LRMhRIfNZOGfBk7Xf2rIeSZkNQfoxPWDAKbsbjanBXyaCupsbjhJ F/uTKL1ccW1kSMiz2GZN/dm8gBH609kivTaR5pGVUVQMGsVFhfBNPKrWj2sRAHG9HeKq CktQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IKB1ps57/QT8GDfoHDbQ4rkeYKLyLnndWA/u8YoAxNU=; b=FqlO5ApzwF9LLDPFKc+FGHhY/SCBC4FqSUbbL1aUIAeIm8WIT2YUhTmIdb54ShFY0F lfnujsoMjC+sb07Xqy9NivWxNnaLdiXuuULppXFq+dRoJEz57X5XCxtHsQp/CRR9hvv2 g1F5ZzmTPkveLNnVdV1m6mIm+zfjYGKygiuKbhFoce/fqA0lizwJU98mcsQEv354ME0H XZrx1eCznVzb/3GD6vdgamJ+KO1YtS1u+cHOSO4h4/oTUhalbbtw4LPJdqyewAeAP7wS 8ka6C8fWu8eifBPoxXv79VrpVUY4IsV16Ne+dvpbpiQGvAaZ8yT3qDpiGeMhRGI++ef1 21TA== X-Gm-Message-State: AOUpUlHdoz52usPivjFjEAAKlnKLwPTxBulNyBOGE+leJ3yc1FoLRK6n qg2jBgVJWQLDmPIBNqhCr2h/K6wnDx7MuBMW0dqpEgLY X-Google-Smtp-Source: AAOMgpe2OFt+1o5/MuKQlvMlwgOHpdnW6GwS/R67UfHSVC4lAaIsATggQyJeUBL19oI+F6CN0Hr0Jx9hx1d8dshGMtU= X-Received: by 2002:a81:2202:: with SMTP id i2-v6mr2896107ywi.167.1531314404768; Wed, 11 Jul 2018 06:06:44 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Wed, 11 Jul 2018 06:06:04 -0700 (PDT) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> From: Eric Rescorla Date: Wed, 11 Jul 2018 06:06:04 -0700 Message-ID: To: Stephen Farrell Cc: nalini elkins , "" Content-Type: multipart/alternative; boundary="00000000000022d1b60570b8eb2f" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 13:06:49 -0000 --00000000000022d1b60570b8eb2f Content-Type: text/plain; charset="UTF-8" I'd like to distinguish between two different questions: 1. Whether or not the IETF should recommend that people stop using older versions of TLS. 2. Whether or not vendors should stop accepting/supporting older versions of TLS. The former one of these is just exhorting people to stop, which people can comply with or not. The latter has real impact, especially for something like a browser where ou (and counterparties) just get involuntarily upgraded. In the latter situation, we need to be pretty sensitive to wide use to avoid bricking people. In the former situation, however, part of the purpose of the IETF deprecating these protocols is to tell people who haven't gotten off that we think they should, and that's a judgement partly driven by uses (otherwise you look silly) but not entirely so. Given that there is a good alternative (i.e., TLS 1.2) that's straightforward to deploy, I'm not sure that the fact that a lot of people are running downrev versions means we shouldn't say that the IETF no longer considers that good. -Ekr On Wed, Jul 11, 2018 at 2:50 AM, Stephen Farrell wrote: > > Hiya, > > On 11/07/18 06:45, nalini elkins wrote: > > Stephen, > > > >> I'd love to add more detail like that and/or more sections for other > > protocols if folks have data to offer with references. > > > > I believe that I can reach out to various people I know. Please comment > > if my methodology is acceptable and if you think this will be helpful. > > It's not whether the methodology is acceptable to me or not > but whether or not the references to the numbers are credible > for readers:-) > > A few comment below, > > > > > I am thinking the following: > > > > Location: U.S. / Canada (possibly U.K.) > > > > - 3 banks (hopefully from the top 5) > > - 3 large insurance companies (includes back end processing) > > - 3 U.S. federal government agencies > > - 3 companies in the Wall Street / Stock brokerage sector (includes back > > end processing) > > - 3 large credit card / processors (ex. Visa, Discover, MasterCard, > etc.) > > - 3 in the retail sector (Home Depot, Target, Lowes, et al) > > Those are pretty small numbers unless they're interacting with > a lot of TLS services. It'd be hard to know if they'd be > representative of something or not if they're anonymised in the > results. I'd encourage you to try get people to be open about > things here - there's no particular shame in having 10% TLSv1.0 > sessions after all:-) > > > > > Note: I put in "back end processing" because these are the folks that > most > > often have many connections to other business partners and so in some > ways > > have the most complex systems to deal with. > > > > Note #2: This is aspirational! I hope I can get all these people to > > cooperate. I will try at least to get some in each category. > > > > > > I will ask them the following questions: > > > > 1. How many applications do you have? (This may end up being only the > > mission critical ones as otherwise it may be too hard to obtain.) > > I'm not sure that's so interesting for this question. And I'm not > sure that different people would count things as applications in > the same way. > > > 2. How many are using TLS and how many are still plain text? (We will > > disregard SSH and other such variants.) > > Again, that's not so interesting here. > > > 3. What percent of clients are using a pre-TLS1.2 version? (This will > be > > an estimation. > I don't see why this needs to be estimated, this is kinda the key > measurement needed and easy to measure. There should be no need for > anyone to stick their thumb in the air for this:-) > > It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and > TLSv1.3) and to say for how many TLS sessions or hosts/IPs the > figures apply. > > And of course providing as much context as possible so that it's > possible to understand the numbers and whether or not the numbers > from different sources are based on the same or different kinds of > measurement. > > > > > 4. Do you have an active project to migrate off of older versions of > TLS? > > Sure. > > > > > 5. What do you estimate your percent of clients using pre-TLS1.2 > versions > > to be next year? > > I don't see how this'd be so useful. Aaking about the historic and > current rates of change of use of the various protocol versions would > be good though if people have that, but they may not. > > S. > > > > > > > Please let me know if this will be of use & if you have suggestions for > > improvement. > > > > Thanks, > > Nalini > > > > > > > > > > On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> Hi Nalini, > >> > >> On 10/07/18 04:50, nalini elkins wrote: > >>> It would be nice to see some of this reflected in the draft rather than > >>> only statistics on browsers. The real usage of these protocols is far > >>> more complex. > >> > >> I didn't have time before the I-D cutoff but have since > >> added a section on mail to the repo pre-01 version. (See > >> [1] section 3.2.) I'd love to add more detail like that > >> and/or more sections for other protocols if folks have > >> data to offer with references. > >> > >> Consistent with other folks' numbers sent to the list > >> yesterday, (though based on a much smaller sat of data I > >> guess;-) my data shows 10.6% use of TLSv1.0 when talking > >> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K > >> IP addresses that listen on port 25 (mail servers). > >> > >> What I don't currently have is a rate of change for that > >> figure. I think that rate of change is the important number > >> for figuring out what to do in the next while. E.g. The > >> WG might conclude that if the percentage of TLSv1.0 is > >> moving down nicely, we should be a bit patient. If it's > >> not moving at all, we can probably move now or in 5 years > >> without that being different. If we're not sure, then get > >> more data... > >> > >> Cheers, > >> S. > >> > >> [1] > >> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast > >> er/draft-moriarty-tls-oldversions-diediedie.txt > >> > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --00000000000022d1b60570b8eb2f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to distinguish between two different que= stions:

1. Whether or not the IETF should recommen= d that people stop using older versions of TLS.
2. Whether or not= vendors should stop accepting/supporting older versions of TLS.
=
The former one of these is just exhorting people to stop, wh= ich people can comply with or not. The latter has real impact, especially f= or something like a browser where ou (and counterparties) just get involunt= arily upgraded.

In the latter situation, we need t= o be pretty sensitive to wide use to avoid bricking people. In the former s= ituation, however, part of the purpose of the IETF deprecating these protoc= ols is to tell people who haven't gotten off that we think they should,= and that's a judgement partly driven by uses (otherwise you look silly= ) but not entirely so. Given that there is a good alternative (i.e., TLS 1.= 2) that's straightforward to deploy, I'm not sure that the fact tha= t a lot of people are running downrev versions means we shouldn't say t= hat the IETF no longer considers that good.

-E= kr


On Wed, Jul 11, 2018 at 2:50 AM, Stephen Farrell <step= hen.farrell@cs.tcd.ie> wrote:

Hiya,

On 11/07/18 06:45, nalini elkins wrote:
>=C2=A0 Stephen,
>
>> I'd love to add more detail like that and/or more sections for= other
> protocols if folks have data to offer with references.
>
> I believe that I can reach out to various people I know.=C2=A0 =C2=A0P= lease comment
> if my methodology is acceptable and if you think this will be helpful.=

It's not whether the methodology is acceptable to me or not
but whether or not the references to the numbers are credible
for readers:-)

A few comment below,

>
> I am thinking the following:
>
> Location: U.S. / Canada (possibly U.K.)
>
> -=C2=A0 3 banks (hopefully from the top 5)
> -=C2=A0 3 large insurance companies=C2=A0 (includes back end processin= g)
> -=C2=A0 3 U.S. federal government agencies
> -=C2=A0 3 companies in the Wall Street / Stock brokerage sector (inclu= des back
> end processing)
> -=C2=A0 3 large credit card / processors (ex. Visa, Discover, MasterCa= rd, etc.)
> -=C2=A0 3 in the retail sector (Home Depot, Target, Lowes, et al)

Those are pretty small numbers unless they're interacting with a lot of TLS services. It'd be hard to know if they'd be
representative of something or not if they're anonymised in the
results. I'd encourage you to try get people to be open about
things here - there's no particular shame in having 10% TLSv1.0
sessions after all:-)

>
> Note: I put in "back end processing" because these are the f= olks that most
> often have many connections to other business partners and so in some = ways
> have the most complex systems to deal with.
>
> Note #2:=C2=A0 This is aspirational!=C2=A0 I hope I can get all these = people to
> cooperate.=C2=A0 I will try at least to get some in each category.
>
>
> I will ask them the following questions:
>
> 1.=C2=A0 How many applications do you have?=C2=A0 (This may end up bei= ng only the
> mission critical ones as otherwise it may be too hard to obtain.)

I'm not sure that's so interesting for this question. And I&= #39;m not
sure that different people would count things as applications in
the same way.

> 2.=C2=A0 =C2=A0How many are using TLS and how many are still plain tex= t?=C2=A0 (We will
> disregard SSH and other such variants.)

Again, that's not so interesting here.

> 3.=C2=A0 =C2=A0What percent of clients are using a pre-TLS1.2 version?= =C2=A0 (This will be
> an estimation.
I don't see why this needs to be estimated, this is kinda the ke= y
measurement needed and easy to measure. There should be no need for
anyone to stick their thumb in the air for this:-)

It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and
TLSv1.3) and to say for how many TLS sessions or hosts/IPs the
figures apply.

And of course providing as much context as possible so that it's
possible to understand the numbers and whether or not the numbers
from different sources are based on the same or different kinds of
measurement.

>
> 4.=C2=A0 =C2=A0Do you have an active project to migrate off of older v= ersions of TLS?

Sure.

>
> 5.=C2=A0 =C2=A0What do you estimate your percent of clients using pre-= TLS1.2 versions
> to be next year?

I don't see how this'd be so useful. Aaking about the histor= ic and
current rates of change of use of the various protocol versions would
be good though if people have that, but they may not.

S.

>
>
> Please let me know if this will be of use & if you have suggestion= s for
> improvement.
>
> Thanks,
> Nalini
>
>
>
>
> On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hi Nalini,
>>
>> On 10/07/18 04:50, nalini elkins wrote:
>>> It would be nice to see some of this reflected in the draft ra= ther than
>>> only statistics on browsers.=C2=A0 =C2=A0The real usage of the= se protocols is far
>>> more complex.
>>
>> I didn't have time before the I-D cutoff but have since
>> added a section on mail to the repo pre-01 version. (See
>> [1] section 3.2.) I'd love to add more detail like that
>> and/or more sections for other protocols if folks have
>> data to offer with references.
>>
>> Consistent with other folks' numbers sent to the list
>> yesterday, (though based on a much smaller sat of data I
>> guess;-) my data shows 10.6% use of TLSv1.0 when talking
>> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
>> IP addresses that listen on port 25 (mail servers).
>>
>> What I don't currently have is a rate of change for that
>> figure. I think that rate of change is the important number
>> for figuring out what to do in the next while. E.g. The
>> WG might conclude that if the percentage of TLSv1.0 is
>> moving down nicely, we should be a bit patient. If it's
>> not moving at all, we can probably move now or in 5 years
>> without that being different. If we're not sure, then get
>> more data...
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast
>> er/draft-moriarty-tls-oldversions-diediedie.txt
>>
>
>
>

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


--00000000000022d1b60570b8eb2f-- From nobody Wed Jul 11 08:16:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E86130DFC for ; Wed, 11 Jul 2018 08:16:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GlxO9qZtSc_n for ; Wed, 11 Jul 2018 08:16:27 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20589124D68 for ; Wed, 11 Jul 2018 08:16:24 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6BF73vb032449; Wed, 11 Jul 2018 16:15:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=UeMCi4J+iCIJMrmyIUWIxQWz2OBN+sGsnIWMys7dMbM=; b=V+WxNXWnr6mj+VJx5QTVdlmwOVtjfrpVyyLardvL2VYpTrUeb83tD2I4tuyXz4HugY8+ AHNyj4xTO33Gcuy8laEaXhPiCDiunHhielLIQDF1iU3Qxj7LEVtZPIZr+Jm8mHOlTLtw v2n1Jo7p9TKGgtT0NrZDIwLgzUhuiuaUl2rQUcigV0kQDiLbduMKNDiiU5lDLZNGqPud edmD9jm+Ss62Mn65fzHGYH2wIs+6bf9M5uK1KbdDqI/lVWe+HukkggC2p8bBDjdb3Xlg q455FMP32XxyM6e0jqkhokWM54DTtc1QLe/aS8iaTcaMKHwaF2SfZZZwd83XBIkCPu6Z hg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2k5jys87rv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Jul 2018 16:15:41 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6BF5ZXY027242; Wed, 11 Jul 2018 11:15:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2k2ruv6qa8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 11 Jul 2018 11:15:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 11 Jul 2018 11:15:35 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Wed, 11 Jul 2018 11:15:35 -0400 From: "Salz, Rich" To: Eric Rescorla , Stephen Farrell CC: "" Thread-Topic: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt Thread-Index: AQHUF6PG+cob+lmdCEitxYvNmL6MC6SHXteAgAAAxoCAABGLAIAApP2AgABLhACAAWbcAIAARIiAgAA2kgD//+EgAA== Date: Wed, 11 Jul 2018 15:15:34 +0000 Message-ID: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.137] Content-Type: multipart/alternative; boundary="_000_B1DB52A1F52E442395CF3F3B0FCDB840akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-11_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=770 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807110163 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-11_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=685 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807110163 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 15:16:29 -0000 --_000_B1DB52A1F52E442395CF3F3B0FCDB840akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJJ20gbm90IHN1cmUgdGhhdCB0aGUgZmFjdCB0aGF0IGEgbG90IG9mIHBlb3BsZSBhcmUgcnVu bmluZyBkb3ducmV2IHZlcnNpb25zIG1lYW5zIHdlIHNob3VsZG4ndCBzYXkgdGhhdCB0aGUgSUVU RiBubyBsb25nZXIgY29uc2lkZXJzIHRoYXQgZ29vZC4NCg0KSSB0b3RhbGx5IGFuZCBzdHJvbmds eSBhZ3JlZS4NCg== --_000_B1DB52A1F52E442395CF3F3B0FCDB840akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <33E575260EC01C44B162ED907756689C@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5o b2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGlu O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4N CjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0Ozwvc3Bhbj48L2I+IEknbSBub3Qgc3VyZSB0 aGF0IHRoZSBmYWN0IHRoYXQgYSBsb3Qgb2YgcGVvcGxlIGFyZSBydW5uaW5nIGRvd25yZXYgdmVy c2lvbnMgbWVhbnMgd2Ugc2hvdWxkbid0IHNheSB0aGF0IHRoZSBJRVRGIG5vIGxvbmdlciBjb25z aWRlcnMgdGhhdCBnb29kLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0b3RhbGx5 IGFuZCBzdHJvbmdseSBhZ3JlZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_B1DB52A1F52E442395CF3F3B0FCDB840akamaicom_-- From nobody Wed Jul 11 09:39:24 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F321130F67 for ; Wed, 11 Jul 2018 09:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8134Arx_uoIx for ; Wed, 11 Jul 2018 09:39:19 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3A5130E69 for ; Wed, 11 Jul 2018 09:39:19 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id c5-v6so21596213qth.5 for ; Wed, 11 Jul 2018 09:39:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cimhSuNJx58DOv+KPjZH/pNfYsb5mmYxAQST8AHYNsA=; b=G3je+5yojDPVdjFUmoz8iWBZDmsBla4R+Nu6Y/rK2FbxidsN4JfBrZR6qVqjbDj3tY OPHbUWWMRLYJzkuHK20uEblTSdSfYJSkmfuXdDH3XOhuFSN9aQuGScEuLk2rNX6yUxZK Py4kH3fQqTMRH4HT1g3avmiqliXppvRCUkoijfT58B6mLWvy0ifODw3iNdyVHfb0YkAT OMa70mtP3HhFR+41lD5Z1WRlgQJU5FpMcAZwsGIJ/nJrdWNw9vo8tav0a3d3/ejWP0XE uwvQrLT1izQL3oiXAgEqFG8SJKq5S5kiPFpzdNpLazjAxgqYmD0ACl8ZPb5AK2IsvMj3 5jEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=cimhSuNJx58DOv+KPjZH/pNfYsb5mmYxAQST8AHYNsA=; b=GULXIYmLxQyLCkUHWYIcdfVQGD6Bzqm7hz1N57zl6l9R3FE7882iVu2d81teqbBAyu SnboSCKtfTj6cJCNb2qNnlApjucylZ4FNpIjOfbPk7QTNLHOkblLSLpMv2Zlt8hNvDvZ LVjbnzyo82hBotPGKjQMMheABbkmMNA7nhO+ddG2POcPDoJ/s3yk3S6GiAqWdd2fa0MS gC8ZryTIws2GUYHS5nMaW8YMmJwuENSCJRHMnHAiaig983GQQlL4JNTs9Or9BOwI3d3c /k1UcaZ98NLSps0QF1ac+IA3nMmf/gl9A90J9hivIKbM5kFODBf9c++KwRzQ6ngVmSNL d89A== X-Gm-Message-State: APt69E0GQRAbNFslc5BrlDob3PL6/rA7hNp/cMdaOhZArz2ObsKi+seI snErF5SP3WSMgJYMYbzqgYDRT41p X-Google-Smtp-Source: AAOMgpfD4MkYi6mSxDzHeEf5JM9PBfOBPRkXnyeiIvGsxI4X/JxNNzb2mAI9uR6uG6AYeP6CKuKJDg== X-Received: by 2002:ac8:1987:: with SMTP id u7-v6mr28381939qtj.296.1531327158468; Wed, 11 Jul 2018 09:39:18 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id w13-v6sm5507819qtc.88.2018.07.11.09.39.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 09:39:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: <20180710203132.A21CB409B@ld9781.wdf.sap.corp> Date: Wed, 11 Jul 2018 12:39:16 -0400 Cc: Andrei Popov , "" Content-Transfer-Encoding: quoted-printable Message-Id: <646B8AB5-A03C-4B3D-BC3C-139AFD426AB5@gmail.com> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <20180709222007.AF5BD409B@ld9781.wdf.sap.corp> <20180710203132.A21CB409B@ld9781.wdf.sap.corp> To: mrex@sap.com Archived-At: Subject: Re: [TLS] [CAUTION] Re: Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 16:39:22 -0000 Sent from my mobile device > On Jul 10, 2018, at 4:31 PM, Martin Rex wrote: >=20 > mrex@sap.com (Martin Rex) wrote: >> Andrei Popov wrote: >>>=20 >>> On the recent Windows versions, TLS 1.0 is negotiated more than 10% >>> of the time on the client side (this includes non-browser connections >>> from all sorts of apps, some hard-coding TLS versions), >>> and TLS 1.1 accounts for ~0.3% of client connections. >>=20 >> "On recent Windows versions" sounds like figure might not account >> for Windows 7 and Windows Server 2008R2, about half of the installed >> base of Windows, and where the numbers are likely *MUCH* higher. >>=20 >> When troubleshooting TLS handshake failures, I sometimes trying >> alternative SSL/TLS clients on customer machines through remote support, >> and it seems when I run this command on a Windows 2012R2 server: >>=20 >> powershell "$web=3DNew-Object System.Net.WebClient ; $web.Download= String('https://www.example.com/')" 2>&1 >>=20 >> it connects with TLSv1.0 only, and this is a client-side limitation. >>=20 >> To make it use TLSv1.2, I would have to use >>=20 >> powershell "[Net.ServicePointManager]::SecurityProtocol =3D [Net.S= ecurityProtocolType]::Tls12 ; $web=3DNew-Object System.Net.WebClient ; $web.= DownloadString('https://www.example.com/')" 2>&1 >>=20 >> i.e. explicit opt-in. >=20 >=20 > btw. I checked this on a Windows 10 (1709) machine, and it's powershell al= so > tries connecting with TLSv1.0 only. >=20 > To me, it looks more like 100% of the Microsoft Windows installed > base not being ready for a TLSv1.2-only world. >=20 Martin, Do you want to add a PR with this unless further verification is needed? Thank you, Kathleen=20 >=20 > -Martin >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 11 09:44:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A099130DF4 for ; Wed, 11 Jul 2018 09:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWii-XAlmhMF for ; Wed, 11 Jul 2018 09:44:38 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A1CF12F295 for ; Wed, 11 Jul 2018 09:44:38 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id b66-v6so13986449qkj.1 for ; Wed, 11 Jul 2018 09:44:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wcu8ezScfZAvJsLbnP344u30vIfH50OXVPdeX4MaMPs=; b=qy9kXS8SH72TnhDPrv+nVkOF1KDQZTdIo7vx0/VdykSV7edM50ht4Z0WX0eRV8yOty 4JTHjNKzYzzn+/e+AS5tea/nhViIvZgh5OCSvlWxVfv2yC1pz62IXxJOt8niREgGCAP4 MOwrqtF0m7TB/2KnAfLstzWPA/9ZphvaUNMHssln6gesZd4IXx09lOtythP7GosXzWcu wy33BAbMocg9xFEHrqareJA0+Hgis715LMh1zlSUUNOI5KvH397CUud7BDdrTRwe8ZzY NVFgUL3jIaKApVt0X1rx6fL785w0iS7IbpcpAsNO9wo2nTHWisRl9DXrojYnrw569Ptt 6Hmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=wcu8ezScfZAvJsLbnP344u30vIfH50OXVPdeX4MaMPs=; b=DGVxs+Iy+4WjWW2TPOy1Xl0IAdney5Z9u6Tz2PQPY5Lcz+k664AEUAD/UVXOvME94C E9HJQYzSWLVDeKQFVq6Ew0t8QpsQgWiAvILNLAJZUD9DL39b1uSR/5m9fAbd8SZ2hfkO MXWqpj+2XSBAxALtFLK8EVDqppyqaP/YGkSon/McVztKfHvF3dGaxcbHLD7BUwQFxLUk bMLEf+QKgPBX9aqkAFTl/1HZ1vSvh09SXGQjk4h15AIG35MRJOMBuK7/AF5BBjtsRAIW Xs1EjoC8dsInc7z0GB83hCWx646PelqL6eoajk1hoP1R15JYQWq4/aWq0bvhlojJ2Khr z5Lg== X-Gm-Message-State: APt69E22beFfRwx9n86Omd4bBDLSWt09/RAgq87eRvZAlk6ZeNUxYqrW ilR6G7Vr9SlYPVOvO85BvWc= X-Google-Smtp-Source: AAOMgpeyK1Tzugs30xUKR7AQ97KKWBT59Fx0C0Q2ok87R+e4CCcYIXQr+TstDEgvlQpXSYwkEQVxjQ== X-Received: by 2002:a37:6454:: with SMTP id y81-v6mr27195604qkb.56.1531327477752; Wed, 11 Jul 2018 09:44:37 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id e206-v6sm2307944qkb.4.2018.07.11.09.44.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 09:44:37 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: Date: Wed, 11 Jul 2018 12:44:35 -0400 Cc: nalini elkins , "" Content-Transfer-Encoding: quoted-printable Message-Id: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> To: Stephen Farrell Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 16:44:42 -0000 Hi Nalini, I think it would be more useful to collect show stopper information. Do the= y have systems or applications that cannot be upgraded as there is no upgrad= e path? Do these systems or applications matter in terms of deprecation? I= t may not matter if they are isolated or there is no external requirement ar= ound encryption. I did hear from someone off-list that I think will submit a PR on the system= s he can=E2=80=99t upgrade, but he also said they don=E2=80=99t matter and a= re not a show stopper. Thank you, Kathleen=20 Sent from my mobile device > On Jul 11, 2018, at 5:50 AM, Stephen Farrell w= rote: >=20 >=20 > Hiya, >=20 >> On 11/07/18 06:45, nalini elkins wrote: >> Stephen, >>=20 >>> I'd love to add more detail like that and/or more sections for other >> protocols if folks have data to offer with references. >>=20 >> I believe that I can reach out to various people I know. Please comment= >> if my methodology is acceptable and if you think this will be helpful. >=20 > It's not whether the methodology is acceptable to me or not > but whether or not the references to the numbers are credible > for readers:-) >=20 > A few comment below, >=20 >>=20 >> I am thinking the following: >>=20 >> Location: U.S. / Canada (possibly U.K.) >>=20 >> - 3 banks (hopefully from the top 5) >> - 3 large insurance companies (includes back end processing) >> - 3 U.S. federal government agencies >> - 3 companies in the Wall Street / Stock brokerage sector (includes back= >> end processing) >> - 3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.= ) >> - 3 in the retail sector (Home Depot, Target, Lowes, et al) >=20 > Those are pretty small numbers unless they're interacting with > a lot of TLS services. It'd be hard to know if they'd be > representative of something or not if they're anonymised in the > results. I'd encourage you to try get people to be open about > things here - there's no particular shame in having 10% TLSv1.0 > sessions after all:-) >=20 >>=20 >> Note: I put in "back end processing" because these are the folks that mos= t >> often have many connections to other business partners and so in some way= s >> have the most complex systems to deal with. >>=20 >> Note #2: This is aspirational! I hope I can get all these people to >> cooperate. I will try at least to get some in each category. >>=20 >>=20 >> I will ask them the following questions: >>=20 >> 1. How many applications do you have? (This may end up being only the >> mission critical ones as otherwise it may be too hard to obtain.) >=20 > I'm not sure that's so interesting for this question. And I'm not > sure that different people would count things as applications in > the same way. >=20 >> 2. How many are using TLS and how many are still plain text? (We will >> disregard SSH and other such variants.) >=20 > Again, that's not so interesting here. >=20 >> 3. What percent of clients are using a pre-TLS1.2 version? (This will b= e >> an estimation. > I don't see why this needs to be estimated, this is kinda the key > measurement needed and easy to measure. There should be no need for > anyone to stick their thumb in the air for this:-) >=20 > It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and > TLSv1.3) and to say for how many TLS sessions or hosts/IPs the > figures apply. >=20 > And of course providing as much context as possible so that it's > possible to understand the numbers and whether or not the numbers > from different sources are based on the same or different kinds of > measurement. >=20 >>=20 >> 4. Do you have an active project to migrate off of older versions of TL= S? >=20 > Sure. >=20 >>=20 >> 5. What do you estimate your percent of clients using pre-TLS1.2 versio= ns >> to be next year? >=20 > I don't see how this'd be so useful. Aaking about the historic and > current rates of change of use of the various protocol versions would > be good though if people have that, but they may not. >=20 > S. >=20 >>=20 >>=20 >> Please let me know if this will be of use & if you have suggestions for >> improvement. >>=20 >> Thanks, >> Nalini >>=20 >>=20 >>=20 >>=20 >> On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell >> wrote: >>=20 >>>=20 >>> Hi Nalini, >>>=20 >>>> On 10/07/18 04:50, nalini elkins wrote: >>>> It would be nice to see some of this reflected in the draft rather than= >>>> only statistics on browsers. The real usage of these protocols is far= >>>> more complex. >>>=20 >>> I didn't have time before the I-D cutoff but have since >>> added a section on mail to the repo pre-01 version. (See >>> [1] section 3.2.) I'd love to add more detail like that >>> and/or more sections for other protocols if folks have >>> data to offer with references. >>>=20 >>> Consistent with other folks' numbers sent to the list >>> yesterday, (though based on a much smaller sat of data I >>> guess;-) my data shows 10.6% use of TLSv1.0 when talking >>> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K >>> IP addresses that listen on port 25 (mail servers). >>>=20 >>> What I don't currently have is a rate of change for that >>> figure. I think that rate of change is the important number >>> for figuring out what to do in the next while. E.g. The >>> WG might conclude that if the percentage of TLSv1.0 is >>> moving down nicely, we should be a bit patient. If it's >>> not moving at all, we can probably move now or in 5 years >>> without that being different. If we're not sure, then get >>> more data... >>>=20 >>> Cheers, >>> S. >>>=20 >>> [1] >>> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast >>> er/draft-moriarty-tls-oldversions-diediedie.txt >>>=20 >>=20 >>=20 >>=20 > <0x5AB2FAF17B172BEA.asc> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 11 09:47:35 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3184130E3D for ; Wed, 11 Jul 2018 09:47:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GYSXFbWXCt0Q for ; Wed, 11 Jul 2018 09:47:31 -0700 (PDT) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AF1130DF4 for ; Wed, 11 Jul 2018 09:47:31 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id 26-v6so3337037qks.9 for ; Wed, 11 Jul 2018 09:47:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vHR/O6bFvM2Y93oyU76iJZ68EeKZP72dlIWlpHtkeeo=; b=R3I9MMVEUlTn6xY1WZnrTc3X5DcB5Uo3bHTR5V0vab0e7yG7XTd+xBNQH0qQI4CUJU bJu77D6hLFVnZ8HkXlKAgDRaJsoyLSWartlND27FQyF0LHAHSK34ioht1MKoJl/IGm93 UnQV9eUskg2yqxVcbWbxhYcAKFIMfCQOw0HaMm4HqaRJ9vD9bQ0isaUr9GodERsAGLDG oHKzalA6xOCfVrloPHI3ffrQeQl3YQwJpjRd1oqfurugVJXpid9VJeHhhPPyOQXrYx0q BrP5v2e5O733GL8WwDxbv6z3CmJHn52WVc+dlVAgKE1v3sDB2f8qhPSkipxIX+9cHmem U+NA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vHR/O6bFvM2Y93oyU76iJZ68EeKZP72dlIWlpHtkeeo=; b=a5FtH/cHDlQYvJ/iEyOWSgv6Ns4Z2jqs69kDY6Q/8J1pnoiApZuC0hXUbWUqTzHAJt bNyLgBW0TkkvqjiM9qZ5BB1kOsBMEaRGT+TIvuYbjaThb8KIGGmEp5tR+HqtuNby26AQ gdPdZjSFZWj/aCPSoi7yIoOYlz77VU6dTXWKt415o8zVN65kSnn3jLsM1UdhbxIGAzXg 3MF/6Y55/wqfzet2kd74Da+DJMEA0/eSI7X1TaNqlkorbiRwPEbe1jDn4ecCANCJoMvR IMSf20IHDYAbVuClb4X18uc/dh7BA5RZ90QM6CRu3aY1vwEVdiQtuywKWHlYPEZsLou0 0ipw== X-Gm-Message-State: APt69E0p5uoJYT8zpG0s/Ry5fna0MFVw09sdmtn4BSML3lq+ugHAT4zC BmPAqCNKoZjyMkc8t1G88fU= X-Google-Smtp-Source: AAOMgpdZtz4jnclbclwvl8JNtvhBwO3N+QFlsuoBSZd2nLIiQQm9ShB42HAAaebZNpKzADPGrJjffA== X-Received: by 2002:a37:27c3:: with SMTP id n186-v6mr26407739qkn.387.1531327650406; Wed, 11 Jul 2018 09:47:30 -0700 (PDT) Received: from [192.168.1.210] (209-6-121-113.s2671.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.121.113]) by smtp.gmail.com with ESMTPSA id s64-v6sm8707074qkc.70.2018.07.11.09.47.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 09:47:29 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (15E216) In-Reply-To: <1531231597254.2616@cs.auckland.ac.nz> Date: Wed, 11 Jul 2018 12:47:28 -0400 Cc: nalini elkins , Andrei Popov , "" Content-Transfer-Encoding: quoted-printable Message-Id: <5B7035FD-7AEF-47B9-A585-1DD5A9500006@gmail.com> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <1531231597254.2616@cs.auckland.ac.nz> To: Peter Gutmann Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 16:47:35 -0000 Contributions with data are welcomed and encouraged. Thank you, Kathleen=20 Sent from my mobile device > On Jul 10, 2018, at 10:07 AM, Peter Gutmann wr= ote: >=20 > nalini elkins writes: >=20 >> It would be nice to see some of this reflected in the draft rather than o= nly >> statistics on browsers. The real usage of these protocols is far more >> complex. >=20 > +1. It often seems that the only possible use for TLS that gets considere= d in > these things is web browsers and web servers, or big-iron type servers in > general. There's a vast amount of TLS that never goes anywhere near a bro= wser > or server of this kind. In particular, the assumptions that are no longer= > valid in this case are: >=20 > - CPU and memory is nearly unlimited and nearly free. >=20 > - Anything can be easily upgraded at the touch of a button. >=20 > - Everyone gets their certs from a commercial CA (that's present in a trus= t > database). >=20 > - People want the most full-featured, complex protocol possible. >=20 > - Users want the latest, trendiest algorithms at all times. >=20 > [Feel free to add more to this list, that's just the stuff that springs > immediately to mind]. >=20 > In the case of SCADA/embedded, pretty much the exact opposite of all of th= ose > points is the case (the last may be somewhat debatable, it's a reference t= o > the fact that industry groups are very conservative and tend to stick with= > something that has what's regarded as good provenance). >=20 > Peter. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Jul 11 10:27:50 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63336130E4C for ; Wed, 11 Jul 2018 10:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y-OY9l8QXWKQ for ; Wed, 11 Jul 2018 10:27:46 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B2EB130F85 for ; Wed, 11 Jul 2018 10:27:46 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id a5-v6so7211144qtp.2 for ; Wed, 11 Jul 2018 10:27:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=9Z1lxUKKtwUHSJkhDazq0rpb74RYdrh2WbDG7Tnc+6w=; b=F17Lh0GNy+QwZcTVCw1R5PSGIzBjz3QjH0yJT0T4jB2CUvbYdnFRsysBbtE3F4JYOw v41Kr430le9U7Z5ux53+GpIzBMKUOEQxNj0HeCAx2h2IsOnM0c93DkU0h/RQWvhTPNWb uFquKjQnW3jLUCEPRQCDrL6b5UjoJ5pxP6C00= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=9Z1lxUKKtwUHSJkhDazq0rpb74RYdrh2WbDG7Tnc+6w=; b=P6nBH76B1cEDpkClGfe5wRQaMVDgpR3VEO8Akb+1Drtrt3QDJaEK+GWk7MdWTT2uTv KC5DxYpeHpWJf5qugUQeauvTWskBdgYx7YmlzHphQcmQWobkaPDMTj1gYDQXqUzc/r3x 3vbAuKCPHEvqKA1wcA6bhbMoIysqr3hRKvp8JfzqvzuIoYrk5kdHfTn9GUIII5Eyj03r MnkFus/fQau/Vc67Vl7iMBAPHwh/v5ABEeQ1nWXGL9R4iPSbsBpZ5tVGN3fJD8OSJOgX G3Lhs0NwOLQpC8Umx5wj78oEGHJYA7PwF4GLVFBztROiz4qLZI/Gz3IRdEawdgNHo060 X5XQ== X-Gm-Message-State: AOUpUlFnGntptmpuu6SbL3WUt2CRDY8z/m3RdELp2T8paiCrmOjd11ae X6lc6GxpFhWQ3Kux7yVR2AvVydY/xjs= X-Google-Smtp-Source: AAOMgpcVt3UNXkhYj0NSBRfj6rOsviZkwuYeoqRhBarZXfX7whtQA4dLVV0+f+8eskxu8toZWtbk5Q== X-Received: by 2002:a0c:881c:: with SMTP id 28-v6mr198420qvl.109.1531330065262; Wed, 11 Jul 2018 10:27:45 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id w13-v6sm5611815qtc.88.2018.07.11.10.27.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 11 Jul 2018 10:27:44 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 11 Jul 2018 13:27:43 -0400 References: <99A6D467-EF66-464F-A26B-940D2198461E@sn3rd.com> To: TLS WG In-Reply-To: <99A6D467-EF66-464F-A26B-940D2198461E@sn3rd.com> Message-Id: <7B24E9CF-18D0-4264-B4CF-6FEFCECC9E81@sn3rd.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] TLS@IETF102 agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 17:27:49 -0000 A revised agenda has been posted. spt > On Jul 10, 2018, at 12:15, Sean Turner wrote: > > All, > > The agenda has been posted: > https://datatracker.ietf.org/meeting/102/materials/agenda-102-tls-02 > > Note that we have two sessions: > > tls Session 1 (2:00 requested) > Monday, 16 July 2018, Afternoon Session I 1330-1530 > Room Name: Place du Canada size: 300 > --------------------------------------------- > tls Session 2 (1:00 requested) > Thursday, 19 July 2018, Afternoon Session III 1810-1910 > Room Name: Laurier size: 250 > --------------------------------------------- > > spt From nobody Wed Jul 11 10:38:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11E4130E63 for ; Wed, 11 Jul 2018 10:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JyA6YcXyivC9 for ; Wed, 11 Jul 2018 10:38:00 -0700 (PDT) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A406D130E40 for ; Wed, 11 Jul 2018 10:38:00 -0700 (PDT) Received: by mail-qk0-x244.google.com with SMTP id b66-v6so14077539qkj.1 for ; Wed, 11 Jul 2018 10:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=D7qPNRrD1SUqFvn0H1IWEn9TwsN+nP0a44uGxjZ7KaQ=; b=aM0v9PDOeX8ugrQoUBuxG8BcKJzB/ZCuaMD5oJz8yGQcxwuA+Dgw18MLIOEL/jMo3m 7/e3qRKiupOCvTInQaTsexPWGYtuEMwuelTC69/R9Zgs84QKljaBD828yX9r7mZfDoN6 g9qwSq1abm+P8NwPgiEgGnqn1UhPo+bpaaBgU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=D7qPNRrD1SUqFvn0H1IWEn9TwsN+nP0a44uGxjZ7KaQ=; b=ev2+L14qDs0F8kpfbRG7BSy5fUUC7AZOluH0BULl0FNdndfH1AeZlazJAsT8YwbPg7 98r3SnqQyf+x7yFBHaVSplbjWNCl6c1TyRViQpMhVKzNXVjPgXv0OA19JRt5gyvcC9bJ 1XJT/EsHY/5nd9NbNJh2X1mpUbZro1zVoZzZlrMlywnpEUINRLoWRuf+NWARh7S3zi4P I94fH4xa1paqacrT+nylQmL3pkFVWxbMLIv48porWjD13ODL1HKk949EgRt1jXgt/VkD 1m3LZWgTRtnV9TMhE6Le/JpLamMg7aaSqbBsNcKXgkVjCf3yzZLdcriw/YPJ/iWid47U C+Hg== X-Gm-Message-State: APt69E12KinI153K6+QzYuXjd5ex1vKLpql6EkdX0FhV7ggKYBG9Y2OD 9gJJaua1GnwOR8DR4kmJ+O9dv0VB1uaVDlxbtjKI X-Google-Smtp-Source: AAOMgpdVKJ0a2AJceWGBNdpWXp9KQJGYYlRFQ1d1HyP4iwhgc+4/ayWivi0oLFgmGFiQUcbzVYRzZBXg5FUrNsTXArE= X-Received: by 2002:a37:6393:: with SMTP id x141-v6mr28202997qkb.318.1531330679570; Wed, 11 Jul 2018 10:37:59 -0700 (PDT) MIME-Version: 1.0 References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> In-Reply-To: From: David Benjamin Date: Wed, 11 Jul 2018 13:37:46 -0400 Message-ID: To: Eric Rescorla Cc: Kathleen Moriarty , "" Content-Type: multipart/alternative; boundary="0000000000003119250570bcb5b0" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 11 Jul 2018 17:38:03 -0000 --0000000000003119250570bcb5b0 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 9, 2018 at 12:58 PM Eric Rescorla wrote: > On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla wrote: > >> Thanks for writing this. >> >> I would be in favor of deprecating old versions of TLS prior to 1.2. >> Firefox Telemetry shows that about 1% of our connections are TLS 1.1 >> > > This should be 1.0. > > > (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. >> >> This is probably a higher number than we'd be comfortable turning off >> immediately, but it is probably worth starting the process. >> > Metrics from Chrome report 0.43% of our connections are TLS 1.0 and 0.03% of them are TLS 1.1, which is a similar situation. I too am in favor of deprecating them and getting things started. David On Mon, Jul 9, 2018 at 9:40 AM, Kathleen Moriarty < >> kathleen.moriarty.ietf@gmail.com> wrote: >> >>> Hello, >>> >>> Stephen and I posted the draft below to see if the TLS working group >>> is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has >>> been a recent drop off in usage for web applications due to the PCI >>> Council recommendation to move off TLSv1.0, with a recommendation to >>> go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 >>> as a baseline. Applications other than those using HTTP may not have >>> had the same reduction in usage. If you are responsible for services >>> where you have a reasonable vantage point to gather and share >>> statistics to assess usage further, that could be helpful for the >>> discussion. We've received some feedback that has been incorporated >>> into the working draft and feelers in general have been positive. It >>> would be good to know if there are any show stoppers that have not >>> been considered. >>> >>> https://github.com/sftcd/tls-oldversions-diediedie >>> >>> Thanks in advance, >>> Kathleen >>> >>> >>> ---------- Forwarded message ---------- >>> From: >>> Date: Mon, Jun 18, 2018 at 3:05 PM >>> Subject: New Version Notification for >>> draft-moriarty-tls-oldversions-diediedie-00.txt >>> To: Stephen Farrell , Kathleen Moriarty >>> >>> >>> >>> >>> A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt >>> has been successfully submitted by Stephen Farrell and posted to the >>> IETF repository. >>> >>> Name: draft-moriarty-tls-oldversions-diediedie >>> Revision: 00 >>> Title: Deprecating TLSv1.0 and TLSv1.1 >>> Document date: 2018-06-18 >>> Group: Individual Submission >>> Pages: 10 >>> URL: >>> >>> https://www.ietf..org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt >>> >>> Status: >>> >>> https://datatracker.ietf.org/doc/draft-moriarty-tls-oldversions-diediedie/ >>> Htmlized: >>> https://tools.ietf.org/html/draft-moriarty-tls-oldversions-diediedie-00 >>> Htmlized: >>> >>> https://datatracker.ietf.org/doc/html/draft-moriarty-tls-oldversions-diediedie >>> >>> >>> Abstract: >>> This document [if approved] formally deprecates Transport Layer >>> Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and moves >>> these documents to the historic state. These versions lack support >>> for current and recommended cipher suites, and various government and >>> industry profiiles of applications using TLS now mandate avoiding >>> these old TLS versions. TLSv1.2 has been the recommended version for >>> IETF protocols since 2008, providing sufficient time to transition >>> away from older versions. Products having to support older versions >>> increase the attack surface unnecessarily and increase opportunities >>> for misconfigurations. Supporting these older versions also requires >>> additional effort for library and product maintenance. >>> >>> This document updates the backward compatibility sections of TLS RFCs >>> [[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1. This >>> document also updates RFC 7525. >>> >>> >>> >>> >>> 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 >>> >>> >>> >>> -- >>> >>> Best regards, >>> Kathleen >>> >>> _______________________________________________ >>> 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 > --0000000000003119250570bcb5b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jul 9,= 2018 at 12:58 PM Eric Rescorla <ekr@rtf= m.com> wrote:
On Mon, Jul 9, 201= 8 at 9:54 AM, Eric Rescorla <ekr@rtfm.com> wrote:
Thanks for writing this.

I would be in favor of deprecating old versions of TLS prio= r to 1.2. Firefox Telemetry shows that about 1% of our connections are TLS = 1.1

This should b= e 1.0.
<= div class=3D"gmail_quote">


(on the same data set, TLS 1.3 is >= 5%), and TLS 1.1 is negligible.

This is probably = a higher number than we'd be comfortable turning off immediately, but i= t is probably worth starting the process.

Metrics from Chrome report 0.43% = of our connections are TLS 1.0 and 0.03% of them are TLS 1.1, which is a si= milar situation. I too am in favor of deprecating them and getting things s= tarted.

David

On Mon, Jul 9= , 2018 at 9:40 AM, Kathleen Moriarty <kathleen.moriarty.iet= f@gmail.com> wrote:
Hell= o,

Stephen and I posted the draft below to see if the TLS working group
is ready to take steps to deprecate TLSv1.0 and TLSv1.1.=C2=A0 There has been a recent drop off in usage for web applications due to the PCI
Council recommendation to move off TLSv1.0, with a recommendation to
go to TLSv1.2 by June 30th.=C2=A0 NIST has also been recommending TLSv1.2 as a baseline.=C2=A0 Applications other than those using HTTP may not have<= br> had the same reduction in usage.=C2=A0 If you are responsible for services<= br> where you have a reasonable vantage point to gather and share
statistics to assess usage further, that could be helpful for the
discussion.=C2=A0 We've received some feedback that has been incorporat= ed
into the working draft and feelers in general have been positive.=C2=A0 It<= br> would be good to know if there are any show stoppers that have not
been considered.

https://github.com/sftcd/tls-oldversions-diediedie=

Thanks in advance,
Kathleen


---------- Forwarded message ----------
From:=C2=A0 <internet-drafts@ietf.org>
Date: Mon, Jun 18, 2018 at 3:05 PM
Subject: New Version Notification for
draft-moriarty-tls-oldversions-diediedie-00.txt
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Kathleen Moriarty
<K= athleen.Moriarty.ietf@gmail.com>



A new version of I-D, draft-moriarty-tls-oldversions-diediedie-00.txt
has been successfully submitted by Stephen Farrell and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-moriarty-tls-oldversion= s-diediedie
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Deprecating TLSv1.0 and TLSv1.1 Document date:=C2=A0 2018-06-18
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 10
URL:
https://www.ietf= ..org/internet-drafts/draft-moriarty-tls-oldversions-diediedie-00.txt Status:
https://datatracker.ietf.o= rg/doc/draft-moriarty-tls-oldversions-diediedie/
Htmlized:
https://tools.ietf.org/html/d= raft-moriarty-tls-oldversions-diediedie-00
Htmlized:
https://datatracker.ie= tf.org/doc/html/draft-moriarty-tls-oldversions-diediedie


Abstract:
=C2=A0 =C2=A0This document [if approved] formally deprecates Transport Laye= r
=C2=A0 =C2=A0Security (TLS) versions 1.0 [RFC2246] and 1.1 [RFC4346] and mo= ves
=C2=A0 =C2=A0these documents to the historic state.=C2=A0 These versions la= ck support
=C2=A0 =C2=A0for current and recommended cipher suites, and various governm= ent and
=C2=A0 =C2=A0industry profiiles of applications using TLS now mandate avoid= ing
=C2=A0 =C2=A0these old TLS versions.=C2=A0 TLSv1.2 has been the recommended= version for
=C2=A0 =C2=A0IETF protocols since 2008, providing sufficient time to transi= tion
=C2=A0 =C2=A0away from older versions.=C2=A0 Products having to support old= er versions
=C2=A0 =C2=A0increase the attack surface unnecessarily and increase opportu= nities
=C2=A0 =C2=A0for misconfigurations.=C2=A0 Supporting these older versions a= lso requires
=C2=A0 =C2=A0additional effort for library and product maintenance.

=C2=A0 =C2=A0This document updates the backward compatibility sections of T= LS RFCs
=C2=A0 =C2=A0[[list TBD]] to prohibit fallback to TLSv1.0 and TLSv1.1.=C2= =A0 This
=C2=A0 =C2=A0document also updates RFC 7525.




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

The IETF Secretariat



--

Best regards,
Kathleen

_______________________________________________
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
--0000000000003119250570bcb5b0-- From nobody Wed Jul 11 18:09:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C326130FB1 for ; Wed, 11 Jul 2018 18:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJM9qi7yEYnH for ; Wed, 11 Jul 2018 18:09:48 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 F0BEB130FA8 for ; Wed, 11 Jul 2018 18:09:47 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id 13-v6so52781260ois.1 for ; Wed, 11 Jul 2018 18:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V7A1od95tqJQn35Q+hPeYC6ZfOg3yw0w6+bCWICP4BA=; b=tMRJib4TQ3ZADyih4IFnNJV1sAPTVfCxJikh74sFQE/3C51okfbwKf/Sey+hAcyujc 5U4cIo5RwFToEZGobuPpzjyMESpIYu0eKVJ7FMnHcIz56I3P6RsQl4AXrYsxVg1qMtat Sis7cGXb6Y8P57ARjWiSLlWpm/BzC7OHrTcVaz3pLpV6WD+x6b3elNQ4Z2JlVBBDOqN6 XrBiZVweG8USQOERb/RDAWmEnuAqzSLyrBBmzeKNBnboEttUezZMfAPHuJcwptZ3A/3F iuzzhfrWkMrtTZpiPF7Sz67sp6j8AeW/EUy104UhKxGgTmMhbcM5Rqh9y9aIWVOqfiho 6i7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V7A1od95tqJQn35Q+hPeYC6ZfOg3yw0w6+bCWICP4BA=; b=WXZ4llaz2Yfu4762IZdblyWHQHthXYgVNlA9Vh3j4ANAbh+u6kr3DoS5ZuSVCseCN0 KFsMFSaYFgTSevpR0++36rryc5RIGGAMsye9jJ3SXaKJmZ8c/dN9vWa3JwA8ntCjuVeW I0kJTYBr8rqPNpebpG6LjQ9LFycXb1DGuqrYSvQE/zq1SsZJXtpHoBd4Fa9rMUuK58EB zYk6v55UoAVPkiutmW17sjDwpvLqjnG47Zd8SC+Y0Zr1+bCbqffuUnJbbIMnYA99b9OL fk0uores+H/aTT4LTBsSWYMEEX1TzGq2WOZC1fE9YHKtuJeyvNqGT4jUmXRcSiIZ1D92 E7Tw== X-Gm-Message-State: AOUpUlGUVjMVYHE54WrE11WCfcAK6Bk8oPUscqf1cP64H6oVFWZ3Gz4j g/HBiao6SnX32P5xpLhZ0l4F2hs3o6gB+BKzPMs= X-Google-Smtp-Source: AAOMgpcmqQXjnVj4v7W7ij3PJXDzjjnN3rdVvUMeByaCvMQnsiGo/YP+GA8SJTF+jdPoukX/FAJAB3q9tuNUhuVS1yk= X-Received: by 2002:aca:3d43:: with SMTP id k64-v6mr182359oia.166.1531357787215; Wed, 11 Jul 2018 18:09:47 -0700 (PDT) MIME-Version: 1.0 References: <99A6D467-EF66-464F-A26B-940D2198461E@sn3rd.com> <7B24E9CF-18D0-4264-B4CF-6FEFCECC9E81@sn3rd.com> In-Reply-To: <7B24E9CF-18D0-4264-B4CF-6FEFCECC9E81@sn3rd.com> From: Martin Thomson Date: Thu, 12 Jul 2018 11:09:36 +1000 Message-ID: To: Sean Turner Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] TLS@IETF102 agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2018 01:09:50 -0000 Given the volume of discussion on the list, I assume that the deprecated TLS 1.*<1.2 discussion is for the purpose of an announcement only. There are things on the agenda that I (personally) would prefer to see set aside for more time on that topic. For instance, we've had very little list activity on delegated credentials. On Thu, Jul 12, 2018 at 3:28 AM Sean Turner wrote: > > A revised agenda has been posted. > > spt > > > On Jul 10, 2018, at 12:15, Sean Turner wrote: > > > > All, > > > > The agenda has been posted: > > https://datatracker.ietf.org/meeting/102/materials/agenda-102-tls-02 > > > > Note that we have two sessions: > > > > tls Session 1 (2:00 requested) > > Monday, 16 July 2018, Afternoon Session I 1330-1530 > > Room Name: Place du Canada size: 300 > > --------------------------------------------- > > tls Session 2 (1:00 requested) > > Thursday, 19 July 2018, Afternoon Session III 1810-1910 > > Room Name: Laurier size: 250 > > --------------------------------------------- > > > > spt > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From wang.haiguang.shieldlab@huawei.com Thu Jul 12 02:30:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22D071310A0 for ; Thu, 12 Jul 2018 02:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifkUDVsuYZnE for ; Thu, 12 Jul 2018 02:30:47 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 3711913109F for ; Thu, 12 Jul 2018 02:30:47 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 71BE597FAC5B5 for ; Thu, 12 Jul 2018 10:30:42 +0100 (IST) Received: from SINEML703-CAH.china.huawei.com (10.223.161.53) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 12 Jul 2018 10:30:43 +0100 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.226]) by SINEML703-CAH.china.huawei.com ([10.223.161.53]) with mapi id 14.03.0382.000; Thu, 12 Jul 2018 17:30:41 +0800 From: Wang Haiguang To: "" Thread-Topic: Regarding the identity bidding issue when using raw public key with TLS Thread-Index: AdQZwdlVj/TBP8f2Sb2VA3i7V7Sehw== Date: Thu, 12 Jul 2018 09:30:40 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309E0B122F@SINEML521-MBX.china.huawei.com> Accept-Language: en-SG, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.215.22.72] Content-Type: multipart/alternative; boundary="_000_0AE05CBFB1A6A0468C8581DAE58A31309E0B122FSINEML521MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Thu, 12 Jul 2018 04:43:02 -0700 Subject: [TLS] Regarding the identity bidding issue when using raw public key with TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2018 10:06:48 -0000 --_000_0AE05CBFB1A6A0468C8581DAE58A31309E0B122FSINEML521MBXchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sIGV2ZXJ5b25lLA0KDQpUbyBzb2x2ZSB0aGUgY29tcGxleCBpc3N1ZSBjYXVzZWQgYnkg dGhlIGNlcnRpZmljYXRpb24sIGluIFJGQyA3MjUwLCBpdCBpcyByZWNvbW1lbmRlZCB0byB1c2Ug cmF3IHB1YmxpYyBmb3IgYXV0aGVudGljYXRpb24uDQpIb3dldmVyLCB3aGVuIHVzaW5nIFJBVyBw dWJsaWMgZGlyZWN0bHkgZm9yIGF1dGhlbnRpY2F0aW9uLCBpZGVudGl0eSBhbmQgcHVibGljIGtl eSBiaW5kaW5nIGlzIHJlcXVpcmVkLiBUaGF0IGlzLCBzZXJ2ZXIgbmVlZCB0byBtYWludGFpbiBh IGxhcmdlIHRhYmxlIHRvIG1hcCB0aGUgcHVibGljIGtleSBhbmQgaWRlbnRpdHkuDQpGb3IgbmV0 d29ya3Mgd2l0aCBodWdlIGFtb3VudCBvZiBJb1QgZGV2aWNlcywgdGhlIG1haW50ZW5hbmNlIG9m IHN1Y2ggYSBodWdlIGRhdGFiYXNlIG1pZ2h0IGJlIGEgY2hhbGxlbmdlIGlzc3VlLg0KDQpDdXJy ZW50bHkgd2UgYXJlIHRoaW5raW5nIHRvIHVzZSBpZGVudGl0eS1iYXNlIHB1YmxpYyBrZXkgdG8g c29sdmUgdGhlIGlzc3VlLiAgSXMgdGhlcmUgYW55IGJldHRlciBzb2x1dGlvbiB0byBzb2x2ZSB0 aGUgaWRlbnRpdHkgYmluZGluZyBpc3N1ZT8NCg0KQ2FuIGFueW9uZSBnaXZlIHVzIHNvbWUgY29t bWVudHMgcmVnYXJkaW5nIHVzaW5nIElCQyBhcyByYXcgcHVibGljIGtleSBmb3IgVExTIGZvciBt YXNzaXZlIElvVCBhdXRoZW50aWNhdGlvbj8NCg0KQmVzdCByZWdhcmRzLg0KDQpIYWlndWFuZw0K DQoNCg== --_000_0AE05CBFB1A6A0468C8581DAE58A31309E0B122FSINEML521MBXchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0 eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGlu Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHls ZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkhlbGxvLCBldmVyeW9uZSwgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0 OTdEIj5UbyBzb2x2ZSB0aGUgY29tcGxleCBpc3N1ZSBjYXVzZWQgYnkgdGhlIGNlcnRpZmljYXRp b24sIGluIFJGQyA3MjUwLCBpdCBpcyByZWNvbW1lbmRlZCB0byB1c2UgcmF3IHB1YmxpYyBmb3Ig YXV0aGVudGljYXRpb24uDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SG93ZXZlciwgd2hlbiB1c2luZyBSQVcg cHVibGljIGRpcmVjdGx5IGZvciBhdXRoZW50aWNhdGlvbiwgaWRlbnRpdHkgYW5kIHB1YmxpYyBr ZXkgYmluZGluZyBpcyByZXF1aXJlZC4gVGhhdCBpcywgc2VydmVyIG5lZWQgdG8gbWFpbnRhaW4g YSBsYXJnZSB0YWJsZSB0byBtYXAgdGhlIHB1YmxpYyBrZXkgYW5kIGlkZW50aXR5Lg0KPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPkZvciBuZXR3b3JrcyB3aXRoIGh1Z2UgYW1vdW50IG9mIElvVCBkZXZpY2VzLCB0 aGUgbWFpbnRlbmFuY2Ugb2Ygc3VjaCBhIGh1Z2UgZGF0YWJhc2UgbWlnaHQgYmUgYSBjaGFsbGVu Z2UgaXNzdWUuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkN1cnJlbnRs eSB3ZSBhcmUgdGhpbmtpbmcgdG8gdXNlIGlkZW50aXR5LWJhc2UgcHVibGljIGtleSB0byBzb2x2 ZSB0aGUgaXNzdWUuICZuYnNwO0lzIHRoZXJlIGFueSBiZXR0ZXIgc29sdXRpb24gdG8gc29sdmUg dGhlIGlkZW50aXR5IGJpbmRpbmcgaXNzdWU/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5DYW4gYW55b25lIGdpdmUgdXMgc29tZSBjb21tZW50cyByZWdhcmRpbmcgdXNpbmcg SUJDIGFzIHJhdyBwdWJsaWMga2V5IGZvciBUTFMgZm9yIG1hc3NpdmUgSW9UIGF1dGhlbnRpY2F0 aW9uPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+SGFpZ3Vhbmc8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_0AE05CBFB1A6A0468C8581DAE58A31309E0B122FSINEML521MBXchi_-- From nobody Thu Jul 12 04:54:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0AA11310D8 for ; Thu, 12 Jul 2018 04:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id STkeavt0M26E for ; Thu, 12 Jul 2018 04:53:55 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A29B81292F1 for ; Thu, 12 Jul 2018 04:53:55 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id 26-v6so4587237qks.9 for ; Thu, 12 Jul 2018 04:53:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0vVwXXuwYZeXSSPeZqMf6TO0E2Owi5rcz0KiEnGhMIY=; b=il7Y4dl7s+QkaHNYqMMny65djB+O1RnaY+lwjCy9+GEYnW8rw/Oz8gJYrVJ98zSMzV rB7ZG6lrRfGRKjrsorQdRDc8cpC+xyBH/zlWeAs3SJ+zC5APkh705HD8cq/hCjHJQX1h JML6PpW2EJrYLFK26SXdUg2mJKifgI92VuKk0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0vVwXXuwYZeXSSPeZqMf6TO0E2Owi5rcz0KiEnGhMIY=; b=ISzTx2rct9QioBU39DAiiMl6MtQF0HcjrQQFLifrrg2ZDVO2aKTh//DARjxYLObDtF 4YFqoYSZ0PXxsnD0SfLNw370a/OCFzJc6V6b4ngFDI8B1ezNF0HNqoSKq9K28rE0PQOb ctm/YP8JsUZ0SWOjI+eEnOAmwgEiN2xSRpftu0v49EudcYN5LNwkpc/pOD4x5tAxp80z X05Ma3Zw+vBn0na1bN2mZa5aCXH8IvFmzPSn3c3FLSqeRId+bXq2IzOMb7qOHziWe9J3 OfRhXns7cCxftf0Ex5cSmc4P0wbVN6u8fRQcuIX5n/COL3/or2wiaDPS8/DNy+v/o6vn DJCw== X-Gm-Message-State: AOUpUlGK89B6DhS2dnFK9ALpZj9B2XiAby5iOIbA3W2RIqj+Ht+pZRPk F0TWghOoL6B4onBBvGTAV8pnjgJwJas= X-Google-Smtp-Source: AAOMgpeZKD3FJfFqkljtO/0EDtq8jcEI9pWpFaPnOz/zn7mApY/ijBRpDYeinvNhFAHdVDCbjOWYiw== X-Received: by 2002:a37:ba43:: with SMTP id k64-v6mr1350598qkf.106.1531396434809; Thu, 12 Jul 2018 04:53:54 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id m15-v6sm17520563qki.44.2018.07.12.04.53.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 04:53:53 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Thu, 12 Jul 2018 07:53:52 -0400 Cc: TLS WG Content-Transfer-Encoding: quoted-printable Message-Id: <53EF61F1-3E53-4624-B83A-86BC79027BFE@sn3rd.com> References: <99A6D467-EF66-464F-A26B-940D2198461E@sn3rd.com> <7B24E9CF-18D0-4264-B4CF-6FEFCECC9E81@sn3rd.com> To: Martin Thomson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] TLS@IETF102 agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2018 11:53:58 -0000 tl;dr: YES. Most of what I was looking for in terms of discussion (i.e., is this a = crazy idea) is happening on the list right now. I=E2=80=99m hoping that = only folks who haven=E2=80=99t said something on list can get up and say = =E2=80=9Coh hey great=E2=80=9D or =E2=80=9Coh hey wait a minute=E2=80=9D. spt > On Jul 11, 2018, at 21:09, Martin Thomson = wrote: >=20 > Given the volume of discussion on the list, I assume that the > deprecated TLS 1.*<1.2 discussion is for the purpose of an > announcement only. There are things on the agenda that I (personally) > would prefer to see set aside for more time on that topic. For > instance, we've had very little list activity on delegated > credentials. > On Thu, Jul 12, 2018 at 3:28 AM Sean Turner wrote: >>=20 >> A revised agenda has been posted. >>=20 >> spt >>=20 >>> On Jul 10, 2018, at 12:15, Sean Turner wrote: >>>=20 >>> All, >>>=20 >>> The agenda has been posted: >>> https://datatracker.ietf.org/meeting/102/materials/agenda-102-tls-02 >>>=20 >>> Note that we have two sessions: >>>=20 >>> tls Session 1 (2:00 requested) >>> Monday, 16 July 2018, Afternoon Session I 1330-1530 >>> Room Name: Place du Canada size: 300 >>> --------------------------------------------- >>> tls Session 2 (1:00 requested) >>> Thursday, 19 July 2018, Afternoon Session III 1810-1910 >>> Room Name: Laurier size: 250 >>> --------------------------------------------- >>>=20 >>> spt >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jul 12 04:58:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE3C1292F1 for ; Thu, 12 Jul 2018 04:58:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bxk-St26LD-W for ; Thu, 12 Jul 2018 04:58:25 -0700 (PDT) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3F0130E12 for ; Thu, 12 Jul 2018 04:58:24 -0700 (PDT) Received: by mail-qk0-x230.google.com with SMTP id z74-v6so15236795qkb.10 for ; Thu, 12 Jul 2018 04:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BwGKEtJr2FTLNUuvb1FO3wcHj3Ln/j277cN69Akisx4=; b=msDZb3bN+nahJQtBB3ahdVLL+vuj+pCId2eX/C//D+bUP8DKyfszfP91sH/CUGqyYu 5IVf3QTl/CgV0/EDm3x9uAyioGSJI0j1SPQIaXyMarD9u3m+Ra2y/KyByETysPabWzc4 giWQ6igQ1JQ495s505ytwukR+Cs9yJtZReqD0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=BwGKEtJr2FTLNUuvb1FO3wcHj3Ln/j277cN69Akisx4=; b=KwN40jTKA/7eSseO1s5nFB0BdMRM9ZAu/7GsoQtvy8IoiofCdVFb2hMnoq5omvHJmm kGrB6FN76+gvqRq8OlnUBr36oC+mFn/T50LE4zbYDS+SN0HsoOCyjNwtNkwlDhcZ44cs 65w3np90S7GCLviLDaeDlqo++r3oGXv+rWyJrD+s045G36E19iKhh1it0J0cotddunig 8dJ9eUQ9tPwtkQDeb43ah+o3JHDhUDMX2ncxAQ012H8cpWjUxDHcORb7CYJrCnpru7ip xITpjOXqA9Df01HdWVYRPnlMdzGknPN5JyWqn5ai9yI1taaqih3QXoLM+I+VeOprY1ae UVxA== X-Gm-Message-State: AOUpUlHUvaUDdR8P75yRBY7ZCppTr1Xu3KWcVnlMvZ1Rrx2nXdB/0tia L525++jTPj1cx6RfmIv3FYcvlOEueMM= X-Google-Smtp-Source: AAOMgpd/LAuDkzh6joTj6CpLkydqYEtyjjqzSIB+GEgNG7qi1Pasb+ryK15BxzkBn/GVWx3cp2nLUA== X-Received: by 2002:a37:7044:: with SMTP id l65-v6mr1365168qkc.187.1531396704198; Thu, 12 Jul 2018 04:58:24 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id r185-v6sm9871164qkf.53.2018.07.12.04.58.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 04:58:23 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Thu, 12 Jul 2018 07:58:17 -0400 Cc: Chris Wood , TLS WG , Joe Salowey Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180711200607.GD59001@mit.edu> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] draft note to WG list announcing Chris X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2018 11:58:28 -0000 I also think you don=E2=80=99t need to justify it. 3 chairs for an = important WG is not unheard of ;) spt > On Jul 12, 2018, at 01:54, Joseph Salowey wrote: >=20 > I do not think you need to justify the addition. =20 >=20 > On Wed, Jul 11, 2018 at 1:17 PM, Christopher Wood = wrote: > I=E2=80=99m fine with any of the three variants. Thanks for drafting = this! >=20 > Cheers, > Chris > On Jul 11, 2018, 10:06 PM +0200, Benjamin Kaduk , = wrote: >> Any comments? >>=20 >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >> Subject: please welcome new co-chair Chris Wood >>=20 >> Hi everyone, >>=20 >> Please welcome Chris Wood as a third TLS co-chair, joining >> Sean and Joe at the helm. Chris will be in Montreal, so be >> sure to introduce yourself! >>=20 >> Thanks, >>=20 >> Ben >> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% >>=20 >> I considered but (so far) rejected saying something like "the >> WG is busy enough to justify three chairs for the long term" or >> "Sean and Joe both expect to remain in the role", which perhaps >> will cause some people to wonder if there is transition planning >> afoot, but probably not many people. >>=20 >> -Ben >=20 From nobody Thu Jul 12 05:17:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36CED130E71 for ; Thu, 12 Jul 2018 05:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j5J_T-jD69wd for ; Thu, 12 Jul 2018 05:17:35 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A363130DF1 for ; Thu, 12 Jul 2018 05:17:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 75DD24FBDA; Thu, 12 Jul 2018 15:17:32 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 7CwGUxEcvf0K; Thu, 12 Jul 2018 15:17:32 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id E9B9527F; Thu, 12 Jul 2018 15:17:29 +0300 (EEST) Date: Thu, 12 Jul 2018 15:17:29 +0300 From: Ilari Liusvaara To: Wang Haiguang Cc: "" Message-ID: <20180712121729.GA3925@LK-Perkele-VII> References: <0AE05CBFB1A6A0468C8581DAE58A31309E0B122F@SINEML521-MBX.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0AE05CBFB1A6A0468C8581DAE58A31309E0B122F@SINEML521-MBX.china.huawei.com> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2018 12:17:39 -0000 On Thu, Jul 12, 2018 at 09:30:40AM +0000, Wang Haiguang wrote: > Hello, everyone, > > To solve the complex issue caused by the certification, in RFC 7250, > it is recommended to use raw public for authentication. > However, when using RAW public directly for authentication, > identity and public key binding is required. That is, server need > to maintain a large table to map the public key and identity. > For networks with huge amount of IoT devices, the maintenance of > such a huge database might be a challenge issue. It seems to me that getting the information to provisioning to the database is the biggest issue. Any semi-decent database program should not even be breaking sweat with million row table on quite low-end server hardware (if the indexing is even remotely sane). > Currently we are thinking to use identity-base public key to solve > the issue. Is there any better solution to solve the identity binding > issue? If you do not want to use server-side database, create an internal CA and issue as compact certificates as possible. The overhead should be in low two hundred bytes. But this does not save you from having to figure out what those IoT devices actually are! > Can anyone give us some comments regarding using IBC as raw public > key for TLS for massive IoT authentication? I do not think there is any way currently to do that. The only defined signature algorithms are ([*] means removed from TLS 1.3): - RSA PKCS#1 v1.5[*] - DSA[*] - ECDSA - EdDSA2 (Ed25519 and Ed448) These are also the only algorithms that can be used with raw public key authentication. None of these is IBC algorithm.. Also, the way the raw public keys work is the same in both TLS 1.2 and 1.3 (the precise messages are different, but it still works the same). -Ilari From nobody Thu Jul 12 05:31:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE671310FF for ; Thu, 12 Jul 2018 05:31:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVFzRVREsrRC for ; Thu, 12 Jul 2018 05:31:08 -0700 (PDT) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CE03130DDE for ; Thu, 12 Jul 2018 05:31:08 -0700 (PDT) Received: by mail-qk0-x22b.google.com with SMTP id y4-v6so15285970qka.5 for ; Thu, 12 Jul 2018 05:31:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MPFwj9kvaTS7SDpuw2cRJ0IacgJeZbft7txk8xLcILs=; b=XPdrgthN8+mpWmIJzvyxmCpP0bHrfAoOF8xdspYDj/gN8mHF3prhiOS5Q1XUgbBEu7 sK0Ywx1fgBQhMN+kIPlqKIebbxKwl0MzGayhJa70B1Nf3P2s2PNIEfpGR6/1yUbBH1Xj /j2eDfmG0sg+RYEys9CtKCQLPRsnIWQWuKVyE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MPFwj9kvaTS7SDpuw2cRJ0IacgJeZbft7txk8xLcILs=; b=THYY2668WSnN9xVGTA8Yvz+Gxbvgans4sdL6WUT3o5+GbONQF8U2MH/bGsAYaDYG/4 T8vTV1UqPKgEIxr3Njz/i2CwnNePyPBb5JcZmP2vHWj4hhOtD+p7jZzHnWCCoevNW57S jrLQegxaT8YwAMxhZ9n83EWZqx+eDI7JgbzfCzb0vNQ0A+ETjfuKnBKOADpRMNb8iMNA gPZDn3PK8em5Bxz06RswnSRG92Eq8RUk5REwpDMVjCyDjlYXXVbUsbbwTrlQO2hiFK4L ImOTVIA72n72hgKEKBTGDc4aFrThw2bCV34MYkX1BFoL/mE53aaTjhW5kF/qa16A7tF8 UD7A== X-Gm-Message-State: AOUpUlEMZ1hBOYbkBGBNO/vEpRZHY+ghlCBC8euLco6x6hbwTXokDM/+ PM7b+hqmEw0uvA+K8kqnRkt4xw== X-Google-Smtp-Source: AAOMgpfQtO1aUwMppGA5xMACJhhzTki5F/SpyUVEqbfsTUJgKewEuPe84Ead3YKlutsFet+FJNyDqQ== X-Received: by 2002:a37:1194:: with SMTP id 20-v6mr1552422qkr.379.1531398667590; Thu, 12 Jul 2018 05:31:07 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id f64-v6sm24590803qkf.2.2018.07.12.05.31.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 05:31:06 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: <20180607210040.GA13834@akamai.com> Date: Thu, 12 Jul 2018 08:31:05 -0400 Cc: David Benjamin , tls@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <8180D46B-F76D-4496-88CA-615ADED675CD@sn3rd.com> References: <152830634989.6264.3566629916218895862@ietfa.amsl.com> <20180607210040.GA13834@akamai.com> To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] I-D Action: draft-ietf-tls-grease-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2018 12:31:12 -0000 > On Jun 7, 2018, at 17:00, Benjamin Kaduk = wrote: >=20 > But, of course, we should actually ask instead of guessing... If nobody has asked yet, I can do it. spt= From nobody Thu Jul 12 06:14:17 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599A7130E3C for ; Thu, 12 Jul 2018 06:14:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWT7jJMfr2Az for ; Thu, 12 Jul 2018 06:14:14 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0DD4130DE2 for ; Thu, 12 Jul 2018 06:14:13 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id e19-v6so9778922qtp.8 for ; Thu, 12 Jul 2018 06:14:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NqZTnwn8lmAlFfoz9yKYfz3IzBRFIPChUM8YvVtShMk=; b=CRFsyYxyacBPZKqBCpflxP+1fbFMU6OGN2OHr0a170htWB5JvSqDdqfNJ/daout/iO S8WDNlT9olnXVcQJ4B8s9IWNtl4lN3iYJOagzsO9AYmuIcQ6rjG9DDTc9xUvOlycNtl6 YdpOPDauTuWd8gjvw/rd2RygmpD5U6IdNYCl8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=NqZTnwn8lmAlFfoz9yKYfz3IzBRFIPChUM8YvVtShMk=; b=t72matTv/hzXJlLX8EX11fcjtgZdQn2JblG7/dUwS/Box+wSyKEtsySLZV7v4iqFpA Q7uGXkcCIPVHkG0MY6/4nRgszf2xGLFiZZJHAmkijxEPjMt+QJa1s+cicjs96MbfxQNx xuSEjMac4ojAy2Vi4YVzoFoKoF5DnPBIBJpvYKjt9Dfs7nfAowh3Y4aso41LDvkHxbuB ur2Rf+09FuM7VVG2qLJop1Po0YkgcVgozqxJyfg97cxw1VVBOJ1toAk87T3o0bt8fxdX LlGfRdxTCKcBCf96eosVYo5O8H7kn9PhiFkbJZ/efrqgroSIvx1oYFsh4YnpIEJrXuR2 4qDA== X-Gm-Message-State: AOUpUlG5UHRNmP/ymirShGWx+q3eunWvoGYQVakwKtr4XHiGpZMov3u3 mzo5J6E+sXqFs0Q3tMy3/nZxKA== X-Google-Smtp-Source: AAOMgpdnxt/QloTabp/1JMItJAM5PLC6sOBTC7FOQ1FFf7VGcqhxh7o3D4bC3/zVU2gbwUOJlD33SQ== X-Received: by 2002:ac8:3913:: with SMTP id s19-v6mr1778830qtb.344.1531401253127; Thu, 12 Jul 2018 06:14:13 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id j16-v6sm8095151qtp.13.2018.07.12.06.14.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 06:14:12 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Sean Turner In-Reply-To: Date: Thu, 12 Jul 2018 09:14:10 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20180711200607.GD59001@mit.edu> To: Benjamin Kaduk , TLS WG X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] draft note to WG list announcing Chris X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2018 13:14:15 -0000 mea culpa =E2=80=A6 I didn=E2=80=99t intend to steal Ben=E2=80=99s = thunder. spt= From nobody Thu Jul 12 06:15:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39493130E3C for ; Thu, 12 Jul 2018 06:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id th1PviJvMWeJ for ; Thu, 12 Jul 2018 06:15:41 -0700 (PDT) Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0223130DE2 for ; Thu, 12 Jul 2018 06:15:41 -0700 (PDT) X-AuditID: 12074424-75dff70000004a80-df-5b47547caeb8 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 0D.B2.19072.C74574B5; Thu, 12 Jul 2018 09:15:40 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w6CDFd0r017893 for ; Thu, 12 Jul 2018 09:15:40 -0400 Received: from mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6CDFZOb025456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 12 Jul 2018 09:15:38 -0400 Date: Thu, 12 Jul 2018 08:15:35 -0500 From: Benjamin Kaduk To: tls@ietf.org Message-ID: <20180712131535.GH59001@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHIsWRmVeSWpSXmKPExsUixCmqrVsT4h5tMO+ItsWn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DK+H6xnbFgO2PFuTszmRoYexi7GDk5JARMJGa+fMraxcjFISSw mEni47Ll7BDOEUaJfzs+QzkPmCQaZu5mB2lhEVCVeP7oGJjNJqAi0dB9mbmLkYNDREBAovml GEhYWEBfYuHBO2AbeAV0JGZuvscEYQtKnJz5hAXEZhbQkrjx7yUTSCuzgLTE8n8cIGFRAWWJ vX2H2Ccw8s5C0jELSccshI4FjMyrGGVTcqt0cxMzc4pTk3WLkxPz8lKLdM31cjNL9FJTSjcx ggKJ3UVlB2N3j/chRgEORiUe3g0cbtFCrIllxZW5hxglOZiURHmlrFyjhfiS8lMqMxKLM+KL SnNSiw8xSnAwK4nwXpoCVM6bklhZlVqUD5OS5mBREufNXcQYLSSQnliSmp2aWpBaBJOV4eBQ kuBlD3aPFhIsSk1PrUjLzClBSDNxcIIM5wEargFSw1tckJhbnJkOkT/FaMzx7VrXJGaOP++n TmIWYsnLz0uVEufdHgRUKgBSmlGaBzcNlAwksvfXvGIUB3pOmHcGyEAeYCKBm/cKaBUT0Kq4 FJA/iksSEVJSDYxbl8y5e9nnWUrpGUHdiZaLcveel5h1hSnrh3dI0dwfXzPSn2oc8rjMnf+6 eoXh+Q7HHyWyeXbeun8+MP2OuH2n8cWqrakvE3dPzHy0etNGjg868Xrrtyo0Ry6KyYzav3Oj hX/9ket+KltuJ3nfUdRx7J+QHvHFSqzs9elHc9KPXdfvvnDk+P+XSizFGYmGWsxFxYkAG4a8 fOECAAA= Archived-At: Subject: [TLS] please welcome new co-chair Chris Wood X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2018 13:15:44 -0000 Hi everyone, Please welcome Chris Wood as a third TLS co-chair, joining Sean and Joe at the helm. Chris will be in Montreal, so be sure to introduce yourself! Thanks, Ben From nobody Thu Jul 12 09:43:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42079130EE3 for ; Thu, 12 Jul 2018 09:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id naAcmLQ8b2lB for ; Thu, 12 Jul 2018 09:43:29 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (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 99AAB130E89 for ; Thu, 12 Jul 2018 09:43:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1531413809; x=2395327409; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Vqnnl66k6Hht72sMSkmiVOkYOjXnTIIYMS+DTom5jho=; b=m515gLtcbOyGA3Ttsob5KDe9+7Q4zmu83+Np1KmIMJaje0bUANPN6Nq2bQk11/7+ 7iodeCrgZsTwyFzMPfewbyQBBJikGLOw11sPudg7P5BJV6zWFcCFxzviB2ivDJHr N7OlddeBnCdHHgHl81E93qTz9g4+VJoBdpLkQeRDQ8pKav7tYbzmiuIo77nkvePW bF/BP1eYRXWzQ7zFf50I81Q6kl1WkEXZOcs5oSIA+tOzY8mWPcXCqPIigwcAeTdX 3DLwpmiLV9l34vkcnH4GJ9F5mj8xUkcZ9I1IjTaHgl/s6SGBJh/uQ0VKQSITlj34 wuwwvkVJ+os39pg+5Tf6mw==; X-AuditID: 11973e15-0d35e9e000007130-ca-5b47853131e7 Received: from mr2-mtap-s03.rno.apple.com (mr2-mtap-s03.rno.apple.com [17.179.226.135]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 15.90.28976.135874B5; Thu, 12 Jul 2018 09:43:29 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by mr2-mtap-s03.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PBR006PHIGHRHH0@mr2-mtap-s03.rno.apple.com>; Thu, 12 Jul 2018 09:43:29 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBR00H00IC2IQ00@nwk-mmpp-sz12.apple.com>; Thu, 12 Jul 2018 09:43:27 -0700 (PDT) X-Va-A: X-Va-T-CD: d5ecc7ff8822007e2c0bf038590e6211 X-Va-E-CD: 8747f88187c6cf6ab5b9eafabe39986e X-Va-R-CD: 626fe6ffa9594b43331ea2e3e4daac39 X-Va-CD: 0 X-Va-ID: 548da252-8782-4b3a-90b5-c0b6fa68bf2e X-V-A: X-V-T-CD: d5ecc7ff8822007e2c0bf038590e6211 X-V-E-CD: 8747f88187c6cf6ab5b9eafabe39986e X-V-R-CD: 626fe6ffa9594b43331ea2e3e4daac39 X-V-CD: 0 X-V-ID: 4035d754-f641-417e-ac2f-598485ed6598 Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PBR00H00IBEHQ00@nwk-mmpp-sz12.apple.com>; Thu, 12 Jul 2018 09:43:26 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-12_06:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1 Received: from [17.234.91.36] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PBR00KIPIG9JK50@nwk-mmpp-sz12.apple.com>; Thu, 12 Jul 2018 09:43:26 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi In-reply-to: <20180712131535.GH59001@mit.edu> Date: Thu, 12 Jul 2018 09:43:20 -0700 Cc: tls@ietf.org Message-id: <43041A24-50B3-492E-9757-150AD246FF99@apple.com> References: <20180712131535.GH59001@mit.edu> To: Benjamin Kaduk , Chris Wood X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOIsWRmVeSWpSXmKPExsUiuPlRu65hq3u0weYbihbLN85ksvh0vovR gcljyZKfTB5NZ44yBzBFcdmkpOZklqUW6dslcGV8OjmHveAgc8W2FXfYGhgfMHUxcnJICJhI 3LuyjrWLkYtDSOAAk8TtD49ZQRK8AoISPybfY+li5OBgFpCXOHheFiTMLKAl8f1RKwtE/Xom iblPdrFDOF1MErOW90BNZZf482sHC4StLfF1fR8rjN138wgzjP3/+iyoOJfEgq2noWxdie5D Z6DmsEmsP7EEytaSuNy/gxHGPvV5DguMfW/SDaiZnBLnv0xkh7B1JN7vOMAMcVwnk8TESw+g GrIl9sy/CzUoWOLPoR6ooi+MEvNetoEVCQtIS3RduMsKYVtKPJu6nA0UFGxA2w6sMQIJcwId +mJaM9hxLAKqEu8v72SGBJGAxLlnL5ghoWgj8WbKLDYQWwjooM3bL4CNFBFwlNi4cDr7BEbF WUiBPQsR2LOQAnsBI/MqRqHcxMwc3cw8M73EgoKcVL3k/NxNjKCUMN1OdAfjmVVWhxgFOBiV eHgdMtyjhVgTy4orcw8xSnOwKInzyp1yiRYSSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAuP6p 1saPi9ZcfHl1w2TpqYrp/9c3PprO9vzsn9kqm36GyXwq3sfqvGHZtI9qF1dvLDkQ8+zSlSQ1 xwblgnTrfR/qJnNoFjQ7hSgyz2gpERdgj9E5eeSvyvqVOrachZkZsdFPk03XLjKb1MKo5/Z1 Pe+J18q/lqnIXpzMZ7lu9fENT9jnTeo5ME+JpTgj0VCLuag4EQCPVRp+6gIAAA== Archived-At: Subject: Re: [TLS] please welcome new co-chair Chris Wood X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 12 Jul 2018 16:43:32 -0000 Congratulations, Chris! David > On Jul 12, 2018, at 06:15, Benjamin Kaduk wrote: > > Hi everyone, > > Please welcome Chris Wood as a third TLS co-chair, joining > Sean and Joe at the helm. Chris will be in Montreal, so be > sure to introduce yourself! > > Thanks, > > Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jul 12 18:28:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3A00130F06 for ; Thu, 12 Jul 2018 18:28:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51Pj80CPnLl2 for ; Thu, 12 Jul 2018 18:28:05 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BED73130DDC for ; Thu, 12 Jul 2018 18:28:05 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id f18-v6so25846842qtp.10 for ; Thu, 12 Jul 2018 18:28:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=Gr4DeUn5mjNeV1QKsv4Kt79PM8NqOJYPkMbp5r6Hq9k=; b=kTjT20nHKVEjp4WHhMnKJ3HESh1DscwCfK36PuEVaSXe8WUeVNOhzYd2YFVThqpJ1Q qWOmkIAMRGHniMRKMK+3cT958HTYQDBUS8jBuUi4OwW1MBD0LNDugxUWwBvp9eXV8Fcp okN5JoAfsMuQVoGSrmlg3d6EQvsDVVvn2831o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=Gr4DeUn5mjNeV1QKsv4Kt79PM8NqOJYPkMbp5r6Hq9k=; b=S+q7zsHfp7W2C+9WCNtu5OjNyOOH8BHaZTis5obXYjp3Q8bU1wicqy++FwjS4zfs1R WoGtr9304jlWL3s1RbSyRSuorOWcB4ZnO9q6pZYSPv/WITysvqEzx9W91QS5T0Oa0zcE VawnR1xfsLyhkZifpUPFhDp4Oe8WGqZGgLp0mLszp855jSm/bHo1pdQ7eJ7qPHTCP1kh /TTY6I6RtbrFmZNfXTrM+WVSXq2T1pCXdgKOhJJXHs5zcUztbvYlUlob4Y9zXEh2WQ08 00gNNTtSx515jEPuAAVK9WL5SFXKDPLfRm0gqa+JFvCa+t0buOQjkPNE7890GWI+oLsd /qsg== X-Gm-Message-State: AOUpUlGyHCNvlXMaiz/Uh9XLhjBK3joibGvYbvFJ3IFPpvJQzH7G/qb4 dEQ1FhfPKtGiZnMtjCzUaC6vECjA0FY= X-Google-Smtp-Source: AAOMgpfQuy+TxkeiZaHtnHHGW8xlj45n20UX14XBlmRV96CDzgR85I2YVU3XbwVxXzN48Xyeq4LvHw== X-Received: by 2002:a0c:d4d7:: with SMTP id y23-v6mr4946225qvh.234.1531445284887; Thu, 12 Jul 2018 18:28:04 -0700 (PDT) Received: from [172.16.0.18] ([96.231.225.148]) by smtp.gmail.com with ESMTPSA id s83-v6sm14827138qki.20.2018.07.12.18.28.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Jul 2018 18:28:04 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 12 Jul 2018 21:28:02 -0400 Message-Id: <90C53688-5C18-4FA1-811D-4D1117296666@sn3rd.com> To: TLS WG X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [TLS] TLS badges X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2018 01:28:08 -0000 All, I have uploaded the TLS badges that were used to make the TLS 1.3 = contributors' T-shirts in a variety of formats to = https://github.com/tlswg/tlswg.github.io. There are no restrictions on = their use. A special shout out to Alissa Cooper (she authorized that money be spent = to get them done), Greg Wood @ ISOC (who worked with Joe and I to get = them developed), and the folks at Ocupop (who did the design). Happy badging! spt From nobody Fri Jul 13 05:24:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 648A3130DDA for ; Fri, 13 Jul 2018 05:24:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=e-dco-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oqNTvZuJyeL for ; Fri, 13 Jul 2018 05:24:51 -0700 (PDT) Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::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 B7835130E6B for ; Fri, 13 Jul 2018 05:24:50 -0700 (PDT) Received: by mail-lj1-x22c.google.com with SMTP id 1-v6so24356878ljv.9 for ; Fri, 13 Jul 2018 05:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=e-dco-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OF3IQsTwzXCFAI1PWKBn6tdJh4g003mgldkgVI1Zg48=; b=xAI+p8K6WksnXTuQyq5GfFEATJ6bYPqQZZCSQN3Zbpn8mbVBaBN12RYmwgBUCjX0kI 5481mVmaynXEhV3DgmHZkNiVsFYzXVCSv2jjNnzKCYUL+cslTxAq3rRvgAdvtmIOWpJm fG9lTz5Ur54zuN+l04/gAu2G1Fs4nD9l37exeQD6TzdGqr/M8fulvAnQ0RYFqvYVFvJ0 mE6Eo/u8bD3Nuxhcee+nhF9fxfxm9i9qFonqvsVo4XDR8CSvokQTEko9QbUQX7stBa+3 bugQBc5Lr0yAVQif/LPe8dCRNnCSGWC0H0G43WHJ4J7KxVKOvljYGkw48Eh9qm6ImeR1 hK/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OF3IQsTwzXCFAI1PWKBn6tdJh4g003mgldkgVI1Zg48=; b=bSdrrNfpjF3j3InorNlIc/lBO/bGZP21MhO9fa5hsP9cOddh2ZQmOyRMzUsS6Mth+/ RXq8EJCDs4YdWLU0+WK6sLMDYZUJeJ9jc0ox9KlbqRampog08gaarZAIUwGZbbe5jvir bT/ib7g8nLABoEYS8HQR3M0C1SmbHELOsJM/wHtDzQpwTj3K0+/8dMWPhyB84izqUjhm p8VPxMJxTykwFOHDjyqPzRSLMDxSUlOoY9ICdsAoz9o9CiYOQ2t1xFeJsNdMNIL0vS85 AN6tjBVUyzgJw32Mm51xOuoeSlGPDC3P45inO6M+riougMk+X/YwdPme0IAxZFZun0FQ 0Y9A== X-Gm-Message-State: AOUpUlGZhrIdG29gsIaMxAke+Ye8O9hnlwoIzZSed5sL8PTj347whFMS YSuBYxGaCgtqfpGLr6zcaxNcwDq4bPZ1zbUq5ZqLNZx4 X-Google-Smtp-Source: AAOMgpcEjxc71TQOznTOZSmOA4EP/ySltLJa0b9C6Hv0E4K54bCNtXrVkHcfjc990Jvy0Rd582E6RLyCdkUCAebekrc= X-Received: by 2002:a2e:4951:: with SMTP id b17-v6mr3085210ljd.67.1531484688789; Fri, 13 Jul 2018 05:24:48 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:f8d:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 05:24:48 -0700 (PDT) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> From: nalini elkins Date: Fri, 13 Jul 2018 08:24:48 -0400 Message-ID: To: Stephen Farrell Cc: "" Content-Type: multipart/alternative; boundary="000000000000daca810570e09051" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2018 12:24:54 -0000 --000000000000daca810570e09051 Content-Type: text/plain; charset="UTF-8" Stephen, Sorry for the late reply. I was travelling to Montreal from India and was jet lagged. > >> I am thinking the following: >> >> Location: U.S. / Canada (possibly U.K.) >> >> - 3 banks (hopefully from the top 5) >> - 3 large insurance companies (includes back end processing) >> - 3 U.S. federal government agencies >> - 3 companies in the Wall Street / Stock brokerage sector (includes back >> end processing) >> - 3 large credit card / processors (ex. Visa, Discover, MasterCard, etc.) >> - 3 in the retail sector (Home Depot, Target, Lowes, et al) >Those are pretty small numbers unless they're interacting with >a lot of TLS services. It'd be hard to know if they'd be >representative of something or not if they're anonymised in the >results. I would expect that these people would have quite a few applications using TLS. Telnet, FTP, MQSeries, SMTP, and many written by the organization itself. What numbers do you feel WOULD be representative? > I'd encourage you to try get people to be open about > things here - there's no particular shame in having 10% TLSv1.0 > sessions after all:-) It isn't a question of shame but it is just a bit too much information to provide a potential adversary. That is, to say that Stock Exchange XYZ has n% of TLS1.0 clients provides a potential attacker too much information. As I say, most organizations that I know are trying very hard to migrate from older versions. It is not as simple as it might seem. If the organizations need to be identified by name, then I think this will be a show stopper for any kind of data that I might be able to provide. Having said that, I completely understand (and share) your distrust of anonymous data. I am at a loss as to how to proceed. I am open to any constructive suggestions. Thanks, Nalini On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell wrote: > > Hiya, > > On 11/07/18 06:45, nalini elkins wrote: > > Stephen, > > > >> I'd love to add more detail like that and/or more sections for other > > protocols if folks have data to offer with references. > > > > I believe that I can reach out to various people I know. Please comment > > if my methodology is acceptable and if you think this will be helpful. > > It's not whether the methodology is acceptable to me or not > but whether or not the references to the numbers are credible > for readers:-) > > A few comment below, > > > > > I am thinking the following: > > > > Location: U.S. / Canada (possibly U.K.) > > > > - 3 banks (hopefully from the top 5) > > - 3 large insurance companies (includes back end processing) > > - 3 U.S. federal government agencies > > - 3 companies in the Wall Street / Stock brokerage sector (includes back > > end processing) > > - 3 large credit card / processors (ex. Visa, Discover, MasterCard, > etc.) > > - 3 in the retail sector (Home Depot, Target, Lowes, et al) > > Those are pretty small numbers unless they're interacting with > a lot of TLS services. It'd be hard to know if they'd be > representative of something or not if they're anonymised in the > results. I'd encourage you to try get people to be open about > things here - there's no particular shame in having 10% TLSv1.0 > sessions after all:-) > > > > > Note: I put in "back end processing" because these are the folks that > most > > often have many connections to other business partners and so in some > ways > > have the most complex systems to deal with. > > > > Note #2: This is aspirational! I hope I can get all these people to > > cooperate. I will try at least to get some in each category. > > > > > > I will ask them the following questions: > > > > 1. How many applications do you have? (This may end up being only the > > mission critical ones as otherwise it may be too hard to obtain.) > > I'm not sure that's so interesting for this question. And I'm not > sure that different people would count things as applications in > the same way. > > > 2. How many are using TLS and how many are still plain text? (We will > > disregard SSH and other such variants.) > > Again, that's not so interesting here. > > > 3. What percent of clients are using a pre-TLS1.2 version? (This will > be > > an estimation. > I don't see why this needs to be estimated, this is kinda the key > measurement needed and easy to measure. There should be no need for > anyone to stick their thumb in the air for this:-) > > It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and > TLSv1.3) and to say for how many TLS sessions or hosts/IPs the > figures apply. > > And of course providing as much context as possible so that it's > possible to understand the numbers and whether or not the numbers > from different sources are based on the same or different kinds of > measurement. > > > > > 4. Do you have an active project to migrate off of older versions of > TLS? > > Sure. > > > > > 5. What do you estimate your percent of clients using pre-TLS1.2 > versions > > to be next year? > > I don't see how this'd be so useful. Aaking about the historic and > current rates of change of use of the various protocol versions would > be good though if people have that, but they may not. > > S. > > > > > > > Please let me know if this will be of use & if you have suggestions for > > improvement. > > > > Thanks, > > Nalini > > > > > > > > > > On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> > > wrote: > > > >> > >> Hi Nalini, > >> > >> On 10/07/18 04:50, nalini elkins wrote: > >>> It would be nice to see some of this reflected in the draft rather than > >>> only statistics on browsers. The real usage of these protocols is far > >>> more complex. > >> > >> I didn't have time before the I-D cutoff but have since > >> added a section on mail to the repo pre-01 version. (See > >> [1] section 3.2.) I'd love to add more detail like that > >> and/or more sections for other protocols if folks have > >> data to offer with references. > >> > >> Consistent with other folks' numbers sent to the list > >> yesterday, (though based on a much smaller sat of data I > >> guess;-) my data shows 10.6% use of TLSv1.0 when talking > >> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K > >> IP addresses that listen on port 25 (mail servers). > >> > >> What I don't currently have is a rate of change for that > >> figure. I think that rate of change is the important number > >> for figuring out what to do in the next while. E.g. The > >> WG might conclude that if the percentage of TLSv1.0 is > >> moving down nicely, we should be a bit patient. If it's > >> not moving at all, we can probably move now or in 5 years > >> without that being different. If we're not sure, then get > >> more data... > >> > >> Cheers, > >> S. > >> > >> [1] > >> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast > >> er/draft-moriarty-tls-oldversions-diediedie.txt > >> > > > > > > > -- Thanks, Nalini Elkins President Enterprise Data Center Operators www.e-dco.com --000000000000daca810570e09051 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Stephen,<= /span>

Sorry for the late repl= y.=C2=A0 =C2=A0I was travelling to Montreal from India and
was jet lagged.

>=C2=A0
>> I am thinking t= he following:
>>=C2=A0
>> Location: U.S. / Canada (possibly U.K.)
>>=C2=A0
>> -=C2=A0 3 banks (hopefully from the top 5)
>> -=C2=A0 3 large= insurance companies=C2=A0 (includes back end processing)
>> -=C2=A0 3 U.S. = federal government agencies
>> -=C2=A0 3 companies in the Wall Street / Stock = brokerage sector (includes back
>> end processing)
>> -=C2=A0 3 large credit card= / processors (ex. Visa, Discover, MasterCard, etc.)
= >> -=C2=A0 3 in the retai= l sector (Home Depot, Target, Lowes, et al)

>Those are pretty sma= ll numbers unless they're interacting with
>a lot of TLS services. It'd b= e hard to know if they'd be
>representative of something or not if they'r= e anonymised in the
>results.=C2=A0

I would expect that these people would have quite a few applications=C2=A0=
using TLS.=C2= =A0 =C2=A0Telnet, FTP, MQSeries, SMTP, and many written by the
=
organization itself.

What numbers do you feel WOU= LD be representative?

>=C2=A0I&= #39;d encourage you to try get people to be open about
> things here - there's no = particular shame in having 10% TLSv1.0
> sessions after all:-)

It isn't a question of shame but it is ju= st a bit too much information
to provide a potential adversary.= =C2=A0 That is, to say that Stock Exchange XYZ
has n% of TLS1.0 c= lients provides a potential attacker too much
information.=C2=A0 = =C2=A0As I say, most organizations that I know are trying very hard
to migrate from older versions.=C2=A0 It is not as simple as it might se= em.

If the organizations need to be identified by = name, then I think this will
be a show stopper for any kind of da= ta that I might be able to provide.
Having said that, I completel= y understand (and share) your distrust of=C2=A0
anonymous data.= =C2=A0 =C2=A0I am at a loss as to how to proceed.

= I am open to any constructive suggestions.

Thanks,=
Nalini


=
On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell= <stephen.farrell@cs.tcd.ie> wrote:

Hiya,

On 11/07/18 06:45, nalini elkins wrote:
>=C2=A0 Stephen,
>
>> I'd love to add more detail like that and/or more sections for= other
> protocols if folks have data to offer with references.
>
> I believe that I can reach out to various people I know.=C2=A0 =C2=A0P= lease comment
> if my methodology is acceptable and if you think this will be helpful.=

It's not whether the methodology is acceptable to me or not
but whether or not the references to the numbers are credible
for readers:-)

A few comment below,

>
> I am thinking the following:
>
> Location: U.S. / Canada (possibly U.K.)
>
> -=C2=A0 3 banks (hopefully from the top 5)
> -=C2=A0 3 large insurance companies=C2=A0 (includes back end processin= g)
> -=C2=A0 3 U.S. federal government agencies
> -=C2=A0 3 companies in the Wall Street / Stock brokerage sector (inclu= des back
> end processing)
> -=C2=A0 3 large credit card / processors (ex. Visa, Discover, MasterCa= rd, etc.)
> -=C2=A0 3 in the retail sector (Home Depot, Target, Lowes, et al)

Those are pretty small numbers unless they're interacting with
a lot of TLS services. It'd be hard to know if they'd be
representative of something or not if they're anonymised in the
results. I'd encourage you to try get people to be open about
things here - there's no particular shame in having 10% TLSv1.0
sessions after all:-)

>
> Note: I put in "back end processing" because these are the f= olks that most
> often have many connections to other business partners and so in some = ways
> have the most complex systems to deal with.
>
> Note #2:=C2=A0 This is aspirational!=C2=A0 I hope I can get all these = people to
> cooperate.=C2=A0 I will try at least to get some in each category.
>
>
> I will ask them the following questions:
>
> 1.=C2=A0 How many applications do you have?=C2=A0 (This may end up bei= ng only the
> mission critical ones as otherwise it may be too hard to obtain.)

I'm not sure that's so interesting for this question. And I'm n= ot
sure that different people would count things as applications in
the same way.

> 2.=C2=A0 =C2=A0How many are using TLS and how many are still plain tex= t?=C2=A0 (We will
> disregard SSH and other such variants.)

Again, that's not so interesting here.

> 3.=C2=A0 =C2=A0What percent of clients are using a pre-TLS1.2 version?= =C2=A0 (This will be
> an estimation.
I don't see why this needs to be estimated, this is kinda the key
measurement needed and easy to measure. There should be no need for
anyone to stick their thumb in the air for this:-)

It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and
TLSv1.3) and to say for how many TLS sessions or hosts/IPs the
figures apply.

And of course providing as much context as possible so that it's
possible to understand the numbers and whether or not the numbers
from different sources are based on the same or different kinds of
measurement.

>
> 4.=C2=A0 =C2=A0Do you have an active project to migrate off of older v= ersions of TLS?

Sure.

>
> 5.=C2=A0 =C2=A0What do you estimate your percent of clients using pre-= TLS1.2 versions
> to be next year?

I don't see how this'd be so useful. Aaking about the historic and<= br> current rates of change of use of the various protocol versions would
be good though if people have that, but they may not.

S.

>
>
> Please let me know if this will be of use & if you have suggestion= s for
> improvement.
>
> Thanks,
> Nalini
>
>
>
>
> On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
>
>>
>> Hi Nalini,
>>
>> On 10/07/18 04:50, nalini elkins wrote:
>>> It would be nice to see some of this reflected in the draft ra= ther than
>>> only statistics on browsers.=C2=A0 =C2=A0The real usage of the= se protocols is far
>>> more complex.
>>
>> I didn't have time before the I-D cutoff but have since
>> added a section on mail to the repo pre-01 version. (See
>> [1] section 3.2.) I'd love to add more detail like that
>> and/or more sections for other protocols if folks have
>> data to offer with references.
>>
>> Consistent with other folks' numbers sent to the list
>> yesterday, (though based on a much smaller sat of data I
>> guess;-) my data shows 10.6% use of TLSv1.0 when talking
>> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
>> IP addresses that listen on port 25 (mail servers).
>>
>> What I don't currently have is a rate of change for that
>> figure. I think that rate of change is the important number
>> for figuring out what to do in the next while. E.g. The
>> WG might conclude that if the percentage of TLSv1.0 is
>> moving down nicely, we should be a bit patient. If it's
>> not moving at all, we can probably move now or in 5 years
>> without that being different. If we're not sure, then get
>> more data...
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast
>> er/draft-moriarty-tls-oldversions-diediedie.txt
>>
>
>
>



--
Thanks,
Nalini Elkins
Pr= esident
Enterprise Data Center Operato= rs

--000000000000daca810570e09051-- From nobody Fri Jul 13 05:36:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C4C130FF3 for ; Fri, 13 Jul 2018 05:36:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNIfuhva1uPV for ; Fri, 13 Jul 2018 05:36:21 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D103E130FFA for ; Fri, 13 Jul 2018 05:36:20 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id j68-v6so11672066ywg.1 for ; Fri, 13 Jul 2018 05:36:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UuY24UJEvCzZWwiUVljEXbPityhYVanfr/LyztnKM1c=; b=up+z+FKBzw1K0fxC1Ysq188tO38hdpgkB0Fuem/Fw7pIy56tZs6hwkJV6OlBdXNYH2 1pp0zxeeAkmrNhm8jiq2lypCTK1JUg2sZ3uibAMQs3UVzfKvvWGad3N1/R5mR0Rqpenc zfbWu2cDwOuSngp+YYUaLO/LH84HjViCsPNCFn/w5SMX/3d8H2AQgfn/lh6ZbVJ1vY7A XBHKEx6xyx6WTQId+vACHuSCXhTx1K9iF/uSSospn0YXpRt1SCG58nUdAVUmJCjk5wD6 ofcTZF1KQ1RQBR5umgLE/GMH+fPhZTp3k0EWR2F5tQmJIlv8lWsVlPyNogMFbfXnyCak 0ODA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UuY24UJEvCzZWwiUVljEXbPityhYVanfr/LyztnKM1c=; b=nftt7sQ2XxQJAN1qauDa87qio0oAUkEb7gP+/58nCpNGopBofO6rVmJ9LpQvMJ4UjS OTOkGrW5TNcqX/ECC34pVDEQLc28+PxGeIE8GVg6uUAeMCqRLQVWKU1wc3KC79jjCfej /3qBvGa4eyq9TClSbHw7tJwOaCbPADxN+OUg6FyGeekh+cz/XVn2NspvSuLU3vlw90rQ bDLmaSkIKv9suTa1OMlff9nIhFhDvkDuLyiNdfhoqGd8L5eM4exwSUW+gsgS9S4b6+H9 9z9G6PAztGwE8B9IFdioFIBKnY21L59JpYAX2kclz0dnHhjDfKLcABSckrjfqgki/jUj TifA== X-Gm-Message-State: AOUpUlH3Wcj7hDltlEyG4JAeJ2Y58xH+F1hFTs9cC3mLY6aTusgyc84t KZZwLlxC44bkr0TgSqptcDHZskU8gYK3i+KYjAXeaQ== X-Google-Smtp-Source: AAOMgpdNX2DwIH0eaPNSJKoCfPekovnC4CcNeLZUOQ3AnDrmgIq+Ii5Q1TJyWXUIHejmhzdBjQmRvtTHeFjbN2setHk= X-Received: by 2002:a0d:f2c7:: with SMTP id b190-v6mr3085468ywf.489.1531485380054; Fri, 13 Jul 2018 05:36:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a81:6b83:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 05:35:39 -0700 (PDT) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> From: Eric Rescorla Date: Fri, 13 Jul 2018 05:35:39 -0700 Message-ID: To: nalini elkins Cc: Stephen Farrell , "" Content-Type: multipart/alternative; boundary="0000000000000ea7010570e0ba77" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2018 12:36:32 -0000 --0000000000000ea7010570e0ba77 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 13, 2018 at 5:24 AM, nalini elkins wrote: > Stephen, > > Sorry for the late reply. I was travelling to Montreal from India and > was jet lagged. > > > > >> I am thinking the following: > >> > >> Location: U.S. / Canada (possibly U.K.) > >> > >> - 3 banks (hopefully from the top 5) > >> - 3 large insurance companies (includes back end processing) > >> - 3 U.S. federal government agencies > >> - 3 companies in the Wall Street / Stock brokerage sector (includes > back > >> end processing) > >> - 3 large credit card / processors (ex. Visa, Discover, MasterCard, > etc.) > >> - 3 in the retail sector (Home Depot, Target, Lowes, et al) > > >Those are pretty small numbers unless they're interacting with > >a lot of TLS services. It'd be hard to know if they'd be > >representative of something or not if they're anonymised in the > >results. > > I would expect that these people would have quite a few applications > using TLS. Telnet, FTP, MQSeries, SMTP, and many written by the > organization itself. > > What numbers do you feel WOULD be representative? > > > I'd encourage you to try get people to be open about > > things here - there's no particular shame in having 10% TLSv1.0 > > sessions after all:-) > > It isn't a question of shame but it is just a bit too much information > to provide a potential adversary. That is, to say that Stock Exchange XYZ > has n% of TLS1.0 clients provides a potential attacker too much > information. > Well, this seems like it is primarily true due to deficiencies in TLS 1.0 or the software running it, in which case so much the more reason to recommend updating. As I say, most organizations that I know are trying very hard > to migrate from older versions. It is not as simple as it might seem. > > If the organizations need to be identified by name, then I think this will > be a show stopper for any kind of data that I might be able to provide. > Having said that, I completely understand (and share) your distrust of > anonymous data. I am at a loss as to how to proceed. > As I said earlier, I don't think the deployment fraction is that relevant here. The question of whether the IETF should deprecate TLS 1.2 is primarily one we should make based on the technical merits of the older protocol versions compared to TLS 1.2. Given that we know that 1.2 is more secure and that 1.0 has serious deficiencies, it seems like the two next questions are: 1. Are there respects in which TLS 1.2 is not an adequate replacement for TLS 1.0? I think the answer here is pretty much no. [0] 2. Is the deployment of TLS 1.2 so low that it's just silly to tell people to cut over. That's clearly not true in the Web environment, though perhaps it's true in some other environment. However, that would be a number more like 30% TLS 1.0 rather than 5-10%. Is the number that high? Absent those things, then it's a sensible recommendation for the IETF to make. -Ekr [0] This is less obvious for TLS 1.3 in that we removed features with low usage. > I am open to any constructive suggestions. > > Thanks, > Nalini > > > On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell < > stephen.farrell@cs.tcd.ie> wrote: > >> >> Hiya, >> >> On 11/07/18 06:45, nalini elkins wrote: >> > Stephen, >> > >> >> I'd love to add more detail like that and/or more sections for other >> > protocols if folks have data to offer with references. >> > >> > I believe that I can reach out to various people I know. Please >> comment >> > if my methodology is acceptable and if you think this will be helpful. >> >> It's not whether the methodology is acceptable to me or not >> but whether or not the references to the numbers are credible >> for readers:-) >> >> A few comment below, >> >> > >> > I am thinking the following: >> > >> > Location: U.S. / Canada (possibly U.K.) >> > >> > - 3 banks (hopefully from the top 5) >> > - 3 large insurance companies (includes back end processing) >> > - 3 U.S. federal government agencies >> > - 3 companies in the Wall Street / Stock brokerage sector (includes >> back >> > end processing) >> > - 3 large credit card / processors (ex. Visa, Discover, MasterCard, >> etc.) >> > - 3 in the retail sector (Home Depot, Target, Lowes, et al) >> >> Those are pretty small numbers unless they're interacting with >> a lot of TLS services. It'd be hard to know if they'd be >> representative of something or not if they're anonymised in the >> results. I'd encourage you to try get people to be open about >> things here - there's no particular shame in having 10% TLSv1.0 >> sessions after all:-) >> >> > >> > Note: I put in "back end processing" because these are the folks that >> most >> > often have many connections to other business partners and so in some >> ways >> > have the most complex systems to deal with. >> > >> > Note #2: This is aspirational! I hope I can get all these people to >> > cooperate. I will try at least to get some in each category. >> > >> > >> > I will ask them the following questions: >> > >> > 1. How many applications do you have? (This may end up being only the >> > mission critical ones as otherwise it may be too hard to obtain.) >> >> I'm not sure that's so interesting for this question. And I'm not >> sure that different people would count things as applications in >> the same way. >> >> > 2. How many are using TLS and how many are still plain text? (We will >> > disregard SSH and other such variants.) >> >> Again, that's not so interesting here. >> >> > 3. What percent of clients are using a pre-TLS1.2 version? (This >> will be >> > an estimation. >> I don't see why this needs to be estimated, this is kinda the key >> measurement needed and easy to measure. There should be no need for >> anyone to stick their thumb in the air for this:-) >> >> It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and >> TLSv1.3) and to say for how many TLS sessions or hosts/IPs the >> figures apply. >> >> And of course providing as much context as possible so that it's >> possible to understand the numbers and whether or not the numbers >> from different sources are based on the same or different kinds of >> measurement. >> >> > >> > 4. Do you have an active project to migrate off of older versions of >> TLS? >> >> Sure. >> >> > >> > 5. What do you estimate your percent of clients using pre-TLS1.2 >> versions >> > to be next year? >> >> I don't see how this'd be so useful. Aaking about the historic and >> current rates of change of use of the various protocol versions would >> be good though if people have that, but they may not. >> >> S. >> >> > >> > >> > Please let me know if this will be of use & if you have suggestions for >> > improvement. >> > >> > Thanks, >> > Nalini >> > >> > >> > >> > >> > On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> >> > wrote: >> > >> >> >> >> Hi Nalini, >> >> >> >> On 10/07/18 04:50, nalini elkins wrote: >> >>> It would be nice to see some of this reflected in the draft rather >> than >> >>> only statistics on browsers. The real usage of these protocols is >> far >> >>> more complex. >> >> >> >> I didn't have time before the I-D cutoff but have since >> >> added a section on mail to the repo pre-01 version. (See >> >> [1] section 3.2.) I'd love to add more detail like that >> >> and/or more sections for other protocols if folks have >> >> data to offer with references. >> >> >> >> Consistent with other folks' numbers sent to the list >> >> yesterday, (though based on a much smaller sat of data I >> >> guess;-) my data shows 10.6% use of TLSv1.0 when talking >> >> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K >> >> IP addresses that listen on port 25 (mail servers). >> >> >> >> What I don't currently have is a rate of change for that >> >> figure. I think that rate of change is the important number >> >> for figuring out what to do in the next while. E.g. The >> >> WG might conclude that if the percentage of TLSv1.0 is >> >> moving down nicely, we should be a bit patient. If it's >> >> not moving at all, we can probably move now or in 5 years >> >> without that being different. If we're not sure, then get >> >> more data... >> >> >> >> Cheers, >> >> S. >> >> >> >> [1] >> >> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast >> >> er/draft-moriarty-tls-oldversions-diediedie.txt >> >> >> > >> > >> > >> > > > > -- > Thanks, > Nalini Elkins > President > Enterprise Data Center Operators > www.e-dco.com > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --0000000000000ea7010570e0ba77 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 13, 2018 at 5:24 AM, nalini elkins <nalini.elkins@e-= dco.com> wrote:
Steph= en,

Sorry for the late reply.=C2=A0 =C2=A0I was travelling to Montre= al from India and
was jet lagged.

>= =C2=A0
>> I am thinking the following:
>>=C2=A0
>>= ; Location: U.S. / Canada (possibly U.K.)
>>=C2=A0
>> -=C2=A0 3 banks (hopefully fr= om the top 5)
>> -=C2=A0 3 large insurance compa= nies=C2=A0 (includes back end processing)
>> -= =C2=A0 3 U.S. federal government agencies
>> -= =C2=A0 3 companies in the Wall Street / Stock brokerage sector (includes ba= ck
>> end processing)
>&= gt; -=C2=A0 3 large credit card / processors (ex. Visa, Discover, MasterCar= d, etc.)
>> -=C2=A0 3 in the retail sector (Home= Depot, Target, Lowes, et al)

>Those are pretty= small numbers unless they're interacting with
>= ;a lot of TLS services. It'd be hard to know if they'd be>representative of something or not if they're anonymise= d in the
>results.=C2=A0

I would expect tha= t these people would have quite a few applications=C2=A0
<= span style=3D"font-size:12.8px;float:none;display:inline">using TLS.=C2=A0 = =C2=A0Telnet, FTP, MQSeries, SMTP, and many written by the
organization it= self.

What numbers do you feel WOULD be representative?
=

>=C2=A0I= 9;d encourage you to try get people to be open about
> things here - th= ere's no particular shame in having 10% TLSv1.0
&g= t; sessions after all:-)

It isn't a question of shame but i= t is just a bit too much information
to provide a potential adver= sary.=C2=A0 That is, to say that Stock Exchange XYZ
has n% of TLS= 1.0 clients provides a potential attacker too much
information.= =C2=A0

Well, this seems like it= is primarily true due to deficiencies in TLS 1.0
or the software= running it, in which case so much the more reason
to recommend u= pdating.


=
=C2=A0As I say, most organizations that I know are t= rying very hard
to migrate from older versions.=C2=A0 It is not a= s simple as it might seem.

If the organizations ne= ed to be identified by name, then I think this will
be a show sto= pper for any kind of data that I might be able to provide.
Having= said that, I completely understand (and share) your distrust of=C2=A0
anonymous data.=C2=A0 =C2=A0I am at a loss as to how to proceed.

As I said earlier, I don't thin= k the deployment fraction is that relevant
here.
The question of whether the IETF should deprecate TLS 1.2 is p= rimarily
one we should make based on the technical merits of the = older protocol
versions compared to TLS 1.2. Given that we know t= hat 1.2 is more
secure and that 1.0 has serious deficiencies, it = seems like the two next
questions are:

1= . Are there respects in which TLS 1.2 is not an adequate replacement
<= div>for TLS 1.0? I think the answer here is pretty much no. [0]
2= . Is the deployment of TLS 1.2 so low that it's just silly to tell peop= le to
cut over. That's clearly not true in the Web environmen= t, though perhaps
it's true in some other environment. Howeve= r, that would be a number
more like 30% TLS 1.0 rather than 5-10%= . Is the number that high?

Absent those things, th= en it's a sensible recommendation for the
IETF to make.

-Ekr

[0] This is less obvi= ous for TLS 1.3 in that we removed features with
low usage.
=




I am open to any constructive suggest= ions.

Thanks,
Nalini


On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell <ste= phen.farrell@cs.tcd.ie> wrote:

Hiya,

On 11/07/18 06:45, nalini elkins wrote:
>=C2=A0 Stephen,
>
>> I'd love to add more detail like that and/or more sections for= other
> protocols if folks have data to offer with references.
>
> I believe that I can reach out to various people I know.=C2=A0 =C2=A0P= lease comment
> if my methodology is acceptable and if you think this will be helpful.=

It's not whether the methodology is acceptable to me or not
but whether or not the references to the numbers are credible
for readers:-)

A few comment below,

>
> I am thinking the following:
>
> Location: U.S. / Canada (possibly U.K.)
>
> -=C2=A0 3 banks (hopefully from the top 5)
> -=C2=A0 3 large insurance companies=C2=A0 (includes back end processin= g)
> -=C2=A0 3 U.S. federal government agencies
> -=C2=A0 3 companies in the Wall Street / Stock brokerage sector (inclu= des back
> end processing)
> -=C2=A0 3 large credit card / processors (ex. Visa, Discover, MasterCa= rd, etc.)
> -=C2=A0 3 in the retail sector (Home Depot, Target, Lowes, et al)

Those are pretty small numbers unless they're interacting with
a lot of TLS services. It'd be hard to know if they'd be
representative of something or not if they're anonymised in the
results. I'd encourage you to try get people to be open about
things here - there's no particular shame in having 10% TLSv1.0
sessions after all:-)

>
> Note: I put in "back end processing" because these are the f= olks that most
> often have many connections to other business partners and so in some = ways
> have the most complex systems to deal with.
>
> Note #2:=C2=A0 This is aspirational!=C2=A0 I hope I can get all these = people to
> cooperate.=C2=A0 I will try at least to get some in each category.
>
>
> I will ask them the following questions:
>
> 1.=C2=A0 How many applications do you have?=C2=A0 (This may end up bei= ng only the
> mission critical ones as otherwise it may be too hard to obtain.)

I'm not sure that's so interesting for this question. And I'm n= ot
sure that different people would count things as applications in
the same way.

> 2.=C2=A0 =C2=A0How many are using TLS and how many are still plain tex= t?=C2=A0 (We will
> disregard SSH and other such variants.)

Again, that's not so interesting here.

> 3.=C2=A0 =C2=A0What percent of clients are using a pre-TLS1.2 version?= =C2=A0 (This will be
> an estimation.
I don't see why this needs to be estimated, this is kinda the key
measurement needed and easy to measure. There should be no need for
anyone to stick their thumb in the air for this:-)

It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and
TLSv1.3) and to say for how many TLS sessions or hosts/IPs the
figures apply.

And of course providing as much context as possible so that it's
possible to understand the numbers and whether or not the numbers
from different sources are based on the same or different kinds of
measurement.

>
> 4.=C2=A0 =C2=A0Do you have an active project to migrate off of older v= ersions of TLS?

Sure.

>
> 5.=C2=A0 =C2=A0What do you estimate your percent of clients using pre-= TLS1.2 versions
> to be next year?

I don't see how this'd be so useful. Aaking about the historic and<= br> current rates of change of use of the various protocol versions would
be good though if people have that, but they may not.

S.

>
>
> Please let me know if this will be of use & if you have suggestion= s for
> improvement.
>
> Thanks,
> Nalini
>
>
>
>
> On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie= >
> wrote:
>
>>
>> Hi Nalini,
>>
>> On 10/07/18 04:50, nalini elkins wrote:
>>> It would be nice to see some of this reflected in the draft ra= ther than
>>> only statistics on browsers.=C2=A0 =C2=A0The real usage of the= se protocols is far
>>> more complex.
>>
>> I didn't have time before the I-D cutoff but have since
>> added a section on mail to the repo pre-01 version. (See
>> [1] section 3.2.) I'd love to add more detail like that
>> and/or more sections for other protocols if folks have
>> data to offer with references.
>>
>> Consistent with other folks' numbers sent to the list
>> yesterday, (though based on a much smaller sat of data I
>> guess;-) my data shows 10.6% use of TLSv1.0 when talking
>> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K
>> IP addresses that listen on port 25 (mail servers).
>>
>> What I don't currently have is a rate of change for that
>> figure. I think that rate of change is the important number
>> for figuring out what to do in the next while. E.g. The
>> WG might conclude that if the percentage of TLSv1.0 is
>> moving down nicely, we should be a bit patient. If it's
>> not moving at all, we can probably move now or in 5 years
>> without that being different. If we're not sure, then get
>> more data...
>>
>> Cheers,
>> S.
>>
>> [1]
>> https://github.com/sftcd/tls-o<= wbr>ldversions-diediedie/blob/mast
>> er/draft-moriarty-tls-oldversions-diediedie.txt
>>
>
>
>



--
<= div>
Thanks,
Nalini Elkins
P= resident
Enterprise Data Center Operat= ors


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


--0000000000000ea7010570e0ba77-- From nobody Fri Jul 13 06:26:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B054130934 for ; Fri, 13 Jul 2018 06:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MozXvWgw5JqP for ; Fri, 13 Jul 2018 06:26:00 -0700 (PDT) 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 C252B126BED for ; Fri, 13 Jul 2018 06:25:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BACB6BE4C; Fri, 13 Jul 2018 14:25:54 +0100 (IST) 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 quLYJGC3y8Pp; Fri, 13 Jul 2018 14:25:54 +0100 (IST) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5F0FCBE38; Fri, 13 Jul 2018 14:25:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1531488354; bh=y3aGYhKCv6kTA206N08uFWKZuX5P38NStcnGbeTwBp8=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=Rdvgfb2dAdw4IuIlW+/FYhHpQhJjho4yscUGmMdjGW9zYxc2IsdOB8LPHt51XjbPM 4E23nrLVGJi3iGzD5sl7e/MuuU5jo92HEepAgsa3ttGZx+eJi9xADp3s2KKb1s0CTH +lgK0VJz3rmcuhpg4q+Rp6qI7TR6BPYZRBARvmZ0= To: nalini elkins Cc: "" References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <91231fb5-8d5a-c825-8ac7-dd34d46db746@cs.tcd.ie> Date: Fri, 13 Jul 2018 14:25:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="MIPZJVicCfevS13EVjbrTdPz5NCHWuFVj" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 13 Jul 2018 13:26:03 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --MIPZJVicCfevS13EVjbrTdPz5NCHWuFVj Content-Type: multipart/mixed; boundary="h84Wt1TkDxAOJh768qZnVqF35jJJl7CfG"; protected-headers="v1" From: Stephen Farrell To: nalini elkins Cc: "" Message-ID: <91231fb5-8d5a-c825-8ac7-dd34d46db746@cs.tcd.ie> Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> In-Reply-To: --h84Wt1TkDxAOJh768qZnVqF35jJJl7CfG Content-Type: multipart/mixed; boundary="------------40466D233376289BA8E0445A" Content-Language: en-GB This is a multi-part message in MIME format. --------------40466D233376289BA8E0445A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 13/07/18 13:24, nalini elkins wrote: > Stephen, >=20 > Sorry for the late reply. I was travelling to Montreal from India and= > was jet lagged. No problem. And that'll be me tomorrow:-) I generally agree with Ekr's mail just now but a little bit more below... >=20 >> >>> I am thinking the following: >>> >>> Location: U.S. / Canada (possibly U.K.) >>> >>> - 3 banks (hopefully from the top 5) >>> - 3 large insurance companies (includes back end processing) >>> - 3 U.S. federal government agencies >>> - 3 companies in the Wall Street / Stock brokerage sector (includes = back >>> end processing) >>> - 3 large credit card / processors (ex. Visa, Discover, MasterCard, > etc.) >>> - 3 in the retail sector (Home Depot, Target, Lowes, et al) >=20 >> Those are pretty small numbers unless they're interacting with >> a lot of TLS services. It'd be hard to know if they'd be >> representative of something or not if they're anonymised in the >> results. >=20 > I would expect that these people would have quite a few applications > using TLS. Telnet, FTP, MQSeries, SMTP, and many written by the > organization itself. >=20 > What numbers do you feel WOULD be representative? Well, for externally visible services, that information is public already and visible via e.g. censys.io and similar so you could just omit those from any numbers you report I guess. I've not thought so much about things that are only visible internally, though I did (have a student:-) do some scanning of our university n/w early this year, but I've yet to look at that data so a) I still need to verify it, and b) I'm not sure how I'd report on it in detail. That said, what he reported for port 443, was ~800 regularly seen servers in the bits of n/w he scanned with: SSLv3 (18%), TLSv1.0 (35%), TLSv1.1 (0%), TLSv1.2 (45%), TLSv1.3 (0%) Which is a tad sad;-( I think many of the SSLv3 and TLSv1.0 servers were on things like printers, conferencing boxes, access points and servers that are have basically been left running when nobody cares for 'em any more. But that's the bit I'd like to go re-check before standing over those numbers. And I'd also like to know more about how those change over time too, and look at other ports and not just 443. (Doing that is somewhere down towards the end of my to-do list but maybe I'll set another student on it later in the year.) If you could quote figures (and rate of change) like those for identified networks that'd I think be useful. If you anonymise and/or aggregate then it's a bit harder to know how to interpret the data. (E.g. the fact we're a university likely means we've more forgotten web servers I guess;-). And if they're guesses and not measurements, or if it's not clear what was measured, then it's really not so useful. I guess the thing to keep in mind is that it's better if the findings can be replicated or otherwise validated. (If it helps, my student's scanning code is at [1] but I reckon there's a good bit of work to be done to make that usable for anyone else.) >> I'd encourage you to try get people to be open about >> things here - there's no particular shame in having 10% TLSv1.0 >> sessions after all:-) >=20 > It isn't a question of shame but it is just a bit too much information > to provide a potential adversary. That is, to say that Stock Exchange = XYZ > has n% of TLS1.0 clients provides a potential attacker too much > information. =20 Not sure I agree there tbh. If they're externally visible services, then it's public already. If they're not, and the attacker is inside the n/w, then the bad actor can find it out then. But I do understand organisations being shy about such things. Cheers, S. [1] https://github.com/mikeyPower/final-year-project > As I say, most organizations that I know are trying very hard > to migrate from older versions. It is not as simple as it might seem. >=20 > If the organizations need to be identified by name, then I think this w= ill > be a show stopper for any kind of data that I might be able to provide.= > Having said that, I completely understand (and share) your distrust of > anonymous data. I am at a loss as to how to proceed. >=20 > I am open to any constructive suggestions. >=20 > Thanks, > Nalini >=20 >=20 > On Wed, Jul 11, 2018 at 5:50 AM, Stephen Farrell > wrote: >=20 >> >> Hiya, >> >> On 11/07/18 06:45, nalini elkins wrote: >>> Stephen, >>> >>>> I'd love to add more detail like that and/or more sections for other= >>> protocols if folks have data to offer with references. >>> >>> I believe that I can reach out to various people I know. Please com= ment >>> if my methodology is acceptable and if you think this will be helpful= =2E >> >> It's not whether the methodology is acceptable to me or not >> but whether or not the references to the numbers are credible >> for readers:-) >> >> A few comment below, >> >>> >>> I am thinking the following: >>> >>> Location: U.S. / Canada (possibly U.K.) >>> >>> - 3 banks (hopefully from the top 5) >>> - 3 large insurance companies (includes back end processing) >>> - 3 U.S. federal government agencies >>> - 3 companies in the Wall Street / Stock brokerage sector (includes = back >>> end processing) >>> - 3 large credit card / processors (ex. Visa, Discover, MasterCard, >> etc.) >>> - 3 in the retail sector (Home Depot, Target, Lowes, et al) >> >> Those are pretty small numbers unless they're interacting with >> a lot of TLS services. It'd be hard to know if they'd be >> representative of something or not if they're anonymised in the >> results. I'd encourage you to try get people to be open about >> things here - there's no particular shame in having 10% TLSv1.0 >> sessions after all:-) >> >>> >>> Note: I put in "back end processing" because these are the folks that= >> most >>> often have many connections to other business partners and so in some= >> ways >>> have the most complex systems to deal with. >>> >>> Note #2: This is aspirational! I hope I can get all these people to= >>> cooperate. I will try at least to get some in each category. >>> >>> >>> I will ask them the following questions: >>> >>> 1. How many applications do you have? (This may end up being only t= he >>> mission critical ones as otherwise it may be too hard to obtain.) >> >> I'm not sure that's so interesting for this question. And I'm not >> sure that different people would count things as applications in >> the same way. >> >>> 2. How many are using TLS and how many are still plain text? (We w= ill >>> disregard SSH and other such variants.) >> >> Again, that's not so interesting here. >> >>> 3. What percent of clients are using a pre-TLS1.2 version? (This w= ill >> be >>> an estimation. >> I don't see why this needs to be estimated, this is kinda the key >> measurement needed and easy to measure. There should be no need for >> anyone to stick their thumb in the air for this:-) >> >> It'd be good to distinguish TLSv1.0 from TLSv1.1 (and SSLv3 and >> TLSv1.3) and to say for how many TLS sessions or hosts/IPs the >> figures apply. >> >> And of course providing as much context as possible so that it's >> possible to understand the numbers and whether or not the numbers >> from different sources are based on the same or different kinds of >> measurement. >> >>> >>> 4. Do you have an active project to migrate off of older versions o= f >> TLS? >> >> Sure. >> >>> >>> 5. What do you estimate your percent of clients using pre-TLS1.2 >> versions >>> to be next year? >> >> I don't see how this'd be so useful. Aaking about the historic and >> current rates of change of use of the various protocol versions would >> be good though if people have that, but they may not. >> >> S. >> >>> >>> >>> Please let me know if this will be of use & if you have suggestions f= or >>> improvement. >>> >>> Thanks, >>> Nalini >>> >>> >>> >>> >>> On Tue, Jul 10, 2018 at 1:51 PM, Stephen Farrell < >> stephen.farrell@cs.tcd.ie> >>> wrote: >>> >>>> >>>> Hi Nalini, >>>> >>>> On 10/07/18 04:50, nalini elkins wrote: >>>>> It would be nice to see some of this reflected in the draft rather = than >>>>> only statistics on browsers. The real usage of these protocols is= far >>>>> more complex. >>>> >>>> I didn't have time before the I-D cutoff but have since >>>> added a section on mail to the repo pre-01 version. (See >>>> [1] section 3.2.) I'd love to add more detail like that >>>> and/or more sections for other protocols if folks have >>>> data to offer with references. >>>> >>>> Consistent with other folks' numbers sent to the list >>>> yesterday, (though based on a much smaller sat of data I >>>> guess;-) my data shows 10.6% use of TLSv1.0 when talking >>>> SMTP/IMAP/POP (or HTTP) over TLS to a population of ~200K >>>> IP addresses that listen on port 25 (mail servers). >>>> >>>> What I don't currently have is a rate of change for that >>>> figure. I think that rate of change is the important number >>>> for figuring out what to do in the next while. E.g. The >>>> WG might conclude that if the percentage of TLSv1.0 is >>>> moving down nicely, we should be a bit patient. If it's >>>> not moving at all, we can probably move now or in 5 years >>>> without that being different. If we're not sure, then get >>>> more data... >>>> >>>> Cheers, >>>> S. >>>> >>>> [1] >>>> https://github.com/sftcd/tls-oldversions-diediedie/blob/mast >>>> er/draft-moriarty-tls-oldversions-diediedie.txt >>>> >>> >>> >>> >> >=20 >=20 >=20 --------------40466D233376289BA8E0445A Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------40466D233376289BA8E0445A-- --h84Wt1TkDxAOJh768qZnVqF35jJJl7CfG-- --MIPZJVicCfevS13EVjbrTdPz5NCHWuFVj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAltIqF4ACgkQWrL68XsX K+oJnQ//Sn4vEFtOoCDIHHHVkz88jV5AWGDtqZLaM4oO7l0Jg2KpN8HlyPtrwMr4 uwTbUCMti+InlXmOY0JiH++Ogl/9/my4TsJKlkVWaK+AZh8jF/TPmQaIXcwIbJSc Qc39FkNY+rjcGSp3VOFHFrUZV7NVy4RucieTYlnso9FIRcYw32xFhB0RcW2cMn+f As6QX5hlEt6Tlv4ISV4nbBIB6TGQTxGZtmI2aqei+SwySZhgALUSUr7ldFECqtip /p4rRCyPICr1WV98TpXHRUgySUAYngE9FRJPZ7Cb4P/jX+t3iDWZdzoOo6aRaa1p eNeOADoxB/XFjFOUTbJC8q9LqlSF1Y9SDqFqX9nPALMZJbE8cT/lTEe/0qBuEBvi TBDiIGZALqyzk7SyszwCsJJEqneK5LHd2qOYjPC3dtJ0MFR6MnAYWL/7oQiOyZ6x bFHdSZwecX2s9yI06vARRPPc5TpRZ2Acv1qf+cd2Y1u5ftwyrJ5CCx0OqtG0tZ4f APCPaRg/A7iaKn2If5WLIWADwHn5tVx3XrHApoCjhwagNYZNkKTaAatRTHdjr4ok IjXu4MM4wYrB5wbXRNLruziNn9eBXqu1joLzKAqXi2WMWvL14hB2OHfKd3D7ZaMA ak58tLoFU8fuPK2cWSblylruf4RjY8Y+i78dBBjFChGqZhaY9nY= =4bpV -----END PGP SIGNATURE----- --MIPZJVicCfevS13EVjbrTdPz5NCHWuFVj-- From nobody Fri Jul 13 19:04:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09185130EAE for ; Fri, 13 Jul 2018 19:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LtqiNTj0WSLc for ; Fri, 13 Jul 2018 19:04:44 -0700 (PDT) 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 7E880130E23 for ; Fri, 13 Jul 2018 19:04:44 -0700 (PDT) Received: by mail-io0-x22b.google.com with SMTP id v26-v6so32891696iog.5 for ; Fri, 13 Jul 2018 19:04:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rXbhfKCXP7Ip5LFMMW9WHd7VtrCKadXId8CayGVyB7w=; b=UNQzr+mAu9hCnO6G7QxOTZSEtTZcpYUGxuauHSmblFcLA/EXyRGfMDih5FrDuBtR/B 7avgReh9yTCtHJbzBAFadDR1f81mJFp8jECxzJwRnqdk2w9IDnM6ZShaTcMubnY66CHY 0b2myC2U9siJqFYTbkcTYUYzfJL65MG7tlrsBweburGTBqHW8V+hQcv/6poZ/EKHCD6A 92S6hIBYT3NsioL6x4qBZ8OfQgYvWMcdLpgXBR4btqLmIzxph84RLVDDurQkA75Dr/Sr 43B6hMfZfYw/iQe/241h6BVzMMkzxdlpp7Q9M7k2mlhmPSsnaB9Qe8Jc9tjC2bFYhw/Z GHFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rXbhfKCXP7Ip5LFMMW9WHd7VtrCKadXId8CayGVyB7w=; b=aKOhHxT3SBOqlw5IQG2hDewQJJjvNu+1Kofp6EceacEQd7MnjnMz1UhyMHkrJ9S+mv sDsEdYYB3Hg5/lTpFwc3SWXpU6o9kth0sOMgnNx4xjJCtWSxg9X7jMzI7z/W6ItVYwOq 52R4Cr4la27rVzHo9uVe3TVtY9VCWG9xvK1Ix63Y1Tb1m9iSrlKuP3w09hmsqZtWqIl1 YGiddI+o02/l2ra3G9EaOSz+3jiTkicrsBsd1893uF0MS+baSlvgjaFSwEU+wqZMGZPy BlYqPgoRdpJpX4vm/HOdpMULRuukQDS/wUj/eBKZNMwlb9IPQk5nS8nYozV9HEBKJOPx M4fw== X-Gm-Message-State: AOUpUlHX/MrzgVWqbmsQBkHMFEN+PzYG7ZjCGAz2+EeMvdY7uuEYD69u iIubnIsYrMrtCqAI+FjOd3aCtCi/BHAmGgyKkoe72pP3LdA= X-Google-Smtp-Source: AAOMgpcGrvNZi6mX+dalGS5SxMEIa7nsAU6gwsX+szupj/Z/V68+m05PSFzUyejdeTXOdPreBp525RRu4Xn7lw2+Xls= X-Received: by 2002:a6b:8828:: with SMTP id k40-v6mr7269622iod.68.1531533883675; Fri, 13 Jul 2018 19:04:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:7054:0:0:0:0:0 with HTTP; Fri, 13 Jul 2018 19:04:43 -0700 (PDT) In-Reply-To: References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> From: Christopher Wood Date: Fri, 13 Jul 2018 19:04:43 -0700 Message-ID: To: David Benjamin Cc: Eric Rescorla , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2018 02:04:46 -0000 (Chair hat off.) On Wed, Jul 11, 2018 at 10:37 AM, David Benjamin wrote: > On Mon, Jul 9, 2018 at 12:58 PM Eric Rescorla wrote: >> >> On Mon, Jul 9, 2018 at 9:54 AM, Eric Rescorla wrote: >>> >>> Thanks for writing this. >>> >>> I would be in favor of deprecating old versions of TLS prior to 1.2. >>> Firefox Telemetry shows that about 1% of our connections are TLS 1.1 >> >> >> This should be 1.0. >> >> >>> (on the same data set, TLS 1.3 is > 5%), and TLS 1.1 is negligible. >>> >>> This is probably a higher number than we'd be comfortable turning off >>> immediately, but it is probably worth starting the process. > > > Metrics from Chrome report 0.43% of our connections are TLS 1.0 and 0.03% of > them are TLS 1.1, which is a similar situation. I too am in favor of > deprecating them and getting things started. Our system-wide metrics indicate 0.36% and 99.6% of connections are TLS 1.0 and 1.2, respectively. This does not include all code paths, though it covers the overwhelming majority of use cases, including mobile mail. Thus, similar to others, I'm in favor of deprecating TLS 1.0 and 1.1. Best, Chris From nobody Fri Jul 13 20:53:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06C7E130F73 for ; Fri, 13 Jul 2018 18:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fbz4Fma3SdRC for ; Fri, 13 Jul 2018 18:44:48 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 67122130F6D for ; Fri, 13 Jul 2018 18:44:48 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 3F5D4E7133AFD for ; Sat, 14 Jul 2018 02:44:34 +0100 (IST) Received: from SINEML705-CAH.china.huawei.com (10.223.161.55) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Sat, 14 Jul 2018 02:44:36 +0100 Received: from SINEML521-MBS.china.huawei.com ([169.254.2.83]) by SINEML705-CAH.china.huawei.com ([10.223.161.55]) with mapi id 14.03.0382.000; Sat, 14 Jul 2018 09:44:28 +0800 From: Wang Haiguang To: "" Thread-Topic: [TLS] Regarding the identity bidding issue when using raw public key with TLS Thread-Index: AdQZwdlVj/TBP8f2Sb2VA3i7V7Seh///qsuA//438UD//Fb5wP/4rAbQ//FXLFD/4q2/gP/FWrmw/4mgufs= Date: Sat, 14 Jul 2018 01:44:28 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309E0B5E73@SINEML521-MBS.china.huawei.com> References: <0AE05CBFB1A6A0468C8581DAE58A31309E0B122F@SINEML521-MBX.china.huawei.com> <20180712121729.GA3925@LK-Perkele-VII> ,<0AE05CBFB1A6A0468C8581DAE58A31309E0B16F3@SINEML521-MBX.china.huawei.com> In-Reply-To: <0AE05CBFB1A6A0468C8581DAE58A31309E0B16F3@SINEML521-MBX.china.huawei.com> Accept-Language: en-SG, en-US Content-Language: en-SG X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.37.116] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-Mailman-Approved-At: Fri, 13 Jul 2018 20:53:08 -0700 Subject: Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2018 01:44:54 -0000 Dear ilari,=0A= =0A= Thanks very much for the reply :-=1B$B!K=1B(B. Please see my comments inlin= e below.=0A= =0A= -----Original Message-----=0A= From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]=0A= Sent: Thursday, July 12, 2018 8:17 PM=0A= To: Wang Haiguang =0A= Cc: =0A= Subject: Re: [TLS] Regarding the identity bidding issue when using raw publ= ic key with TLS=0A= =0A= On Thu, Jul 12, 2018 at 09:30:40AM +0000, Wang Haiguang wrote:=0A= > Hello, everyone,=0A= >=0A= > To solve the complex issue caused by the certification, in RFC 7250,=0A= > it is recommended to use raw public for authentication.=0A= > However, when using RAW public directly for authentication, identity=0A= > and public key binding is required. That is, server need to maintain a=0A= > large table to map the public key and identity.=0A= > For networks with huge amount of IoT devices, the maintenance of such=0A= > a huge database might be a challenge issue.=0A= =0A= It seems to me that getting the information to provisioning to the database= is the biggest issue. Any semi-decent database program should not even be = breaking sweat with million row table on quite low-end server hardware (if = the indexing is even remotely sane).=0A= =0A= [HG-1] Yes. Getting the information and provisioning to the database for ma= ssive IoT is a big issue. Using IBC as raw public key, then we might be abl= e to get ride of this issue, especially for network operators. They may jus= t care about the number of devices connected to network instead of knowing = the details of each device.=0A= =0A= > Currently we are thinking to use identity-base public key to solve the=0A= > issue. Is there any better solution to solve the identity binding=0A= > issue?=0A= =0A= If you do not want to use server-side database, create an internal CA and i= ssue as compact certificates as possible. The overhead should be in low two= hundred bytes.=0A= =0A= But this does not save you from having to figure out what those IoT devices= actually are!=0A= =0A= [HG-1] Internal CA and compact certificate can help in some scenarios, but = it will limit the authentication to a local domain. With IBC, we can keep t= he certificate compact, at same time, it can be used cross domain.=0A= =0A= > Can anyone give us some comments regarding using IBC as raw public key=0A= > for TLS for massive IoT authentication?=0A= =0A= I do not think there is any way currently to do that. The only defined sign= ature algorithms are ([*] means removed from TLS 1.3):=0A= =0A= - RSA PKCS#1 v1.5[*]=0A= - DSA[*]=0A= - ECDSA=0A= - EdDSA2 (Ed25519 and Ed448)=0A= =0A= These are also the only algorithms that can be used with raw public key aut= hentication. None of these is IBC algorithm..=0A= =0A= Also, the way the raw public keys work is the same in both TLS 1.2 and=0A= 1.3 (the precise messages are different, but it still works the same).=0A= =0A= [HG-1] Yes. With TLS-1.3, IBC algorithm is not supported at the moment. So = we hope that we can develop a separate RFC based on 1.3 and support IBC for= massive IoT usage scenarios only?=0A= RFC 6507 specifies an IBC signature method based on ECC, it is similar to = ECDSA. We can start with that first.=0A= =0A= =0A= -Ilari=0A= From nobody Sat Jul 14 08:36:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF4371310FE; Sat, 14 Jul 2018 08:35:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e5xFvUfVzH16; Sat, 14 Jul 2018 08:35:51 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7FC41310E8; Sat, 14 Jul 2018 08:35:51 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id BAC4BB80EB9; Sat, 14 Jul 2018 08:35:48 -0700 (PDT) To: eugene.adell@gmail.com, tim@dierks.org, ekr@rtfm.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: kaduk@mit.edu, iesg@ietf.org, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180714153548.BAC4BB80EB9@rfc-editor.org> Date: Sat, 14 Jul 2018 08:35:48 -0700 (PDT) Archived-At: Subject: [TLS] [Errata Rejected] RFC5246 (5409) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2018 15:36:01 -0000 The following errata report has been rejected for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5409 -------------------------------------- Status: Rejected Type: Technical Reported by: Eugene Adell Date Reported: 2018-06-26 Rejected by: Benjamin Kaduk (IESG) Section: Appendix A.5 Original Text ------------- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are reserved to avoid collision with Fortezza-based cipher suites in SSL 3. Corrected Text -------------- Note: The cipher suite values { 0x00, 0x1C } and { 0x00, 0x1D } are reserved to avoid collision with Fortezza-based cipher suites in SSL 3. The cipher suite value { 0x00, 0x1E } firstly also assigned to Fortezza has been released and has since been be reassigned. Notes ----- RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in its Draft 01 version introduces three new cipher suites colliding with the three Fortezza ones. The Draft 02 version partially corrects that, by moving the Kerberos cipher suites values by two. This omission of the third cipher suite has never been corrected, and this remains in the same state in the final RFC 2712, RFC 2246 and its successors including this one. Changing the first Kerberos cipher suite value, or moving all of them, would now not make any sense. Enhancing the note as suggested is probably enough to mention how one Fortezza cipher suite disappeared. --VERIFIER NOTES-- RFC 5246 is not the appropriate location to document this conflict. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Sat Jul 14 09:59:10 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C9AB130E8F for ; Sat, 14 Jul 2018 09:59:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7shKxGpjad_o for ; Sat, 14 Jul 2018 09:59:05 -0700 (PDT) Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1577128CF3 for ; Sat, 14 Jul 2018 09:59:05 -0700 (PDT) Received: by mail-wr1-x42a.google.com with SMTP id g6-v6so19000348wrp.0 for ; Sat, 14 Jul 2018 09:59:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZvFAHCtBHECRFIwUr0hkxWN1hkl/MAVMRvIPWsbPRYs=; b=UapEbGKJBo8jUUDhQD86RxGXm7bxztPFVvm+lsno0Z/9ujdvJhKT9jvWBABDtN73jB SZUTzY9zvtFwIw1AxfXoppQ8pVP3kz32v5v9M5VyPNtWoT0aYmu5+thOPfQB9ZdUTA/y hQMipdQXDKjtpcTtdtqAed4pqVoac11eB036nLmVHxPyJ+x2lj/ed3YQjTeA24Mqgl6U rOcpBBjEuD1oFGPIViql+khIYkbeEVDBPoPqzlmSUhVEDF1AWv/wcDH7tUJLvtjPAMZL NNl3fjvf9xE/aohWKS+xVHy+peJSJteKYfISxwKYKHC453hKpwuLj2G/9x1fOS3bb7LK 1Z5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZvFAHCtBHECRFIwUr0hkxWN1hkl/MAVMRvIPWsbPRYs=; b=QJrvPQEOoMiAtlknQuX5MzCXWTWGINAjUf5em8OFzZy+lzWs0Bw3fgOUm4RpnLSSpU MfN0Giqq8f+kjA+6nskVAJ5FWukv7YqueU4fGojyoPhc34QjfIb6Kf+g68eDghKOAnZE uAs1VbhNXb8ZViCsY2XdV0YcuRTvm8inTYSv9ZT7SSW0UHk1R+qGbAvZPdPVie9jIGFQ lzXVXMcrHj+9kaykIKa4LnbQOSNvtAlzOFouuhveP7eEdbiUvvO3X5YxulqyElLkUgfN Umj+piLiX4ZIGm8V2A6XNcMM24BOS09YEL5QRwmEeVQap5VFM/GOhjz6tQMCoWzFxwbv xxWA== X-Gm-Message-State: AOUpUlHtiyEsMEtTeCbWT/D2OwkYMQ5uQ8XqJQ1O1OWiIZ3bQW/BW2oV Hz8MV9W7O8F1BGRpq7WPYNeY09yF X-Google-Smtp-Source: AAOMgpfoU/KrZaSEsnRRVLEzWGlZuFS6qLVPCuruC7zva5xl/FsnamX0PUQ2iCpu83a/dWFHFUUUIQ== X-Received: by 2002:a5d:438d:: with SMTP id i13-v6mr8355177wrq.156.1531587543870; Sat, 14 Jul 2018 09:59:03 -0700 (PDT) Received: from [172.18.91.175] ([80.81.74.138]) by smtp.gmail.com with ESMTPSA id r68-v6sm3484499wmr.2.2018.07.14.09.59.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 14 Jul 2018 09:59:03 -0700 (PDT) To: Stephen Farrell , nalini elkins Cc: "" References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <2ad88b61-aa3c-88d4-dfef-bcd78eeeeeca@cs.tcd.ie> <91231fb5-8d5a-c825-8ac7-dd34d46db746@cs.tcd.ie> From: Yaron Sheffer Message-ID: <37850f6b-6c12-4a17-766e-437df8604377@gmail.com> Date: Sat, 14 Jul 2018 19:59:01 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <91231fb5-8d5a-c825-8ac7-dd34d46db746@cs.tcd.ie> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 14 Jul 2018 16:59:08 -0000 > >>> I'd encourage you to try get people to be open about >>> things here - there's no particular shame in having 10% TLSv1.0 >>> sessions after all:-) >> >> It isn't a question of shame but it is just a bit too much information >> to provide a potential adversary. That is, to say that Stock Exchange XYZ >> has n% of TLS1.0 clients provides a potential attacker too much >> information. > > Not sure I agree there tbh. If they're externally visible > services, then it's public already. If they're not, and the > attacker is inside the n/w, then the bad actor can find it > out then. But I do understand organisations being shy about > such things. > Having gone through this exercise recently, I agree with Nalini on why people would not want to report openly. For a typical enterprise, 10% TLS 1.0 in the internal network could well mean that 10% of your servers are Java boxes that have not been updated in the last two years (and so are riddled with vulnerabilities that are much more severe than the old TLS version). Absolutely a good reason to be ashamed :-) and certainly not information that you'd want to share openly. Thanks, Yaron From nobody Sat Jul 14 20:26:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 854A9130F05 for ; Sat, 14 Jul 2018 20:26:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ASti6zlLDcc for ; Sat, 14 Jul 2018 20:26:33 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90D1A130EB9 for ; Sat, 14 Jul 2018 20:26:33 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6F3MMPU014610; Sun, 15 Jul 2018 04:26:27 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=QFG5gK+R7c2HRtTbUOAKOrBSAl+tKIeax9TAsws/40s=; b=EBrXP49ODImROzlrbVV+SoYsFsGufi9fGcLEZZg8q3bqXO8J6HQd2u9QnQuOhxl7FnDT rkEbXyAXaRdcRU3SKcxihUQ8vJHR15WirTH0SUHNF3lEcPugxeq/gI5Q58kp6/QwY9LL m9h7LBnZ2QTvpQgiCTXV7egdumDVaWVcoDGnwEOfCXZlAwL1mQelpRnY9V5eJaB7ndQK iRmOz04hqlGXsY/+RqtYwN7K6fChR/IRYyND1pwQp5EYU3qahkiBWmlI4vqXqjn8gTdG VclDOlkjtUZy9x61Xx3u5TKJBHq6nkF8BcpnMA13DVzWZ8bOe18aYrXfflljl+rlw/Cb sw== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2k7a4y22fq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 15 Jul 2018 04:26:27 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6F3KCTr018273; Sat, 14 Jul 2018 23:26:26 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2k7cgw24e8-1; Sat, 14 Jul 2018 23:26:26 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 9B52D200DC; Sun, 15 Jul 2018 03:26:26 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1feXg1-0005zx-Sx; Sat, 14 Jul 2018 22:26:25 -0500 Date: Sat, 14 Jul 2018 22:26:25 -0500 From: Benjamin Kaduk To: Wang Haiguang Cc: "" Message-ID: <20180715032625.GQ14551@akamai.com> References: <0AE05CBFB1A6A0468C8581DAE58A31309E0B122F@SINEML521-MBX.china.huawei.com> <20180712121729.GA3925@LK-Perkele-VII> <0AE05CBFB1A6A0468C8581DAE58A31309E0B16F3@SINEML521-MBX.china.huawei.com> <0AE05CBFB1A6A0468C8581DAE58A31309E0B5E73@SINEML521-MBS.china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0AE05CBFB1A6A0468C8581DAE58A31309E0B5E73@SINEML521-MBS.china.huawei.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-14_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807150040 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-14_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807150040 Archived-At: Subject: Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 15 Jul 2018 03:26:36 -0000 On Sat, Jul 14, 2018 at 01:44:28AM +0000, Wang Haiguang wrote: > Dear ilari, > > Thanks very much for the reply :-）. Please see my comments inline below. > > -----Original Message----- > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com] > Sent: Thursday, July 12, 2018 8:17 PM > To: Wang Haiguang > Cc: > Subject: Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS > > On Thu, Jul 12, 2018 at 09:30:40AM +0000, Wang Haiguang wrote: > > Can anyone give us some comments regarding using IBC as raw public key > > for TLS for massive IoT authentication? > > I do not think there is any way currently to do that. The only defined signature algorithms are ([*] means removed from TLS 1.3): > > - RSA PKCS#1 v1.5[*] > - DSA[*] > - ECDSA > - EdDSA2 (Ed25519 and Ed448) > > These are also the only algorithms that can be used with raw public key authentication. None of these is IBC algorithm.. > > Also, the way the raw public keys work is the same in both TLS 1.2 and > 1.3 (the precise messages are different, but it still works the same). > > [HG-1] Yes. With TLS-1.3, IBC algorithm is not supported at the moment. So we hope that we can develop a separate RFC based on 1.3 and support IBC for massive IoT usage scenarios only? > RFC 6507 specifies an IBC signature method based on ECC, it is similar to ECDSA. We can start with that first. Writing an internet-draft that specifies IBC signatures for TLS 1.3 is the first step, but in principle such usage would not need to be limited to "massive IoT usage scenarios only". -Ben From nobody Mon Jul 16 04:11:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40AC6130F6C for ; Mon, 16 Jul 2018 04:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZYowZcftA3wK for ; Mon, 16 Jul 2018 04:11:30 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677FA130E2D for ; Mon, 16 Jul 2018 04:11:30 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 706C6402316D; Mon, 16 Jul 2018 11:11:29 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 67072111DD03; Mon, 16 Jul 2018 11:11:28 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 16 Jul 2018 13:11:22 +0200 Message-ID: <4405432.75Bqqshp4i@pintsize.usersys.redhat.com> In-Reply-To: <37850f6b-6c12-4a17-766e-437df8604377@gmail.com> References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> <91231fb5-8d5a-c825-8ac7-dd34d46db746@cs.tcd.ie> <37850f6b-6c12-4a17-766e-437df8604377@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart9698435.lohu3SXB6e"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Mon, 16 Jul 2018 11:11:29 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Mon, 16 Jul 2018 11:11:29 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2018 11:11:32 -0000 --nextPart9698435.lohu3SXB6e Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 14 July 2018 18:59:01 CEST Yaron Sheffer wrote: > >>> I'd encourage you to try get people to be open about > >>> things here - there's no particular shame in having 10% TLSv1.0 > >>> sessions after all:-) > >>=20 > >> It isn't a question of shame but it is just a bit too much information > >> to provide a potential adversary. That is, to say that Stock Exchange > >> XYZ > >> has n% of TLS1.0 clients provides a potential attacker too much > >> information. > >=20 > > Not sure I agree there tbh. If they're externally visible > > services, then it's public already. If they're not, and the > > attacker is inside the n/w, then the bad actor can find it > > out then. But I do understand organisations being shy about > > such things. >=20 > Having gone through this exercise recently, I agree with Nalini on why > people would not want to report openly. >=20 > For a typical enterprise, 10% TLS 1.0 in the internal network could well > mean that 10% of your servers are Java boxes that have not been updated > in the last two years (and so are riddled with vulnerabilities that are > much more severe than the old TLS version). Absolutely a good reason to > be ashamed :-) and certainly not information that you'd want to share > openly. or fully updated and supported RHEL-5 servers... that data point alone is far too little to say if the use of TLS 1.0 is=20 shameful or not =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart9698435.lohu3SXB6e Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltMfVoACgkQkqjRuAHS 9fVT1g//S8rERNaKcOIMuPv1Vtp++6fTj8F8SaW3Y8JCgVa2H2oq/TuhpGqmNwDY y6ztnIBQ0j9ef27oUcbNOwQsVKjRWtOCokpB8EP7mc2YNfvR2n+b0yv1ic4yLClu IqShogeXia2yAVhXjJTX1T5lYjV26+2/Ul+wyt3/cxL8h1betfnQz1o7YBULH7vr 20DlIZ39pRLbCll5CpFlw/1q2SvLY/3a3yedUgRYvxdkvkYVvYprQUf5jPzc5O9s w+qZsB+1D4yW1SyG6+XBiSZhHAegsm0wHRIFoHu36zduoQ6iJ/22kYEH+1W2SDVA /4hhvc0ET6Sa9MvFChfMrLTu5u959jtHtnvkw57Qb02RBzSfvWflkm1ti7BS/EzP iAdUTBA1hPZLqwHQuvddSEXntLRxnlE/We9eESInUJQ2HykD7j8zOi8N44hA+nRJ ytW5iFMpQQiW9aqll58prZL7XDore7khlLh7ls0yUiuKMuCWVmPodlxH0wv3lHtU VbSi8yleLTw8HCxp0ZPo8tpFFEvWnhkb5CMqaevOzY2fxUlxLbMs8cSOqAEN8ujz yhOPR2Sk/jdWGXfOBOXaH4UpdbHaFIrBxAdeE+7UsGnvgbgD3ICorau2VOa8OAwD rBTyHTqN6VD8Ux2LqinmS41ju/BIMTIgO/GXzL+yI14uXTE7g2Y= =TOl0 -----END PGP SIGNATURE----- --nextPart9698435.lohu3SXB6e-- From nobody Mon Jul 16 07:42:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6420F130DFF for ; Mon, 16 Jul 2018 07:42:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HgCgdJCHspnS for ; Mon, 16 Jul 2018 07:42:36 -0700 (PDT) Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::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 A3347130DC0 for ; Mon, 16 Jul 2018 07:42:36 -0700 (PDT) Received: by mail-pl0-x231.google.com with SMTP id s17-v6so5957746plp.7 for ; Mon, 16 Jul 2018 07:42:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=FJ1yuwtyQB79KubtrcnWMfYeJZlcaGwxGhNx1EapwA4=; b=hAPFHR1oomot8TwJdc+I94ah8X6I/WURyC+axl5oyvrMlWp4DhyaFzFuf+BNlv2dGu ImwIjcaP0Kl5lREZBDublvLsymJ23lRnagt55uUJAdRNqmMKEz4dbNYX1ROPLZ8BLdnk j5XRwYeoCIfDmC8LM7GS6vmakMaBThORVQ5hE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=FJ1yuwtyQB79KubtrcnWMfYeJZlcaGwxGhNx1EapwA4=; b=k6KBLwYMwygcXNizDQPXpUxqITSHUUXydc2gEJ6tpE3hoK7BGIYKTr1KkTn0AGXBpm j/M9BB01OaQdLr9INg6AWudhu2n4XEbDa21Btk3yjJJpR2FvOYwZnTlv1i/86byc2/Zk VeQ6dQl+5UjiK9B6pEAHqklkfZXVgogJeUAQIO48AEOhFsnBr5n8r6+CEQk4KDOxhmwk iN0HjzJg1RsuADmSIPlICEQIGnZo504S1xT58ik+UnUpm1R7HOHljGJTLJhmxvspv7g0 kbBelRZJzcxfUNenHzm5mtvF92RnT0C0L6jL8eJCsl/XVaygwIpbhzSwxHn2oN3/++cQ cT/Q== X-Gm-Message-State: AOUpUlHhL9uBzdrBQ0xecJ4tCirxsKXelQMPwpU+/oTOvdqWAdTTgKAZ QPk6iy779g71ogZZIZAgJWdhnfXTW7Y= X-Google-Smtp-Source: AAOMgpfDaumCGe8/8C0Ftwducru0Z+7SA435bi2y31Ucled/6Lsh9/4wLTsoMUUoWKyMUeUUoVl4sQ== X-Received: by 2002:a17:902:aa8f:: with SMTP id d15-v6mr749251plr.64.1531752156203; Mon, 16 Jul 2018 07:42:36 -0700 (PDT) Received: from ?IPv6:2001:67c:370:1998:3020:ca0c:4051:b23f? ([2001:67c:370:1998:3020:ca0c:4051:b23f]) by smtp.gmail.com with ESMTPSA id u68-v6sm49064793pfb.159.2018.07.16.07.42.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Jul 2018 07:42:35 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 16 Jul 2018 10:42:27 -0400 References: <99A6D467-EF66-464F-A26B-940D2198461E@sn3rd.com> <7B24E9CF-18D0-4264-B4CF-6FEFCECC9E81@sn3rd.com> To: TLS WG In-Reply-To: <7B24E9CF-18D0-4264-B4CF-6FEFCECC9E81@sn3rd.com> Message-Id: <7EEF5DEE-24AF-4C0D-9BDE-1EA63AEBF078@sn3rd.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] TLS@IETF102 agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2018 14:42:38 -0000 Slides for today are uploaded to: https://datatracker.ietf.org/wg/tls/meetings/ spt > On Jul 11, 2018, at 13:27, Sean Turner wrote: > > A revised agenda has been posted. > > spt > >> On Jul 10, 2018, at 12:15, Sean Turner wrote: >> >> All, >> >> The agenda has been posted: >> https://datatracker.ietf.org/meeting/102/materials/agenda-102-tls-02 >> >> Note that we have two sessions: >> >> tls Session 1 (2:00 requested) >> Monday, 16 July 2018, Afternoon Session I 1330-1530 >> Room Name: Place du Canada size: 300 >> --------------------------------------------- >> tls Session 2 (1:00 requested) >> Thursday, 19 July 2018, Afternoon Session III 1810-1910 >> Room Name: Laurier size: 250 >> --------------------------------------------- >> >> spt > From nobody Mon Jul 16 08:46:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438D0130EB0 for ; Mon, 16 Jul 2018 08:46:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RfHi-g6dtIR5 for ; Mon, 16 Jul 2018 08:46:01 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 2006D130FF1 for ; Mon, 16 Jul 2018 08:46:01 -0700 (PDT) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C201897486BB for ; Mon, 16 Jul 2018 16:45:56 +0100 (IST) Received: from SINEML701-CAH.china.huawei.com (10.223.161.51) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.399.0; Mon, 16 Jul 2018 16:45:58 +0100 Received: from SINEML521-MBX.china.huawei.com ([169.254.1.215]) by SINEML701-CAH.china.huawei.com ([169.254.245.173]) with mapi id 14.03.0382.000; Mon, 16 Jul 2018 23:45:53 +0800 From: Wang Haiguang To: "" Thread-Topic: [TLS] Regarding the identity bidding issue when using raw public key with TLS Thread-Index: AdQZwdlVj/TBP8f2Sb2VA3i7V7Seh///qsuA//438UD//Fb5wP/4rAbQ//FXLFD/4q2/gP/FWrmw/4mgufv/EhiugP4hS5IK Date: Mon, 16 Jul 2018 15:45:52 +0000 Message-ID: <0AE05CBFB1A6A0468C8581DAE58A31309E0BF8C5@SINEML521-MBX.china.huawei.com> References: <0AE05CBFB1A6A0468C8581DAE58A31309E0B122F@SINEML521-MBX.china.huawei.com> <20180712121729.GA3925@LK-Perkele-VII> <0AE05CBFB1A6A0468C8581DAE58A31309E0B16F3@SINEML521-MBX.china.huawei.com> <0AE05CBFB1A6A0468C8581DAE58A31309E0B5E73@SINEML521-MBS.china.huawei.com>, <20180715032625.GQ14551@akamai.com> In-Reply-To: <20180715032625.GQ14551@akamai.com> Accept-Language: en-SG, en-US Content-Language: en-SG X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.124.182.191] Content-Type: text/plain; charset="iso-2022-jp" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [TLS] Regarding the identity bidding issue when using raw public key with TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2018 15:46:03 -0000 Dear Benjamin,=0A= =0A= See my comments below.=0A= ________________________________________=0A= From: Benjamin Kaduk [bkaduk@akamai.com]=0A= Sent: Sunday, 15 July, 2018 11:26:25 AM=0A= To: Wang Haiguang=0A= Cc: =0A= Subject: Re: [TLS] Regarding the identity bidding issue when using raw publ= ic key with TLS=0A= =0A= On Sat, Jul 14, 2018 at 01:44:28AM +0000, Wang Haiguang wrote:=0A= > Dear ilari,=0A= >=0A= > Thanks very much for the reply :-=1B$B!K=1B(B. Please see my comments inl= ine below.=0A= >=0A= > -----Original Message-----=0A= > From: ilariliusvaara@welho.com [mailto:ilariliusvaara@welho.com]=0A= > Sent: Thursday, July 12, 2018 8:17 PM=0A= > To: Wang Haiguang =0A= > Cc: =0A= > Subject: Re: [TLS] Regarding the identity bidding issue when using raw pu= blic key with TLS=0A= >=0A= > On Thu, Jul 12, 2018 at 09:30:40AM +0000, Wang Haiguang wrote:=0A= > > Can anyone give us some comments regarding using IBC as raw public key= =0A= > > for TLS for massive IoT authentication?=0A= >=0A= > I do not think there is any way currently to do that. The only defined si= gnature algorithms are ([*] means removed from TLS 1.3):=0A= >=0A= > - RSA PKCS#1 v1.5[*]=0A= > - DSA[*]=0A= > - ECDSA=0A= > - EdDSA2 (Ed25519 and Ed448)=0A= >=0A= > These are also the only algorithms that can be used with raw public key a= uthentication. None of these is IBC algorithm..=0A= >=0A= > Also, the way the raw public keys work is the same in both TLS 1.2 and=0A= > 1.3 (the precise messages are different, but it still works the same).=0A= >=0A= > [HG-1] Yes. With TLS-1.3, IBC algorithm is not supported at the moment. S= o we hope that we can develop a separate RFC based on 1.3 and support IBC f= or massive IoT usage scenarios only?=0A= > RFC 6507 specifies an IBC signature method based on ECC, it is similar t= o ECDSA. We can start with that first.=0A= =0A= Writing an internet-draft that specifies IBC signatures for TLS 1.3 is the= =0A= first step, but in principle such usage would not need to be limited to=0A= "massive IoT usage scenarios only".=0A= =0A= [HG-2] Yes. IBC can be used for other scenarios also. We are happy to exten= d the usage scenarios also. =0A= =0A= --Haiguang=0A= From walter.neto@superlogica.com Mon Jul 16 09:09:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61371130E3B for ; Mon, 16 Jul 2018 09:09:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=superlogica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1ma28aKBtBa for ; Mon, 16 Jul 2018 09:08:58 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24C0E13109B for ; Mon, 16 Jul 2018 09:08:57 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id f18-v6so33316804qtp.10 for ; Mon, 16 Jul 2018 09:08:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=superlogica.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=/Qw2AYa6Fymfq7kBHEq9M1y22pp/UeBUMbUvq1t6M7M=; b=N/hzsv4j2r8U1Lux9fn1jL8OVcaoVmE1z2x2JFWUZRHa36+N3Br5cm4vpaylXrHaro x2Zp2lwqcwv0blWzckKEr41BFXUj00sfZs0LmTXXxbhGSna3GFjp9TkI6lXiDDjwIG/c vK1Py/Sq6MhrX+Gki9sxQU6pmZru7PpGG3l2Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=/Qw2AYa6Fymfq7kBHEq9M1y22pp/UeBUMbUvq1t6M7M=; b=ABAsgGYIGx13JNUXE8IVajX1M7kJCjIjCW/MekKr4qXyDnF2oq3woS5cMOzefzsGBL slItwlRQV9mGQ4oS9okylaZYcHVsLc0/uVQqeBhzZALX9AAooVvE0VpPI++s2h51+Spc QQDgJlgEU0d0035Y32RXwNRxkTyHiZ6yMqzdPgiNvQjbw9TVW3nWk1HG+FtHx1ZNt9Z3 qlup3O0KyNSz9lL2A7QfjhhclomwHmu+1vP9IuZ2SoypWhFENrGMVvvTe9DSQy2XJYyS Jc/GlL54djRyBTBl3jGG/k4bG9LksKiGw1/vl8o0fKdGlDNNZnbHMlg4E/fAX51J6/fA TuNQ== X-Gm-Message-State: AOUpUlGd1ZE3uoGbc765l0N5DM0riR80obZ13WvyA/Y1QP6AdIg1ZC3d 4dpklWSronsurIrZw9myDfEozAn85azMlETBBJYxF7h6SAI= X-Google-Smtp-Source: AAOMgpdFLgW6/FXmEfglvf4xoq5lZqI7PFBcOoQIcUp3lh8CPxWCbU8+QD45OOnNWaxyUmnNdeSXBDLiu0lYgl8Pp6U= X-Received: by 2002:aed:2561:: with SMTP id w30-v6mr14920035qtc.240.1531757335910; Mon, 16 Jul 2018 09:08:55 -0700 (PDT) MIME-Version: 1.0 From: Walter Neto Date: Mon, 16 Jul 2018 13:08:19 -0300 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Doubts about a solution or new service/protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2018 16:14:29 -0000 Hi IETF tls list, I have some problem to solve I believe it is good to make my questions and proposals here. I'm from Brazil, here we need to use X.509 certificates to sign electronic invoices XMLs and to communicate this XMLs through https. The problem is that the most of emitters pass their certificates (with private and public keys) to the software companies that communicate this invoices, what in my point of view it is so insecure, the other problem is that generate a certificate to the software company authorized to emmit the invoice is so bureaucratic. My proposal is to create a service that generates tokens to third applications use this service to sign, and encrypt data without the certificate, and introduce an option in the tls protocol to pass the token and the service address to use it when don't have local cert files. Does it make sense? -- Walter Neto From nobody Mon Jul 16 09:50:49 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33922130DEE for ; Mon, 16 Jul 2018 09:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILYnQuhgK27M for ; Mon, 16 Jul 2018 09:50:39 -0700 (PDT) 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 39CD4131164 for ; Mon, 16 Jul 2018 09:50:39 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id i18-v6so22704344ioj.13 for ; Mon, 16 Jul 2018 09:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sH1+c6sbW3+IAIEHhDdcEoWPZc+GuRhIbCWXePM4LEk=; b=DOe66A4GVCP6+0WAfvH4u8XwTkRnJfFKwmA1dfcTJPFbSfDSIknQzERbkdM0Twu95D GbQQ6JsMuPM1IlMlU4FBYMQ/NBbjZrHivkt2UN/UUg3TbWX7TXHEF4VxDpRhwrLfgzyU r9ekyLuI403bE4t8cQBRtpIdTw6uZCflVC0WRHLSOromPuSH/z/i2x/FEDpwoTYUr1be TK1GGLeTq0JtGFvxVT/S+3HDpOETQUAx5PWgknmNq7tbVOjerlEQf8nrsgRU5e1gD39E P+ZtOnHenuNHghi4UVX4qCbGyZ1/+IkOoQGObVRRY8R7d67iYBS1EXWYBvQTkTyJnlbh ZHqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sH1+c6sbW3+IAIEHhDdcEoWPZc+GuRhIbCWXePM4LEk=; b=JGf/9MruEs5NFeU4XR+Rdsfr+E8bJiwvDXLnTFWKcs+ilgUe5VuOiHVEQrFkBN1nC4 hXyZ9A9Zm1Dx/VmIyVhovYG5IMVX0/sa8MLyUvYuFrSt1OCbRVnqDsP+8t8P0X1qcoe6 XpqZ1GBDvEasF8YNjiOFfbiSTw97fK++iyPXMmZ40kBysibj7NU0HWxLuC+O6IVuqGbs KJ2TYcgNApmQJ9oJb7eHKtHwf/EGPwQ8CFZS33BgiEqPP65iTXPkt1EAvkA3lIHwlEj4 NVioLsKr37uywmOQHRf0kSSI2m4xThb98eKvTBS4AAaETgLHKvPtyQi2NgrCJZHe7qdC J3XA== X-Gm-Message-State: AOUpUlFY8R5u9f6Pa8vKwc7zurQgsOYrKCveI77Q/jRot/0lRh4iKZka gYLv47cjtqYcFAszll2iZrMTsPmqCkUZusPWTyUMmg== X-Google-Smtp-Source: AAOMgpf6899YTZTIKO99kvmv98jtiOlz94jfdCi2vjJfcGWepj/rZ5kG3aLCd/us/nq6MhG3mtPDOpSuigapnOU/AeQ= X-Received: by 2002:a6b:4c5:: with SMTP id 188-v6mr603545ioe.32.1531759838425; Mon, 16 Jul 2018 09:50:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Mon, 16 Jul 2018 12:50:27 -0400 Message-ID: To: Walter Neto Cc: tls@ietf.org Content-Type: multipart/alternative; boundary="0000000000000d10f6057120a1eb" Archived-At: Subject: Re: [TLS] Doubts about a solution or new service/protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2018 16:50:45 -0000 --0000000000000d10f6057120a1eb Content-Type: text/plain; charset="UTF-8" Why do you need to extend tls to do this? Why not just use it for encapsulation? What you are describing sounds more like pgp than tls. On Mon, Jul 16, 2018 at 12:15 PM Walter Neto wrote: > Hi IETF tls list, > > I have some problem to solve I believe it is good to make my questions and > proposals here. > > I'm from Brazil, here we need to use X.509 certificates to sign electronic > invoices XMLs and to communicate this XMLs through https. > > The problem is that the most of emitters pass their certificates (with > private > and public keys) to the software companies that communicate this invoices, > what > in my point of view it is so insecure, the other problem is that generate a > certificate to the software company authorized to emmit the invoice is so > bureaucratic. > > My proposal is to create a service that generates tokens to third > applications > use this service to sign, and encrypt data without the certificate, and > introduce an option in the tls protocol to pass the token and the service > address to use it when don't have local cert files. > > Does it make sense? > > -- > Walter Neto > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000000d10f6057120a1eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Why do you need to extend tls to do this?=C2=A0 Why = not just use it for encapsulation?=C2=A0 What you are describing sounds mor= e like pgp than tls.=C2=A0

<= div dir=3D"ltr">On Mon, Jul 16, 2018 at 12:15 PM Walter Neto <walter.neto@superlogica.com> wr= ote:
Hi IETF tls list,

I have some problem to solve I believe it is good to make my questions and<= br> proposals here.

I'm from Brazil, here we need to use X.509 certificates to sign electro= nic
invoices XMLs and to communicate this XMLs through https.

The problem is that the most of emitters pass their certificates (with priv= ate
and public keys) to the software companies that communicate this invoices, = what
in my point of view it is so insecure, the other problem is that generate a=
certificate to the software company authorized to emmit the invoice is so bureaucratic.

My proposal is to create a service that generates tokens to third applicati= ons
use this service to sign, and encrypt data without the certificate, and
introduce an option in the tls protocol to pass the token and the service address to use it when don't have local cert files.

Does it make sense?

--
Walter Neto

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000000d10f6057120a1eb-- From nobody Mon Jul 16 11:31:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B687C130F00 for ; Mon, 16 Jul 2018 11:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=superlogica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i7os9v03aYLm for ; Mon, 16 Jul 2018 11:31:34 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE1E613111D for ; Mon, 16 Jul 2018 11:31:33 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id a5-v6so19205119qtp.2 for ; Mon, 16 Jul 2018 11:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=superlogica.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ko5ZxDU+UYLokM0EwEqXqoW+tVsH0w7ZnHlGSBlwTUU=; b=VruizZqRv5NPMVNGayAIp2LLFkEUaIoy52u11dOJbeRF240Saky8cXXDirv/0JPBSU 5G0EaVtjXbDf1MiqSTDA5Tv29wWthsqVvC+K/nlLaP8IE265iljvODNEYZvn93FOEE1D FslhEmZ2cBk5kvQcdiTcNE19x3J8uJyc0S6lE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ko5ZxDU+UYLokM0EwEqXqoW+tVsH0w7ZnHlGSBlwTUU=; b=gJrkP1uWjFfUWDGv0mrYRFzunqWKdff9HL6/UZBkctvCd9DMpsumqpOQHklBVqw6y4 XBQiCANJ2KUUIMdKatPR4E9a6F5hrjuXD+l+fVd78vgZ5qYXX5jyw0jRdruvhViVWE+J cf4XClzmgu2+/hZ1TyMDwLXOJj08hIsqNUr/4fasASS2pZYHLbgkMxkJUgvZ22MdHZmH Ifed5Hr6lz+YmA9AQSsIDcsZSng2iwny6pkoKwdem60H/cpXnzvj4Rf5Jcs/Wx0omtYf /BCutxCh572GTlf1x5H3zkfZWHYEEvSUEle9UHBAoIsbnBcL0EXGbAMISw6kv5TbUOsN +9uQ== X-Gm-Message-State: AOUpUlFjrmDLZE3mZlnb2FiD+DosdZ22bXgToXhTCUW/0El2tcABuF5K ACCSVTCdmw6zol6KQMYLm7fwt8HVSCm39/U+NocZ5iSaUmU= X-Google-Smtp-Source: AAOMgpdTgkvn7xRv0h0gZT/IsgE14q27pZ+a6iNDTRQPVVJ5MHB+3z/gx3s13xlU6wgm0mdVp+UAjXaXl9+z3gCqVmE= X-Received: by 2002:ac8:91d:: with SMTP id t29-v6mr16183589qth.188.1531765892790; Mon, 16 Jul 2018 11:31:32 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Walter Neto Date: Mon, 16 Jul 2018 15:30:56 -0300 Message-ID: To: mellon@fugue.com Cc: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Doubts about a solution or new service/protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2018 18:31:41 -0000 Sorry Ted, I think I was not so clear. We use https (http over tls) to transmit this invoice files and I think it will be great if we have the option on the tls protocol to ask another service to encrypt things to it, without having the certificate (with private key). On Mon, Jul 16, 2018 at 1:50 PM Ted Lemon wrote: > > Why do you need to extend tls to do this? Why not just use it for encapsulation? What you are describing sounds more like pgp than tls. > > On Mon, Jul 16, 2018 at 12:15 PM Walter Neto wrote: >> >> Hi IETF tls list, >> >> I have some problem to solve I believe it is good to make my questions and >> proposals here. >> >> I'm from Brazil, here we need to use X.509 certificates to sign electronic >> invoices XMLs and to communicate this XMLs through https. >> >> The problem is that the most of emitters pass their certificates (with private >> and public keys) to the software companies that communicate this invoices, what >> in my point of view it is so insecure, the other problem is that generate a >> certificate to the software company authorized to emmit the invoice is so >> bureaucratic. >> >> My proposal is to create a service that generates tokens to third applications >> use this service to sign, and encrypt data without the certificate, and >> introduce an option in the tls protocol to pass the token and the service >> address to use it when don't have local cert files. >> >> Does it make sense? >> >> -- >> Walter Neto >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 16 12:12:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628521311B8 for ; Mon, 16 Jul 2018 12:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xc9UK4RmBKv9 for ; Mon, 16 Jul 2018 12:12:17 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCE81311DE for ; Mon, 16 Jul 2018 12:12:17 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id 13-v6so76910178ois.1 for ; Mon, 16 Jul 2018 12:12:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=gVZ753ilK+9zZlTU3tk2nCaDcBWWmvclZjJYlgmzSJ4=; b=JHYrb4HRF9W48r/6+V7lfK7LY3YJM+uZJBBCGEwZYZgCwzT7pIIR/CugpuzZJjgkoO dRsu1JldupcUNQoyDV5JUfsrggZqZ0GTFlpLmbzK83D+ACPvUqRA1IXk58zRJJeJyD7f HRIy7K+XQ+afYEtP6Ag1fZJVNZnWxGC/fOfP7zjsAIuH9IKE3/BlngzD0PHa05S/wSqb 7a0jiGF8NH3PigRi0IoX2SvwoPnaXjHrP9z1KEY26BaB5ootz/n3S4/KDmeP0bnYfnwQ nizwW2qUcG040YH2ptkrW8swMgqqIIvO1ZHFF+1OPFT60JjCoLe1Q7xFUaHYq2JMhYlo mrZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gVZ753ilK+9zZlTU3tk2nCaDcBWWmvclZjJYlgmzSJ4=; b=s/RLaM86hytSDMQbIyf5rnpo2WeQdO2Z6BRCY3xoCgNmnCpkB33KSGdK8DZ6ZSMkwg 4mnLnmB3K9V1iUVvqb76jAGltbHJY8UG6YbT/8FRVafFcXO8fDDKaGsjUtQ//vssR6H2 vN0SeBuiLQY+gv68QnXi3YJSGL9R88UhilvjfZ/zy7ffCDOsVabDAeYocJeG04Y2XvVc 6Pkbq/bA/NH6Fqb8hCWrLvdXMRiXiEQn17qM9j+Q4y3+qWMD0rmzDxKZtu/YXAPuanpm z4+xXUyloV6K9lCdHqLGbRjCceg+vlSfxfXF+naD5T2fj75JjZs0FPL3DOSUxB4k1lvo JxcQ== X-Gm-Message-State: AOUpUlEnOgPGPEHG/yTAzjbXzdeRGwr11zG+hikWYybpJo4jk8LxIcpd VnQpsATUhHeBQwF3DGRtGUZHezWj/5WIQd3Zu9cVYL/h X-Google-Smtp-Source: AAOMgpfecMcJBHZpw/HqdknyemlHwbFtGWuYwrrxX+aAxK9fH644ExbfwCZSoRxxBh8L+mr7z7D+HvtizFpvOM0G2Ak= X-Received: by 2002:aca:100f:: with SMTP id 15-v6mr683286oiq.110.1531768336277; Mon, 16 Jul 2018 12:12:16 -0700 (PDT) MIME-Version: 1.0 From: Martin Thomson Date: Mon, 16 Jul 2018 15:12:04 -0400 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Connection ID discussions in QUIC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 16 Jul 2018 19:12:28 -0000 There will be discussions in the QUIC WG this week about connection IDs, but here are some pointers: https://github.com/quicwg/base-drafts/issues/1495 https://github.com/quicwg/base-drafts/issues/1483 (might be irrelevant, but reflective of the different design choices) https://github.com/quicwg/base-drafts/issues/1468 https://github.com/quicwg/base-drafts/issues/1464 https://github.com/quicwg/base-drafts/issues/1322 One major way in which the (current) QUIC design differs from DTLS is that QUIC attaches a sequence number to each connection ID. In comparison, DTLS connection ID message says whether the connection ID is to be used immediately or if it is a spare. From nobody Tue Jul 17 05:39:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0592130E25 for ; Tue, 17 Jul 2018 05:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fEVWl-lVyVwj for ; Tue, 17 Jul 2018 05:39:35 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E825A127333 for ; Tue, 17 Jul 2018 05:39:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id B512F201CA for ; Tue, 17 Jul 2018 16:39:17 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JacstGnWY8fk for ; Tue, 17 Jul 2018 16:39:16 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 8C669200AA for ; Tue, 17 Jul 2018 16:39:16 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0399.000; Tue, 17 Jul 2018 14:39:31 +0200 From: "Bruckert, Leonie" To: "tls@ietf.org" Thread-Topic: Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pA== Date: Tue, 17 Jul 2018 12:39:31 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-guid: 4D7E4AE3-1D77-44B1-8E99-185B444FB429 Content-Type: multipart/alternative; boundary="_000_DE8E4C1F24911E469CC24DD4819274AA2770426Cmailessen01secu_" MIME-Version: 1.0 Archived-At: Subject: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 12:39:39 -0000 --_000_DE8E4C1F24911E469CC24DD4819274AA2770426Cmailessen01secu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear WG members, I am quite astonished that the brainpool curves are eventually prohibited i= n TLS 1.3. Based on an earlier comment (https://www.ietf.org/mail-archive/w= eb/tls/current/msg17204.html), I would have thought that the brainpool curv= es will be allowed in any future version, especially since they have been d= eployed successfully to date. Reading the latest draft I happened to notice that the numbers 0x001A to 0x= 001C that point to the brainpool curves are marked as obsolete_RESERVED for= the following reasons: "The obsolete curves have various known/theoretical weaknesses or have had = very little usage, in some cases only due to unintentional server configura= tion issues. They are no longer considered appropriate for general use and= should be assumed to be potentially unsafe." (See p. 127) I am not aware of any weaknesses of the brainpool curves, so I consider thi= s banishment unjustified. As I did not at all understand this decision and = furthermore, could not find any explanations in the mailing list archive, I= would like to ask how all this happened. Best regards, Leonie --_000_DE8E4C1F24911E469CC24DD4819274AA2770426Cmailessen01secu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Dear WG members,<= /span>

 

I am quite astonished that t= he brainpool curves are eventually prohibited in TLS 1.3. Based on an earli= er comment (https://www.ietf.org/mail-archive/web/tls/current/msg17204.htm= l), I would have thought that the brainpool curves will be allowed in any futu= re version, especially since they have been deployed successfully to date.<= o:p>

 

Reading the latest draft I h= appened to notice that the numbers 0x001A to 0x001C that point to the brain= pool curves are marked as obsolete_RESERVED for the following reasons:=

 

„The obsolete curves h= ave various known/theoretical weaknesses or have had very little usage, in = some cases only due to unintentional server configuration issues.  The= y are no longer considered appropriate for general use and should be assumed to be potentially unsafe.“ (See p. 127)

 

I am not aware of any weakne= sses of the brainpool curves, so I consider this banishment unjustified. As= I did not at all understand this decision and furthermore, could not find = any explanations in the mailing list archive, I would like to ask how all this happened.

 

Best regards,

 

Leonie

 

 

--_000_DE8E4C1F24911E469CC24DD4819274AA2770426Cmailessen01secu_-- From nobody Tue Jul 17 06:27:41 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCC8D130EAC for ; Tue, 17 Jul 2018 06:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cQZLqVqXNYpZ for ; Tue, 17 Jul 2018 06:27:32 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EF2130E58 for ; Tue, 17 Jul 2018 06:27:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 0B010470CA; Tue, 17 Jul 2018 16:27:20 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 8U5Q5pmVM7W0; Tue, 17 Jul 2018 16:27:19 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 6989F72; Tue, 17 Jul 2018 16:27:17 +0300 (EEST) Date: Tue, 17 Jul 2018 16:27:16 +0300 From: Ilari Liusvaara To: "Bruckert, Leonie" Cc: "tls@ietf.org" Message-ID: <20180717132716.GA12785@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 13:27:39 -0000 On Tue, Jul 17, 2018 at 12:39:31PM +0000, Bruckert, Leonie wrote: > Dear WG members, > > I am quite astonished that the brainpool curves are eventually > prohibited in TLS 1.3. Based on an earlier comment > (https://www.ietf.org/mail-archive/web/tls/current/msg17204.html), > I would have thought that the brainpool curves will be allowed in > any future version, especially since they have been deployed > successfully to date. That comment was three years ago. TLS 1.3 was quite different back then. And dropping Brainpool came later. But that discussion already touched reasons why Brainpool was dropped. > I am not aware of any weaknesses of the brainpool curves, so I > consider this banishment unjustified. As I did not at all > understand this decision and furthermore, could not find any > explanations in the mailing list archive, I would like to ask > how all this happened. Altough brainpool curves are not in any known class of weak curves (base field degree >2, l == p, or small k where l | p^k-1), and as such, finding these to be weak would be a cryptographic breakthrough (highly likely taking out lots of other curves with them): - These curves are pretty much national. - These curves are slow compared to other curves. There was also other pieces of national crypto that were dropped, like the non-AES GCM modes, even if porting these across would have been trivial, and AFAIK there is no known cryptographic trouble with those algorithms. I took look when Brainpool was finally actually dropped. It was draft-12 in March 2016 (the previous one from December 2015 still had them). At the same time, signature negotiation was revamped, which may be related, given that the revamped signature negotiation does not have room for ECDSA with Brainpool curves. -Ilari From nobody Tue Jul 17 06:56:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01FAE130F0F for ; Tue, 17 Jul 2018 06:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrea028zmWmo for ; Tue, 17 Jul 2018 06:55:55 -0700 (PDT) Received: from zucker2.schokokeks.org (zucker2.schokokeks.org [178.63.68.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA3012D7F8 for ; Tue, 17 Jul 2018 06:55:54 -0700 (PDT) Received: from computer ([2001:2012:127:3e00:ff5e:3a82:43d7:a6d6]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 17 Jul 2018 15:55:51 +0200 id 0000000000000078.000000005B4DF568.00004F48 Date: Tue, 17 Jul 2018 15:55:50 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20180717155550.1a18202e@computer> In-Reply-To: References: X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 13:55:58 -0000 Hi, I think there's been a mentality change in the TLS community that explains this. Back when Brainpool curves were standardized there was a "more is better" mentality when it came to algorithms. I.e. if an algorithm is not broken it's good to have it in TLS. Particularly all kinds of nationalized algs made it into TLS. There's a very strong reason against this: It creates complexity. More opportunities for attacks, more fragmentation of the ecosystem. I believe I speak for a lot of people here when I say that fewer algorithms is better and having more algs "just because" is not a good reason. With that in mind an algorithm doesn't have to be weak to be removed from TLS. It's reason enough if it's rarely used and doesn't have a significant advantage over alternatives. Brainpool curves were never widely used in mainstream deployments of TLS (aka browsers). They have no significant advantage over the other choices. They pretty much exist because Germany wanted to have their homegrown crypto algorithm, too, meaning they exist for nationalistic reasons, not technical ones. So deprecating them has the same reason we don't have SEED or Camellia in TLS any more. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Tue Jul 17 07:57:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2010130E58 for ; Tue, 17 Jul 2018 07:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YDRfSZo1wR2 for ; Tue, 17 Jul 2018 07:57:36 -0700 (PDT) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (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 9FD8A130F65 for ; Tue, 17 Jul 2018 07:57:36 -0700 (PDT) X-Spoof: Received: from xct104cnc.rim.net ([10.65.161.204]) by mhs214cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 17 Jul 2018 10:57:34 -0400 Received: from XCT111CNC.rim.net (10.65.161.211) by XCT104CNC.rim.net (10.65.161.204) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 17 Jul 2018 10:57:34 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT111CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Tue, 17 Jul 2018 10:57:33 -0400 From: Dan Brown To: =?iso-8859-1?Q?Hanno_B=F6ck?= , "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowA///OLCs= Date: Tue, 17 Jul 2018 14:57:30 +0000 Message-ID: <20180717145727.8642646.41749.26614@blackberry.com> References: , <20180717155550.1a18202e@computer> In-Reply-To: <20180717155550.1a18202e@computer> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 14:57:56 -0000 It's mainly due to CFRG's advice, isn't it? Calling other curves potentially unsafe or inappropriate for general use is= a bit harsh and outside the scope of TLS, isn't it? As to using a narrow or wide set of curves, there are reputable proposals f= or the latter: ia.cr/2015/647 and ia.cr/2015/366 which may be too slow for TLS, or lacking in some other practicalities, but= it is hard to conclude it is riskier or less secure. If it's not too late then an editorial softening for the reason for the set= of allowed TLS curves makes sense. Best regards, Dan Original Message From: Hanno B=F6ck Sent: Tuesday, July 17, 2018 9:56 AM To: tls@ietf.org Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Hi, I think there's been a mentality change in the TLS community that explains this. Back when Brainpool curves were standardized there was a "more is better" mentality when it came to algorithms. I.e. if an algorithm is not broken it's good to have it in TLS. Particularly all kinds of nationalized algs made it into TLS. There's a very strong reason against this: It creates complexity. More opportunities for attacks, more fragmentation of the ecosystem. I believe I speak for a lot of people here when I say that fewer algorithms is better and having more algs "just because" is not a good reason. With that in mind an algorithm doesn't have to be weak to be removed from TLS. It's reason enough if it's rarely used and doesn't have a significant advantage over alternatives. Brainpool curves were never widely used in mainstream deployments of TLS (aka browsers). They have no significant advantage over the other choices. They pretty much exist because Germany wanted to have their homegrown crypto algorithm, too, meaning they exist for nationalistic reasons, not technical ones. So deprecating them has the same reason we don't have SEED or Camellia in TLS any more. -- Hanno B=F6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Jul 17 08:02:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16476130F85 for ; Tue, 17 Jul 2018 08:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nm5D93VaK34v for ; Tue, 17 Jul 2018 08:02:27 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4600F130E58 for ; Tue, 17 Jul 2018 08:02:27 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id u202-v6so1081242lff.9 for ; Tue, 17 Jul 2018 08:02:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HVkJcsKYD5q28Dnu+NHL3TbpFBenUW2ckPbzyuqlYyo=; b=0HA4USi8PUcq7pNdJo7uUChja3q4RbFKYHGp7xx4OXfFdnWAiMTbi384ty8ebxkx16 1iE0DfptM5mxwkFX2uqTJ+kcxhbwGtJXfoZ6Zt9PO4MfFSk6ePOiWnftBuS29vEjcDbs uoldM1v8MI7tgo33ISHjJeS2tVS/xXRi0sPsQFar7qBrcmR1JOL1agR+WosBGkYyDrr+ n2rVw2ZcyjhkA+bo7O7l5HLQaOXOHf/B8v/GkdtBGI/eFhqyjRbQgM6peefbYoSdLz5/ HMDQU3d+v6BttsQ0P+CHjGQE1CnDlwxKjNwD8BcY2bNBVtB/7y+t9eJoFj0YjQuEci0T cJng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HVkJcsKYD5q28Dnu+NHL3TbpFBenUW2ckPbzyuqlYyo=; b=Pp6akDzzlS7i1CK5bRJ/SgfkxSo2cCZBKPovLSa7tsrcJzGQa+fzC87S4YRvssWVuK pJvfmiA7Fcpgiv2vYjICGrCKZkyK8v8rvEnaRpOFyj0EMcc3ZJiS1foQJN34jOxzEqy6 qZaCacv4pE0oevHJzuPK6IIV6VDJmxEF1DML5eLBGxeWUGh5AtmwGUBA7mdvjp+Q17Mv LpLRChCcXvE7gYPE+lSjy3Ksh/FXOQbN3mGtAMlIZsc4Wcn+KUC8gPe8ov9dW1g6nCNr swb3YIcY0gm6NRrFejly0AKDN3l/Wz4C/neNpJDWphlNZkOg3sgQi4R6/2GXtTF6SMGN SONA== X-Gm-Message-State: AOUpUlHRaqrRMiLxXrsOBHrygyhMyqkz6b1TJCUpVlcyaNmTSonPFxH3 MXQu0c0RGdkUsgmlbgEGs8ioUGRaEM6wvsyYY6FJp7MhzSs= X-Google-Smtp-Source: AAOMgpc0uZpA7uKd4MS51yXu9Nc9Q+wmthnPqTCj7LJcxn94F9M6mo8IgYSoAnLjBD6b2NXofDcu9jbBwDfFF4THd0c= X-Received: by 2002:a19:7403:: with SMTP id v3-v6mr1492316lfe.97.1531839745569; Tue, 17 Jul 2018 08:02:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 08:01:44 -0700 (PDT) In-Reply-To: <20180717145727.8642646.41749.26614@blackberry.com> References: <20180717155550.1a18202e@computer> <20180717145727.8642646.41749.26614@blackberry.com> From: Eric Rescorla Date: Tue, 17 Jul 2018 08:01:44 -0700 Message-ID: To: Dan Brown Cc: =?UTF-8?Q?Hanno_B=C3=B6ck?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e34ca30571333b74" Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 15:02:44 -0000 --000000000000e34ca30571333b74 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well, I note that the text also says "or have had very little usage," -Ekr On Tue, Jul 17, 2018 at 7:57 AM, Dan Brown wrote= : > It's mainly due to CFRG's advice, isn't it? > Calling other curves potentially unsafe or inappropriate for general use > is a bit harsh and outside the scope of TLS, isn't it? > As to using a narrow or wide set of curves, there are reputable proposals > for the latter: > > ia.cr/2015/647 and ia.cr/2015/366 > > which may be too slow for TLS, or lacking in some other practicalities, > but it is hard to conclude it is riskier or less secure. > > If it's not too late then an editorial softening for the reason for the > set of allowed TLS curves makes sense. > > Best regards, > > Dan > > > Original Message > From: Hanno B=C3=B6ck > Sent: Tuesday, July 17, 2018 9:56 AM > To: tls@ietf.org > Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? > > > Hi, > > I think there's been a mentality change in the TLS community that > explains this. > Back when Brainpool curves were standardized there was a "more is > better" mentality when it came to algorithms. I.e. if an algorithm is > not broken it's good to have it in TLS. Particularly all kinds of > nationalized algs made it into TLS. > > There's a very strong reason against this: It creates complexity. More > opportunities for attacks, more fragmentation of the ecosystem. I > believe I speak for a lot of people here when I say that fewer > algorithms is better and having more algs "just because" is not a good > reason. With that in mind an algorithm doesn't have to be weak to be > removed from TLS. It's reason enough if it's rarely used and doesn't > have a significant advantage over alternatives. > > Brainpool curves were never widely used in mainstream deployments of TLS > (aka browsers). They have no significant advantage over the other > choices. They pretty much exist because Germany wanted to have their > homegrown crypto algorithm, too, meaning they exist for nationalistic > reasons, not technical ones. So deprecating them has the same reason we > don't have SEED or Camellia in TLS any more. > > -- > Hanno B=C3=B6ck > https://hboeck.de/ > > mail/jabber: hanno@hboeck.de > GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 > > _______________________________________________ > 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 > --000000000000e34ca30571333b74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Well, I note that the text also says "or have ha= d very little usage,"

-Ekr


On Tue, J= ul 17, 2018 at 7:57 AM, Dan Brown <danibrown@blackberry.com>= wrote:
It's mainly due to CFR= G's advice, isn't it?
Calling other curves potentially unsafe or inappropriate for general use is= a bit harsh and outside the scope of TLS, isn't it?
As to using a narrow or wide set of curves, there are reputable proposals f= or the latter:

ia.c= r/2015/647 and ia.cr/2015/366

which may be too slow for TLS, or lacking in some other practicalities, but= it is hard to conclude it is riskier or less secure.

If it's not too late then an editorial softening for the reason for the= set of allowed TLS curves makes sense.

Best regards,

Dan


=C2=A0 Original Message
From: Hanno B=C3=B6ck
Sent: Tuesday, July 17, 2018 9:56 AM
To: tls@ietf.org
Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3?


Hi,

I think there's been a mentality change in the TLS community that
explains this.
Back when Brainpool curves were standardized there was a "more is
better" mentality when it came to algorithms. I.e. if an algorithm is<= br> not broken it's good to have it in TLS. Particularly all kinds of
nationalized algs made it into TLS.

There's a very strong reason against this: It creates complexity. More<= br> opportunities for attacks, more fragmentation of the ecosystem. I
believe I speak for a lot of people here when I say that fewer
algorithms is better and having more algs "just because" is not a= good
reason. With that in mind an algorithm doesn't have to be weak to be removed from TLS. It's reason enough if it's rarely used and doesn&= #39;t
have a significant advantage over alternatives.

Brainpool curves were never widely used in mainstream deployments of TLS (aka browsers). They have no significant advantage over the other
choices. They pretty much exist because Germany wanted to have their
homegrown crypto algorithm, too, meaning they exist for nationalistic
reasons, not technical ones. So deprecating them has the same reason we
don't have SEED or Camellia in TLS any more.

--
Hanno B=C3=B6ck
https:/= /hboeck.de/

mail/jabber: hanno@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

_______________________________________________
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

--000000000000e34ca30571333b74-- From nobody Tue Jul 17 08:04:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F7B2130E58 for ; Tue, 17 Jul 2018 08:04:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0BGVm_eolt2q for ; Tue, 17 Jul 2018 08:04:25 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C62EA130DFE for ; Tue, 17 Jul 2018 08:04:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 43F62200AA; Tue, 17 Jul 2018 19:04:09 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3expFOAhscqZ; Tue, 17 Jul 2018 19:04:08 +0200 (CEST) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id E7DF4200A0; Tue, 17 Jul 2018 19:04:08 +0200 (CEST) Received: from [10.208.1.212] (10.208.1.212) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 17 Jul 2018 17:04:23 +0200 To: =?UTF-8?Q?Hanno_B=c3=b6ck?= , References: <20180717155550.1a18202e@computer> From: Johannes Merkle Openpgp: preference=signencrypt Message-ID: <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> Date: Tue, 17 Jul 2018 17:04:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20180717155550.1a18202e@computer> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-G-Data-MailSecurity-for-Exchange-State: 0 X-G-Data-MailSecurity-for-Exchange-Error: 0 X-G-Data-MailSecurity-for-Exchange-Sender: 23 X-G-Data-MailSecurity-for-Exchange-Server: d65e63f7-5c15-413f-8f63-c0d707471c93 X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 X-G-Data-MailSecurity-for-Exchange-Guid: A62A4E5E-CF42-4927-B52A-94E27907E517 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 15:04:28 -0000 Hi, > There's a very strong reason against this: It creates complexity. More > opportunities for attacks, more fragmentation of the ecosystem. I > believe I speak for a lot of people here when I say that fewer > algorithms is better and having more algs "just because" is not a good > reason. With that in mind an algorithm doesn't have to be weak to be > removed from TLS. It's reason enough if it's rarely used and doesn't > have a significant advantage over alternatives. Crypto agility definitely has its value. There are not so many curves supported by TLS 1.3, and all of them use primes of a very special form. Of course, this is exactly what makes these curves faster than the Brainpool curves, but from a security perspective it might be advisable to have alternatives at hand which have very different properties (and have not been generated by the NSA using seeds of obscure origin). In particular, as the code points had already been registered and have already been implemented in some products. Furthermore, the reasoning in the draft that these curves "should be assumed to be potentially unsafe" is completely wrong. Johannes From nobody Tue Jul 17 08:37:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3536E130F16 for ; Tue, 17 Jul 2018 08:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o7PHVa84iVnN for ; Tue, 17 Jul 2018 08:37:29 -0700 (PDT) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE88E130DFF for ; Tue, 17 Jul 2018 08:37:28 -0700 (PDT) Received: by mail-vk0-x22e.google.com with SMTP id j11-v6so810542vke.8 for ; Tue, 17 Jul 2018 08:37:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IpEL6s4mZGc6XiYNsrGCIyQcv8dtw3F+naXTJ3WWIb8=; b=Jqj/n25LApU9CV27rdjU9odEN5bf6JjP1IpDUDogI5O7NLtL1IJObHl/aZcDg99w+b ng8q7jiwZMbabnN9bYjSn+ixVOfoa+++q8uWpkXUzPhYSJ4Ibr/jTUjcXtkI3oQNijWp UbcJTBLYxWCN+PgUdDc8BWzgJ+i66WO2r7xfCgTxYisbWPyiqxWPAt1+Q7XI5Adkxp8K sDp74ezKah1VZiyJIYV4H6kpk3MkUs2SidAOZr60FWrFq8zp26VqSGcsAxk2Tec5nGcR /IXn7wH1b/DtEWRn4F9PTBXetpJc4BUrntKJ3ItdlPNx9IW8EzGZZebDm4crQ8iTGq6k 9oNw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IpEL6s4mZGc6XiYNsrGCIyQcv8dtw3F+naXTJ3WWIb8=; b=Wnv62RWEcU+wtW8mIA8KOp0JPnT0OpggRSJwQxva6f1XyCFxC2MYC18iLhHeeMYSdo nlb30HmkJEBUDuricZTlj88z7tdKLcuJ2JcsFM2v7BkUnMMMpJfMfpjlKUN69+VleVcT WzOHhRDVv4qal9s6MycBEGP5lXzAhH9Lfm2Ye3i4S7X/6UCP8yUgiho26h/Pz3yyY3zY MEchzUf73xQol7hMBy/n4mn2cOjHzQtfq0sj5sdbimxaZGv89amGt7MMu9w0v5h4OBfv 8jY7KDXs6IJOjvrkEDfDcRPC4kiCSszlBZsj458IDYsDM6pAOVnVLr9KnUEV2qALqSaJ M2hw== X-Gm-Message-State: AOUpUlFTCloAPwik+xJCgytBInj3ZAnfp62zeIDSzLAXWhsWpcK3X4C9 /BWmMgUINh4AD9ES/+3BuP/AHq7rs/p0dQCBulyQ7Mu6 X-Google-Smtp-Source: AAOMgpdJQ8YXd91Hg4B3ttFj0NPgITtZ3DwaQn3WMNARnfVLEeQHhlHBUBcatNR78AYC4fcgJ6dh9xoJSfZVrhqKwdE= X-Received: by 2002:a1f:ebc7:: with SMTP id j190-v6mr1177684vkh.114.1531841847857; Tue, 17 Jul 2018 08:37:27 -0700 (PDT) MIME-Version: 1.0 References: <20180717155550.1a18202e@computer> <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> In-Reply-To: <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> From: Tony Arcieri Date: Tue, 17 Jul 2018 08:37:16 -0700 Message-ID: To: Johannes Merkle Cc: =?UTF-8?Q?Hanno_B=C3=B6ck?= , "" Content-Type: multipart/alternative; boundary="0000000000003196f7057133b96d" Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 15:37:46 -0000 --0000000000003196f7057133b96d Content-Type: text/plain; charset="UTF-8" On Tue, Jul 17, 2018 at 8:04 AM Johannes Merkle wrote: > Crypto agility definitely has its value. There are not so many curves > supported by TLS 1.3, and all of them use primes > of a very special form. Of course, this is exactly what makes these curves > faster than the Brainpool curves, but from a > security perspective it might be advisable to have alternatives at hand > which have very different properties Between the NIST curves and Curve25519/Ed448 we have this already. > (and have not been generated by the NSA using seeds of obscure origin). > We've been through this before, e.g.: https://www.ietf.org/mail-archive/web/tls/current/msg10271.html https://bada55.cr.yp.to/brainpool.html ...the latter of which quotes you as saying the repeated digits in the "A" and "B" values used in Brainpool seed generation process were "unfortunate". There are no compelling practical reasons to continue to support the Brainpool curves. They are both redundant and obscure. -- Tony Arcieri --0000000000003196f7057133b96d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 17= , 2018 at 8:04 AM Johannes Merkle <johannes.merkle@secunet.com> wrote:
Crypto agility definitely has its valu= e. There are not so many curves supported by TLS 1.3, and all of them use p= rimes
of a very special form. Of course, this is exactly what makes these curves = faster than the Brainpool curves, but from a
security perspective it might be advisable to have alternatives at hand whi= ch have very different properties

Between t= he NIST curves and Curve25519/Ed448 we have this already.
=C2=A0<= /div>
(and have not been = generated by the NSA using seeds of obscure origin).
<= br>
We've been through this before, e.g.:

...the latt= er of which quotes you as saying the repeated digits in the "A" a= nd "B" values used in Brainpool seed generation process were &quo= t;unfortunate".

There are no compelling pract= ical reasons to continue to support the Brainpool curves. They are both red= undant and obscure.

--
Tony Arcieri
--0000000000003196f7057133b96d-- From nobody Tue Jul 17 08:48:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32095130F3F for ; Tue, 17 Jul 2018 08:48:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3cjQFKAKpASW for ; Tue, 17 Jul 2018 08:48:31 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21A7F130F66 for ; Tue, 17 Jul 2018 08:48:31 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id g6-v6so1188475lfb.11 for ; Tue, 17 Jul 2018 08:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=q4UDfZteJ9Cdzn1cxXpRZ/GJrZB7L5sI6aOo5rrcKkk=; b=U36gWfItesfYKsJ1SrmoDGOtEO30Sar/cbSVQyRbKGe22FPEIKXRO0Fp9Zjck5mvs0 nIO73Hplf7DvZyvkSLeCT2RGm7LwXZ0N1yiGYSN2viVq/codH5Az/NFHE+2MQmT8mREx mHZGvdSAQgi5WLKjEg2HwPOjxC61LOW8+uZThzBW2+FUYmzAvboqs4ylKmoPng47Zo8n 1Wd5Cm2zMonh7cdIzdsLlqH8FQaW96JxIsmPsfgtAMGaI2J4ktAn2Awa1mZnwv0GL+2/ wr2t6V3YzA6T1/tQpNnW+AbnyafKYVKO/sfbrHjSU/1sm1NyjF1b0RklLW24lHhiNR5O 3xiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=q4UDfZteJ9Cdzn1cxXpRZ/GJrZB7L5sI6aOo5rrcKkk=; b=ahcC9EiJvzMDWC0WvC84BLutsSk31LeN3GWaJC9XeOKuZ94A6Y2eY+L0BNohhwoJyC SXLVuEieyQ1pEsUthW6JhxqTzMqt0DyW00vz4Ni8VlM76i0bK0IhR+e6Q99nUcCobEWv UG/P++14BD+K/D/UsFTIe8smDb0yMOIZloRKGljC8jTddYQ7dByQRqSSL1iFPefk68hi gsSc3QAJ0YqP1U0Hu4p3K4VmmDd5vNx8zpBycIY4wSzRdQwpMfudgHp1nIm44t3mdeel Yg0M6bzPJCJkHnBlvgv4/wCmp4/CUkoo8Hyt4OASuRWWTMS3tcMJs1Cdm3ypdkQOCSJP eSfA== X-Gm-Message-State: AOUpUlEN0gQp9IznFTcd9s4qECQgNIYgNs1gwRyov2uFLVgBnpmG4RPG 79TXUZPetLG63vH1DdvcnccVRMJrVKn7xU/sDTY8hg== X-Google-Smtp-Source: AAOMgpciDIRXHGAzHp+cBunArTTtt5MojBJsgYrjdwNFCTR1e1zWRRgdUBZPI8e+AQ1/ENYvENgU6V/Pp8ZhuLZTVzI= X-Received: by 2002:a19:a417:: with SMTP id q23-v6mr1587346lfc.59.1531842509375; Tue, 17 Jul 2018 08:48:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 08:47:48 -0700 (PDT) In-Reply-To: <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> References: <20180717155550.1a18202e@computer> <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> From: Eric Rescorla Date: Tue, 17 Jul 2018 08:47:48 -0700 Message-ID: To: Johannes Merkle Cc: =?UTF-8?Q?Hanno_B=C3=B6ck?= , "" Content-Type: multipart/alternative; boundary="0000000000009f9d43057133e0c7" Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 15:48:47 -0000 --0000000000009f9d43057133e0c7 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 17, 2018 at 8:04 AM, Johannes Merkle < johannes.merkle@secunet.com> wrote: > Hi, > > > There's a very strong reason against this: It creates complexity. More > > opportunities for attacks, more fragmentation of the ecosystem. I > > believe I speak for a lot of people here when I say that fewer > > algorithms is better and having more algs "just because" is not a good > > reason. With that in mind an algorithm doesn't have to be weak to be > > removed from TLS. It's reason enough if it's rarely used and doesn't > > have a significant advantage over alternatives. > > Crypto agility definitely has its value. There are not so many curves > supported by TLS 1.3, and all of them use primes > of a very special form. Of course, this is exactly what makes these curves > faster than the Brainpool curves, but from a > security perspective it might be advisable to have alternatives at hand > which have very different properties (and have > not been generated by the NSA using seeds of obscure origin). In > particular, as the code points had already been > registered and have already been implemented in some products. > Well, I think the question here centers on what "at hand" means. We've generally decided to limit the number of algorithms we recommend (the Recommended) column in the registry. I have trouble seeing any situation in which we would have these curves as Recommended. And so "at hand" really means (1) code points assigned and (2) some small number of people who don't follow our Recommended advice do them. I have trouble seeing, for instance, many Web implementations having these curves. If we think that we need a backup set of curves with yet different properties from the CFRG curves and the NIST curves, then we should ask CFRG to produce such curves, which we would then feel good about marking "Recommended" -Ekr Furthermore, the reasoning in the draft that these curves "should be > assumed to be potentially unsafe" is completely wrong. > > Johannes > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000009f9d43057133e0c7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 17, 2018 at 8:04 AM, Johannes Merkle <= johannes.m= erkle@secunet.com> wrote:
H= i,

> There's a very strong reason against this: It creates complexity. = More
> opportunities for attacks, more fragmentation of the ecosystem. I
> believe I speak for a lot of people here when I say that fewer
> algorithms is better and having more algs "just because" is = not a good
> reason. With that in mind an algorithm doesn't have to be weak to = be
> removed from TLS. It's reason enough if it's rarely used and d= oesn't
> have a significant advantage over alternatives.

Crypto agility definitely has its value. There are not so many curve= s supported by TLS 1.3, and all of them use primes
of a very special form. Of course, this is exactly what makes these curves = faster than the Brainpool curves, but from a
security perspective it might be advisable to have alternatives at hand whi= ch have very different properties (and have
not been generated by the NSA using seeds of obscure origin). In particular= , as the code points had already been
registered and have already been implemented in some products.
=C2=A0
Well, I think the question here centers on wh= at "at hand" means. We've generally decided to limit the numb= er of algorithms we recommend (the Recommended) column in the registry. I h= ave trouble seeing any situation in which we would have these curves as Rec= ommended. And so "at hand" really means (1) code points assigned = and (2) some small number of people who don't follow our Recommended ad= vice do them. I have trouble seeing, for instance, many Web implementations= having these curves.

If we think that we need a b= ackup set of curves with yet different properties from the CFRG curves and = the NIST curves, then we should ask CFRG to produce such curves, which we w= ould then feel good about marking "Recommended"
-Ekr


Furthermore, the reasoning in the draft that these curves "should be a= ssumed to be potentially unsafe" is completely wrong.

Johannes

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

--0000000000009f9d43057133e0c7-- From nobody Tue Jul 17 09:42:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24C05130DCF for ; Tue, 17 Jul 2018 09:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VT3aB7hYV6VX for ; Tue, 17 Jul 2018 09:42:21 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0809130E27 for ; Tue, 17 Jul 2018 09:42:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 098BC200BD; Tue, 17 Jul 2018 20:42:02 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUG3VYr7moz9; Tue, 17 Jul 2018 20:41:58 +0200 (CEST) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 7D80E200A0; Tue, 17 Jul 2018 20:41:58 +0200 (CEST) Received: from [10.208.1.212] (10.208.1.212) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 17 Jul 2018 18:42:13 +0200 To: Tony Arcieri CC: "" References: <20180717155550.1a18202e@computer> <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> From: Johannes Merkle Openpgp: preference=signencrypt Message-ID: <7ac9ad00-2fd1-ad01-a3d6-75d2838fc206@secunet.com> Date: Tue, 17 Jul 2018 18:42:12 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: de-DE Content-Transfer-Encoding: 7bit X-G-Data-MailSecurity-for-Exchange-State: 0 X-G-Data-MailSecurity-for-Exchange-Error: 0 X-G-Data-MailSecurity-for-Exchange-Sender: 23 X-G-Data-MailSecurity-for-Exchange-Server: d65e63f7-5c15-413f-8f63-c0d707471c93 X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 X-G-Data-MailSecurity-for-Exchange-Guid: F61FD048-DF38-4F73-934C-56E2A4822D82 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 16:42:25 -0000 > We've been through this before, e.g.: > > https://www.ietf.org/mail-archive/web/tls/current/msg10271.html > https://bada55.cr.yp.to/brainpool.html > > ...the latter of which quotes you as saying the repeated digits in the "A" > and "B" values used in Brainpool seed generation process were "unfortunate". > I am so tired of this polemic discussion. Everything that need to be said in response can be found here: https://www.ietf.org/mail-archive/web/cfrg/current/msg05353.html Give it a read. Johannes From nobody Tue Jul 17 09:45:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 256E9130EB0 for ; Tue, 17 Jul 2018 09:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZzLehFIrAeM for ; Tue, 17 Jul 2018 09:45:42 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E903130DCF for ; Tue, 17 Jul 2018 09:45:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 2BB66201AA; Tue, 17 Jul 2018 20:45:26 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBJ6KMGrvhCC; Tue, 17 Jul 2018 20:45:25 +0200 (CEST) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id D1A35200A0; Tue, 17 Jul 2018 20:45:25 +0200 (CEST) Received: from [10.208.1.212] (10.208.1.212) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.399.0; Tue, 17 Jul 2018 18:45:40 +0200 To: Eric Rescorla CC: "" References: <20180717155550.1a18202e@computer> <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> From: Johannes Merkle Openpgp: preference=signencrypt Message-ID: Date: Tue, 17 Jul 2018 18:45:40 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Language: de-DE Content-Transfer-Encoding: 7bit X-G-Data-MailSecurity-for-Exchange-State: 0 X-G-Data-MailSecurity-for-Exchange-Error: 0 X-G-Data-MailSecurity-for-Exchange-Sender: 23 X-G-Data-MailSecurity-for-Exchange-Server: d65e63f7-5c15-413f-8f63-c0d707471c93 X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 X-G-Data-MailSecurity-for-Exchange-Guid: DA04619B-7F84-40DE-9A65-333833F38173 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 16:45:44 -0000 Eric Rescorla schrieb am 17.07.2018 um 17:47: > We've > generally decided to limit the number of algorithms we recommend (the > Recommended) column in the registry. I have trouble seeing any situation in > which we would have these curves as Recommended. And so "at hand" really > means (1) code points assigned and (2) some small number of people who > don't follow our Recommended advice do them But the draft states Values within "obsolete_RESERVED" ranges are used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 So its not merely a recommendation. Johannes From nobody Tue Jul 17 10:24:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED7F130F4C for ; Tue, 17 Jul 2018 10:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R_CLg9GpzJ6B for ; Tue, 17 Jul 2018 10:24:22 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::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 CE64F130EC9 for ; Tue, 17 Jul 2018 10:24:21 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id q127-v6so1662963ljq.11 for ; Tue, 17 Jul 2018 10:24:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=i4ocVF3ZTt3sLrzkv8Vbkq+sOPAIEGYzo52enTdsd9k=; b=QGKfcxDspi3mv8+ZuXaZLTg3sSW1KpxqGtl2tRlsZBfHnUg5bEc8drSk3w57VjPoKq XAAsT3M4xNlL65RsRuB8CJ7KI7Z8n+NUSVoBabO0QbHZT04GVSOw4l6nROMIBeJ8ziB+ 7rKvjHS/PWvKX2X9zu2QX8/LWJfqS7yEwt9Da0AR9T8yWfdB3pPl6jJMkAOgaEWhK95q LBAQV5o7lhXLmZWMqB3aaHPW9LP7Byi1AZHvN4dF4kT0VKO+J7uiBoapnCwqNMnkSa3m Uv3iuOYqFd8OUJZpTVRQp9pAKDvmFUeHKXwMRoI68xXWgQw3NHKJVWvvrVQHmmex5p0d dPZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=i4ocVF3ZTt3sLrzkv8Vbkq+sOPAIEGYzo52enTdsd9k=; b=Z7wAk9PdCCYHiM9LzwYuTwqmpowCNZ1NFL8qXNONhO3yG3QTsUE4qlOBuuTh1AxbHt t//5HCTbWeIzT0aFCSfr+lcaav2nguNMqeZMNugm5yDnZuN7Gup73/f6BC+dl6Z7YGCQ WAVbBjkrZ6OCg/eNlRGDn+hiuv48YwbTxSdJZYAIUhi9HCiD8hzLn0/MwKSW+3vV2AOq Mr3kyfTPn7ZBSU44B+3AW5mxqdYiC9+FgitX140fmIX84lXL3nvV7VQakJ0jc4bGId7m 1zLWIohnN+neP7FtFvlqH/f9qHqLnTcG5xa65Ugs4rgYjCZp72BSBky+H6dcPBTRQx8T nkuQ== X-Gm-Message-State: AOUpUlFpER7M54sv2kMG6A/n3xFJHuT7eFJqaunuOJg5+P9GQ0PPWd/6 GNv7lmmT10Q9ysgRAvUA0jwUynPnR0oVQsauQdLNuGZr X-Google-Smtp-Source: AAOMgpd+kbJPMqDfh+CPjt7t4dKTX89+26MilYA9w/IIIq1+j47Tm5oZPPV/dH6hS1GC6WqlfBIVvRNf2/Sb56mPp6k= X-Received: by 2002:a2e:954e:: with SMTP id t14-v6mr2072421ljh.68.1531848260115; Tue, 17 Jul 2018 10:24:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 10:23:39 -0700 (PDT) In-Reply-To: References: <20180717155550.1a18202e@computer> <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> From: Eric Rescorla Date: Tue, 17 Jul 2018 10:23:39 -0700 Message-ID: To: Johannes Merkle Cc: "" Content-Type: multipart/alternative; boundary="00000000000064f5a505713537c8" Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 17:24:24 -0000 --00000000000064f5a505713537c8 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 17, 2018 at 9:45 AM, Johannes Merkle < johannes.merkle@secunet.com> wrote: > Eric Rescorla schrieb am 17.07.2018 um 17:47: > > We've > > generally decided to limit the number of algorithms we recommend (the > > Recommended) column in the registry. I have trouble seeing any situation > in > > which we would have these curves as Recommended. And so "at hand" really > > means (1) code points assigned and (2) some small number of people who > > don't follow our Recommended advice do them > > But the draft states > Values within "obsolete_RESERVED" ranges are used in previous > versions of TLS and MUST NOT be offered or negotiated by TLS 1.3 > > So its not merely a recommendation. > Yes, what I am saying is that even if we were to remove that text it would not significantly change matters. -Ekr > Johannes > --00000000000064f5a505713537c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 17, 2018 at 9:45 AM, Johannes Merkle <= johannes.m= erkle@secunet.com> wrote:
<= span class=3D"">Eric Rescorla schrieb am 17.07.2018 um 17:47:
> We've
> generally decided to limit the number of algorithms we recommend (the<= br> > Recommended) column in the registry. I have trouble seeing any situati= on in
> which we would have these curves as Recommended. And so "at hand&= quot; really
> means (1) code points assigned and (2) some small number of people who=
> don't follow our Recommended advice do them

But the draft states
=C2=A0 =C2=A0Values within "obsolete_RESERVED" ranges are used in= previous
=C2=A0 =C2=A0versions of TLS and MUST NOT be offered or negotiated by TLS 1= .3

So its not merely a recommendation.

Yes= , what I am saying is that even if we were to remove that text it would not= significantly change matters.

-Ekr
=

Johannes

--00000000000064f5a505713537c8-- From nobody Tue Jul 17 10:28:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC8D4130EC9 for ; Tue, 17 Jul 2018 10:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmcFvGSCbrns for ; Tue, 17 Jul 2018 10:28:47 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 6844A130EDA for ; Tue, 17 Jul 2018 10:28:46 -0700 (PDT) Received: from LLE2K16-MBX01.mitll.ad.local (LLE2K16-MBX01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w6HHSjA7032764; Tue, 17 Jul 2018 13:28:45 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Eric Rescorla , Johannes Merkle CC: "" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowAAAJk44AAAYQtAAACBV4AAAFTmYD//76KAA== Date: Tue, 17 Jul 2018 17:28:44 +0000 Message-ID: <6B005B2A-148F-4459-B7B5-E4ECC063EBC3@ll.mit.edu> References: <20180717155550.1a18202e@computer> <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3614678962_2182951530" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-17_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=980 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807170182 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 17:28:51 -0000 --B_3614678962_2182951530 Content-type: multipart/alternative; boundary="B_3614678962_368090303" --B_3614678962_368090303 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable > We've > generally decided to limit the number of algorithms we recommend (the > Recommended) column in the registry. I have trouble seeing any situation = in > which we would have these curves as Recommended. And so "at hand" really > means (1) code points assigned and (2) some small number of people who > don't follow our Recommended advice do them But the draft states Values within "obsolete_RESERVED" ranges are used in previous versions of TLS and MUST NOT be offered or negotiated by TLS 1..3 So its not merely a recommendation. =20 Yes, what I am saying is that even if we were to remove that text it would = not significantly change matters. =20 I think =E2=80=9CMUST NOT=E2=80=9D is way too strong in this context, and =E2=80=9Cmust=E2=80=9D be= softened. --B_3614678962_368090303 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

> We've
> gen= erally decided to limit the number of algorithms we recommend (the
> R= ecommended) column in the registry. I have trouble seeing any situation in> which we would have these curves as Recommended. And so "at hand= " really
> means (1) code points assigned and (2) some small numb= er of people who
> don't follow our Recommended advice do them

= But the draft states
   Values within "obsolete_RESERVED&q= uot; ranges are used in previous
   versions of TLS and MUST NO= T be offered or negotiated by TLS 1..3

So its not merely a recommenda= tion.

 

Y= es, what I am saying is that even if we were to remove that text it would no= t significantly change matters.

=  

I think =E2=80=9CMUST NOT=E2=80=9D is way too strong = in this context, and =E2=80=9Cmust=E2=80=9D be softened.

--B_3614678962_368090303-- --B_3614678962_2182951530 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgOk5gTHaSuWjNIYBk GJ5d2ShyzjL0VM9v5ZP+7+9xIwAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTgwNzE3MTcyOTIyWjANBgkqhkiG9w0BAQEFAASCAQBAktwZUS31kT0uNyeX fx0J22MVB45z05+9z3+QyTByLxNTd92eddqyOQsucshWR6pEJcgWxWvlxrOE0Pn7iX27v4tv /6eNwKeWEtWZFmb/6Ljc7yu6/fpoTwApyMpnO0EtUawjzEnYQeZLqcqPZ3xdLHkzgZErXZZH V0Wh9gFuGh0hqESPcE2hn7PMi4xUmV3Adnd3Y5yfVG9SA/LvGd6T8jYW6T4H2mSorYMrB5ur W67lncwWfrYRRaS0f5CC7ez7ZfIfBdk1TPZ0xm6PSkHTNLxFEFhwssWC3Ccjjfe/m0ln3fvf CtWxdBJ6Y5qI06b7HVu8v6b87rHYfTlDDF4s --B_3614678962_2182951530-- From nobody Tue Jul 17 10:45:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D91213104E for ; Tue, 17 Jul 2018 10:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ugvm2ohOGXbq for ; Tue, 17 Jul 2018 10:45:02 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC8613103D for ; Tue, 17 Jul 2018 10:45:00 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6HHgQvD024201; Tue, 17 Jul 2018 18:44:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=KHt+LJpj6v+nvi1i2tDsDlGGmFNTeeO60FcQFN/gBt4=; b=NRekgZkPkP7E+kgZpRSuqACGOLnP/NfvIa/fmA9wyzZ/ulMwr2QLQ5LM4J0SdLA+9DB0 y1Lue6KuNoqgH4vHvZeuyaGZdxjCcj0XaVJr2DKT/VyHJ3SVaZmLWTqZnSxPIU7C/Ohe NIMUJ+JkS8S8QTXcFaYeaWRdkSmmGjgMvZ8R0MjU1iecvTaRA3kAajE4maAVq03SKfWE Ky6aI5dU3PngFRTvB7IdFFWwE86aa7kLWT6ec+WEkdwzEV3f7gC359ugGZ64hrWx2aGk GA26WvGuFh+uQzWO7qPP1nEdFfZ4hzA45SN7IZn15dH9gPF6GzDXM9hjuxNg58i42gD/ EA== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2k9m2nr59u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 17 Jul 2018 18:44:59 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6HHZART019836; Tue, 17 Jul 2018 13:44:58 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint4.akamai.com with ESMTP id 2k7cgwaqdr-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 17 Jul 2018 13:44:58 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Jul 2018 13:44:55 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Jul 2018 13:44:55 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Tue, 17 Jul 2018 13:44:55 -0400 From: "Salz, Rich" To: "Blumenthal, Uri - 0553 - MITLL" , Eric Rescorla , Johannes Merkle CC: "" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowAAAJk44AAAYQtAAACBV4AAAFTmYD//76KAIAABFcA Date: Tue, 17 Jul 2018 17:44:54 +0000 Message-ID: <77A8548F-A6AA-46CA-A7E4-84414FCEB66D@akamai.com> References: <20180717155550.1a18202e@computer> <5cde94e3-416a-6773-c35c-9bb3952f5097@secunet.com> <6B005B2A-148F-4459-B7B5-E4ECC063EBC3@ll.mit.edu> In-Reply-To: <6B005B2A-148F-4459-B7B5-E4ECC063EBC3@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.42.203] Content-Type: multipart/alternative; boundary="_000_77A8548FA6AA46CAA7E484414FCEB66Dakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-17_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=774 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807170184 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-17_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=689 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807170185 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 17 Jul 2018 17:45:20 -0000 --_000_77A8548FA6AA46CAA7E484414FCEB66Dakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnV0IHRoZSBkcmFmdCBzdGF0ZXMNCiAgIFZhbHVlcyB3aXRoaW4gIm9ic29sZXRlX1JFU0VSVkVE IiByYW5nZXMgYXJlIHVzZWQgaW4gcHJldmlvdXMNCiAgIHZlcnNpb25zIG9mIFRMUyBhbmQgTVVT VCBOT1QgYmUgb2ZmZXJlZCBvciBuZWdvdGlhdGVkIGJ5IFRMUyAxLi4zDQoNClRMUyAxLjMgZG9l cyBub3QgZGVmaW5lIHVzZSBvZiB0aGUgQnJhaW5wb29sIGN1cnZlcy4gIEFueSBpbXBsZW1lbnRh dGlvbiB0aGF0IHdhbnRzIHRvIHVzZSB0aGVtIGluIFRMUyAxLjMgaXMgYWxyZWFkeSBvdXQtb2Yt c2NvcGUgb2YgdGhlIHN0YW5kYXJkLCBhbmQgaXMgdGhlcmVmb3JlIG5vdCByZXF1aXJlZCB0byBm b2xsb3cgTVVTVCBldGMuDQoNClRoZSBpbnRlbnQgb2YgdGhlIFdHIHdhcyB0byBub3QgYWxsb3cg c29tZSB0aGluZ3MsIGFuZCBjaGFuZ2luZyBhd2F5IGZyb20gTVVTVCB2aW9sYXRlcyB0aGF0IGlu dGVudC4NCg0KQSBzZXBhcmF0ZSBSRkMgcHJvcG9zYWwgYWRkaW5nIEJyYWlucG9vbCB0byBUTFMg MS4zIGlzIHRoZSB3YXkgdG8gZ28sIGFuZCB0aGUgb25seSB3YXkgdG8gZ28uDQoNCkZvciBub3cs IHVzZSBUTFMgMS4yDQo= --_000_77A8548FA6AA46CAA7E484414FCEB66Dakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <33B8090AF41C184E8E956813733B902E@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5o b2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpiO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFz cz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDoyNC40NXB0Ij5CdXQgdGhlIGRyYWZ0IHN0YXRlczxicj4NCiZuYnNwOyAmbmJzcDtWYWx1ZXMg d2l0aGluICZxdW90O29ic29sZXRlX1JFU0VSVkVEJnF1b3Q7IHJhbmdlcyBhcmUgdXNlZCBpbiBw cmV2aW91czxicj4NCiZuYnNwOyAmbmJzcDt2ZXJzaW9ucyBvZiBUTFMgYW5kIE1VU1QgTk9UIGJl IG9mZmVyZWQgb3IgbmVnb3RpYXRlZCBieSBUTFMgMS4uMzxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VExTIDEuMyBkb2VzIG5vdCBkZWZpbmUgdXNlIG9m IHRoZSBCcmFpbnBvb2wgY3VydmVzLiZuYnNwOyBBbnkgaW1wbGVtZW50YXRpb24gdGhhdCB3YW50 cyB0byB1c2UgdGhlbSBpbiBUTFMgMS4zIGlzIGFscmVhZHkgb3V0LW9mLXNjb3BlIG9mIHRoZSBz dGFuZGFyZCwgYW5kIGlzIHRoZXJlZm9yZSBub3QgcmVxdWlyZWQgdG8gZm9sbG93IE1VU1QgZXRj LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaW50ZW50IG9mIHRoZSBXRyB3YXMgdG8gbm90 IGFsbG93IHNvbWUgdGhpbmdzLCBhbmQgY2hhbmdpbmcgYXdheSBmcm9tIE1VU1QgdmlvbGF0ZXMg dGhhdCBpbnRlbnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkEgc2VwYXJhdGUgUkZDIHByb3Bv c2FsIGFkZGluZyBCcmFpbnBvb2wgdG8gVExTIDEuMyBpcyB0aGUgd2F5IHRvIGdvLCBhbmQgdGhl IG9ubHkgd2F5IHRvIGdvLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3Igbm93LCB1c2UgVExT IDEuMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_77A8548FA6AA46CAA7E484414FCEB66Dakamaicom_-- From nobody Tue Jul 17 18:17:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C91B413104E for ; Tue, 17 Jul 2018 18:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4JiD8zmX21Y for ; Tue, 17 Jul 2018 18:17:50 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod03.osg.ufl.edu [128.227.74.219]) (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 C40B513102C for ; Tue, 17 Jul 2018 18:17:49 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.38 Received: from exmbxprd12.ad.ufl.edu ([10.36.133.38]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w6I1HlOw061454 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 17 Jul 2018 21:17:48 -0400 Received: from exmbxprd21.ad.ufl.edu (128.227.145.166) by exmbxprd12.ad.ufl.edu (10.36.133.38) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Jul 2018 21:17:47 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd21.ad.ufl.edu (128.227.145.166) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 17 Jul 2018 21:17:47 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (216.32.181.21) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Tue, 17 Jul 2018 21:17:46 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHPR22MB0623.namprd22.prod.outlook.com (10.172.166.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Wed, 18 Jul 2018 01:17:44 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f%2]) with mapi id 15.20.0973.016; Wed, 18 Jul 2018 01:17:44 +0000 From: "Patton,Christopher J" To: "tls@ietf.org" Thread-Topic: Proposed changes to draft-ietf-tls-subcerts Thread-Index: AQHUHjQqsE1M6CF49EGVkJJk0Fkh4Q== Date: Wed, 18 Jul 2018 01:17:44 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8800:f546:26a0:5f54:ae8a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB0623; 6:8077gXG1oNd1jZwRz6OLkbXPc51hQeFwK81klVCxQUbi4o9k3KO7/T4yAJyfQ9415mu9TibnWUwL3CNqYVHhMA8imM7l2MJ0Qc3P+D/D9ekP1rwwFo3afeG7LxYOipQYuav1Xg71ufIxWm9Ur6jI3589pII+0nQTgXW/HmQT8h77/DI0NaemVP39T22ikYuCaJmN4DAb/7PzLBWIvvCU4MwvdahtWiEaq8snoHECPoV4oLgdWNRACpfpBRSorvuUaXpZeTJ/gCg1t6fDBiCFT/vGGSzHQIMNrncthS+LfdqxxEK/yC8Ev3RDwlhKqK02drpVAvTmOIu598/M2iVeaDR0kSofpASplazE7xEO/L5IYL2Sc1PTZjXtPwuvOXyWEi3VewqGUvRVVckBARLXUS0ZR45mqR78iFiP38KqBtymYqZ44hCS1pTLKQYZdR9Op+Pt8IG6oJE3DfGrmD3xYw==; 5:5sJa+23G6wVp67TEfuni69X2LTDOO1EU6f7qcwqF21hjGTifhlLg9BJ2mrL+XOF9ZnxNRpib8eKveYdRB/zKFBJfW8FrxyHQIy8wE8sooijKotu90MvmXOgZazGPhKF9oELtwai8TK76JJp8sJdbzKbHIxAM728p9wck4TfiUdA=; 7:32gIDyifnTx8I7An6U8HZaSuHZW9n+PLxcnLt9S/FK3VvB4iJJw1q/z3ALzveak0m9MxPv6zBuHAbZP2Friszx1VUxJrNrhWSTFGBk2j6lwbYLG7dnBKX/s4KogL1fvbzBO0WlxASwcph5M1GgnFlqMO5FBJO6EKLDR5O3ZbhsBNlvSvyT/uu+WgQ60jV2jTlhIUd0NdeEZfwfgI9UdBUvP4x92AUaNL/Z/tqSYWZpcKo8kpWtVveNPXirOag3xL x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: c302b896-4b08-4da9-1e8d-08d5ec4c4421 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0623; x-ms-traffictypediagnostic: MWHPR22MB0623: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:MWHPR22MB0623; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0623; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(136003)(39860400002)(396003)(346002)(366004)(199004)(189003)(53754006)(55016002)(5250100002)(68736007)(2906002)(6506007)(478600001)(2501003)(74316002)(7696005)(606006)(236005)(54896002)(6306002)(6606003)(6916009)(19627405001)(9686003)(75432002)(14454004)(88552002)(53936002)(33656002)(5640700003)(5660300001)(966005)(6436002)(316002)(786003)(2900100001)(8936002)(86362001)(25786009)(97736004)(186003)(81166006)(81156014)(102836004)(6116002)(486006)(1730700003)(256004)(105586002)(7736002)(476003)(8676002)(2351001)(99286004)(106356001)(46003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0623; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: dYr1cjijSztqWe5EDIwR6+klY+aohStZfXJchuT3d1sU11Qfusz0nHfqoSk5/lldZPWRT3ZaGsPalKB63ZI+NxGUJ52YQ13FFpBHzxbcOEuKsGx9+hT8bO+jfALjYXeqoeDZuC5mraDgsKKz+pfK4zkZgLYs0ds1ZriYOu9SA+c7CG8LFIHQ35BCw6XJ6XgAZ7xtnxygEjGQfTjLEprUUePq6z8mj6myRkUNPi2UOqjKhK6OeeYXLqRIcAAYox1b1EW77pagm6eSeBDFVFECH1HKjvKudfsBA9NnQFG8+zv+Tl8bpG/JDU+VS29vkHhQIDZFSzEpT/GH6rFECVn9vxjz6/lRFgmudcz1AsVw5p8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB04618EDC85B44409E9530AEFC6530MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c302b896-4b08-4da9-1e8d-08d5ec4c4421 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2018 01:17:44.3490 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0623 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-17_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=810 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180012 X-UFL-Spam-Level: * Archived-At: Subject: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 01:17:54 -0000 --_000_MWHPR22MB04618EDC85B44409E9530AEFC6530MWHPR22MB0461namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I've added a few pull requests to the draft "Delegated credentials for TLS"= that address the proposals discussed at IETF. Specifically: * https://github.com/tlswg/tls-subcerts/pull/8 -- Creates a tighter bin= ding of the DC to the handshake parameters; * https://github.com/tlswg/tls-subcerts/pull/9 -- Permits mandatory del= egation-key isolation, addresses the proposed"must-use-DC" TLS feature exte= nsion; * https://github.com/tlswg/tls-subcerts/pull/10 -- drops support for TL= S 1.2. Comments on these changes are welcome; feel free to chime in on GitHub. Thanks, Chris Patton --_000_MWHPR22MB04618EDC85B44409E9530AEFC6530MWHPR22MB0461namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all, 


I've added a few pull reques= ts to the draft "Delegated credentials for TLS" that address the = proposals discussed at IETF.

Specifically:


Comments on these changes are welcome; feel free to chime in on GitHub.

Thanks,
Chris Patton



--_000_MWHPR22MB04618EDC85B44409E9530AEFC6530MWHPR22MB0461namp_-- From nobody Tue Jul 17 19:30:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4148D130EDD for ; Tue, 17 Jul 2018 19:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGBxe1sM5Sqk for ; Tue, 17 Jul 2018 19:30:42 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17F5130EE9 for ; Tue, 17 Jul 2018 19:30:41 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id A96FB29E344; Tue, 17 Jul 2018 22:30:39 -0400 (EDT) Date: Tue, 17 Jul 2018 22:30:39 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180718023039.GV33554@straasha.imrryr.org> Reply-To: tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 02:30:45 -0000 Below I shall try to address a few of the concerns raised in writing. You can read just the high-level notes above my signature, diving into the corresponding detailed exposition below my signature as you see fit. Apologies for lack of hypertext links. 0. The draft as approved by the IESG, describes unilateral pinning by the client. We all agree that was not a good idea, but it was a well-intended attempt to address a real security gap. 1. The hypothetical "assertive use-case" Richard mentions that is based on just the current draft is a non-starter. [ Sadly, Paul forgot to disabuse the audience of its possibility on Monday ] If the WebPKI is presumed never compromised then we don't need a DANE alternative. With the present draft, DANE offers no protection when the WebPKI is compromised. 2. Denial of existence reached consensus on list shortly after London, we just need to polish up the text. It is also quite useful for the greenfield applications that can make do without pinning. I was surprised to hear some suggest that denial of existence remains outside the WG consensus. 3. Given denial of existence, a cached policy that strictly requires the extension (STS-like extension pinning) can be removed in multiple ways. Clients can also initially limit the maximum pinned extension support lifetime, to avoid excessive exposure to any overly eager servers that promise more than they can deliver. 4. Concern that the transport provider, not the domain owner commits to the downgrade protection of future connections. This is mitigated by mutually agreed settings between the customer and the provider and the customer's freedom to drop TLSA records in advance of a provider switch. The customer (domain owner can delete the TLSA records, and within one "extension support lifetime" all extant pins will expire. 5. Concerns that more than a 2 byte lifetime is needed for a downgrade protection design. Neither subdomain pinning nor a testing mode are good fit for a TLS-layer mechanism. Other similar STS mechanisms have no additional knobs that might apply. In summary, I'd like to propose that we get an updated draft out the door *now* with denial of existence word-smithed and updated security considerations based on Ben's text in the pull request. We can then quickly follow that up with some final on-list discussion around downgrade protection, be it a fixed two bytes of lifetime (in TBD units with TBD implementation guidance for non-zero values), or one byte of length (initially zero) for a TBD (initialy opaque, TBD specification) payload. I see no benefit from a nested extension block. This is just a needlessly more complex way of doing separate extensions. With either two bytes or an opaque<0..255>, libraries implement the extension once, and applications can implement downgrade protection with no new extensions needed in libraries once the TBD bits are defined, just process the downgrade-protection payload. My preference is for the two bytes, which simplifies the application API (extension conveys a network short value rather than an opaque octet string). If all we need in addition is a testing bit, with some sort of in-band signalling (new alert?) for the missing extension halving the max lifetime from ~7.5 years, to ~3.8 years is fine, and in any case we get to choose the scale to yield the right range, 15 bits of granularity is plenty. That said, variable length (0 or up to 255) will do if there's really a plausible use-case for more bells/whistles in the extension that make sense at the TLS layer across the application ecosystem (HTTPS, IMAP, XMPP, NTTP, SUBMIT, POP, ...). The only remaining alternatives are to severely limit the application scope or work on a separate (almost identical) extension that fixes the issues in this one. It would have all the features of this one, plus the controversial payload, and would deprecate the present draft on security grounds. -- Viktor. 0. The draft as approved by the IESG, describes unilateral pinning by the client. We all agree that was not a good idea, but it was a well-intended attempt to address a real security gap. This was added late in the original WG last call and went largely unnoticed by the community, including the IESG. It was only when some of us tried to argue for a more robust downgrade-protection mechanism that the original unilateral pinning was noticed and pointed out, and at that juncture the draft went back to the WG to remove the unilateral TOFU pinning. And yet the TOFU pinning was there in order to try to close the gap between the intended scope and actual security properties of the specification. 1. The hypothetical "assertive use-case" Richard mentions that is based on just the current draft is a non-starter. [ Sadly, Paul forgot to disabuse the audience of its possibility on Monday ] If the WebPKI is presumed never compromised then we don't need a DANE alternative. With the present draft, DANE offers no protection when the WebPKI is compromised. For multiple years (perhaps a decade or more) of the initial deployment of the extension in some existing TLS application the majority of clients and servers will support only WebPKI and not DANE. Servers that rely on this extension to authenticate a privately issued (or self-signed) certificate would therefore fail to interoperate with the vast majority of clients. Clients that don't fall back to WebPKI in the absence of a DANE TLSA chain would not interoperate with the vast majority of servers. Rather than lose interoperability with the majority of potential clients, non-hypothetical servers will get a certificate from Let's Encrypt or similar and *then* perhaps consider getting *additional* security from DANE. Only a negligible fraction of servers are going to select DANE-only just to save spending $0 on a WebPKI-certificate. Similar considerations rule out a rapid transition to DANE-only clients. The bast majority of clients will do WebPKI fallback. The extension, as defined in the present draft, can be trivially stripped by an attacker able to obtain a fraudulent WebPKI certificate. Therefore, for existing applications, it neither obviates the need for WebPKI certificates, nor offers any additional security. Some clients might by local policy mandate DANE with some servers, but this is not a scalable model for the Internet. So all that one gets from (assertive) WebPKI + DANE is the extra complexity cost of managing TLSA records in DNSSEC and the cost of possible failure if TLSA record update automation fails. There is no benefit at all, so even correctly managed TLSA records are just extra baggage, that gains no security beyond WebPKI. This guarantees negligible deployment. If DANE is to have any use at all, it MUST be downgrade resistant. This is not controversial, when last discussed, even the majority (even those who've been rather reluctant to support "pinning") of responses broadly agreed with the cost/benefit analysis that showed DANE without downgrade protection to be all cost and no benefit. 2. Denial of existence reached consensus on list shortly after London, we just need to polish up the text. It is also quite useful for the greenfield applications that can make do without pinning. I was surprised to hear some suggest that denial of existence remains outside the WG consensus. Denial of existence helps even/especially in the immediate "green field" use-case, i.e. in applications that mandate the extension. Such clients can then interoperate with servers that are (to coin a term) "DANE chain ready", but don't yet have DNSSEC or have not yet worked out the operational details of publishing TLSA records. The server can send a denial of existence proof (even if its own zone is unsigned, in which case it sends proof of that from some ancestor domain), and then the client can securely fall back to WebPKI, or TOFU... 3. Given denial of existence, a cached policy that strictly requires the extension (STS-like extension pinning) can be removed in multiple ways. Clients can also initially limit the maximum pinned extension support lifetime, to avoid excessive exposure to any overly eager servers that promise more than they can deliver. a. Start sending a TTL of zero, authenticated via the current DANE TLSA records. b. Delete the TLSA records. Send a denial of existence proof. c. Stop doing DNSSEC. Send a denial of existence proof, of insecure delegation of the domain. If any of the above happens at least one "pin lifetime" prior to moving the service to a new platform that does not support the extension, there is no friction for clients that reconnect after a long break. If the proposed scale of 1h-65536h (max out at ~7.5 years) is deemed too risky on the high end, perhaps we can reach consensus on units of minutes, which tops out at ~45.5 days. That would cover the majority of recurrent connections to a site, while allowing a timely planned move to a provider that does not support the extension. It would still adequately cover MUAs sending and receiving email, NNTP and XMPP clients, connecting regularly to their servers, ... 4. Concern that the transport provider, not the domain owner commits to the downgrade protection of future connections. This is mitigated by mutually agreed settings between the customer and the provider and the customer's freedom to drop TLSA records in advance of a provider switch. The customer (domain owner can delete the TLSA records, and within one "extension support lifetime" all extant pins will expire. Yes, the commitment signal comes from the transport provider, but denial of existence resets or prevents a strict extension requirement, so a strict policy can only be set when the domain has both DNSSEC and TLSA records. The transport provider would *not* be able to pin the extension in the absence of DNSSEC and TLSA records at the served domain. Presumably, the domain owner would like to see the TLSA records used, else why publish them. One might also expect that the transport endpoint provider is operating the service for the benefit of and in concert with the domain owner. If the domain owner wants no pinning, or pinning for just a short time (days or weeks, not months or years), then that's what the transport provider will be be delivering (or they'll not have very many customers). 5. Concerns that more than a 2 byte lifetime is needed for a downgrade protection design. Neither subdomain pinning nor a testing mode are good fit for a TLS-layer mechanism. Other similar STS mechanisms have no additional knobs that might apply. a. At least an extension lifetime TTL is needed to address the downgrade attack. Zero bytes is definitely not enough. b. DANE TLSA records are seervice-specific, they cover *one* port on one named transport endpoint. Pinning subdomains as in some STS variants is not natural here. DANE chain stapling is a transport-layer (TLS) not an application-layer mechanism. Robust pinning for subdomains drags in the public suffix list, and is much too complex for a general-purpose TLS-layer mechanism. c. Testing is not a good fit at this layer, all that's pinned is the ability to deliver the extension, after a previous connection delivered DANE TLSA records and a non-zero extension support lifetime. There is no TLS-layer mechanism for the client to inform servers that don't offer the extension that this extension was expected while continuing the connection. The closest we get is the TLS 1.3 missing_extension(109) alert, which does not carry the id of the mission extension, and is a failure alert. Out-of-band notification would require HTTP support in applications that can't generally be expected to include an HTTP implementation. From nobody Tue Jul 17 23:56:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 922D9130F09 for ; Tue, 17 Jul 2018 23:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TH67ssgQj36E for ; Tue, 17 Jul 2018 23:56:23 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0177F130DC8 for ; Tue, 17 Jul 2018 23:56:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id DA5544F754; Wed, 18 Jul 2018 09:56:19 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 130HWSycvf9E; Wed, 18 Jul 2018 09:56:19 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 4FD2E79; Wed, 18 Jul 2018 09:56:17 +0300 (EEST) Date: Wed, 18 Jul 2018 09:56:16 +0300 From: Ilari Liusvaara To: "Patton,Christopher J" Cc: "tls@ietf.org" Message-ID: <20180718065616.GA18428@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 06:56:26 -0000 On Wed, Jul 18, 2018 at 01:17:44AM +0000, Patton,Christopher J wrote: > Hi all, > > > I've added a few pull requests to the draft "Delegated credentials for TLS" that address the proposals discussed at IETF. > > Specifically: > > * https://github.com/tlswg/tls-subcerts/pull/8 -- Creates a tighter binding of the DC to the handshake parameters; > * https://github.com/tlswg/tls-subcerts/pull/9 -- Permits mandatory delegation-key isolation, addresses the proposed"must-use-DC" TLS feature extension; > * https://github.com/tlswg/tls-subcerts/pull/10 -- drops support for TLS 1.2. > > Comments on these changes are welcome; feel free to chime in on GitHub. The way mandatory delegation-key usage is specified seems to violate how X.509 critical bit is supposed to work. The bit is not supposed to alter processing of recogized extensions, it is only supposed to alter processing of unrecognized extensions from ignore to reject. If you want to actually alter the processing to require such certificate to always only be used for DC, you need a flag somewhere else, which might be payload of the extension (and that extension should _also_ be marked critical to ensure that clients that do not understand DC do not accept it). -Ilari From nobody Wed Jul 18 01:52:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A50F0130E0C for ; Wed, 18 Jul 2018 01:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P1gcxYC1us3 for ; Wed, 18 Jul 2018 01:52:13 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 CC5AE130DDD for ; Wed, 18 Jul 2018 01:52:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1531903933; x=1563439933; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KHVyxNHr6QMDZjOKRBf2KneszFWpmKl4Ch7f1ZuKQn8=; b=p8005OHvBZVkMOmxdqiw9SgbRetOTRtgHdVOnFA26Ep0t2JReXRdUyN7 PHJR7b66934uLdlQchlUuNF2S7plfYwIhabXqPVjtiwwaXHaQsX+FbpzB jkB+T2vAKL76xvFxAl9m8QRtkXpu7xueoXgb7s5NDKgarh6b3RwaRRvrC b1YmZmG+DrTGEh1IWJCqtmy6dUWSq4IpdKmPKJgJwItMfD4WenBGVG6Y1 PVx+77UTXlYj1KnP1EQdRhi0m/QKfWrorth+4NStdsIaf6+C1KEGhyKhE YArpBIcpoUCOaHOWKaaBCXqS530ve1B4kR7k2Z3uN4z3MUVV7sDyM1iSc Q==; X-IronPort-AV: E=Sophos;i="5.51,369,1526299200"; d="scan'208";a="21831720" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.5 - Outgoing - Outgoing Received: from uxcn13-tdc-d.uoa.auckland.ac.nz ([10.6.3.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Jul 2018 20:52:09 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-d.UoA.auckland.ac.nz (10.6.3.5) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 18 Jul 2018 20:52:09 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1263.000; Wed, 18 Jul 2018 20:52:09 +1200 From: Peter Gutmann To: Eric Rescorla , Dan Brown CC: "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pP//TLsAgAAROwCAAAEvAIAB8+aN Date: Wed, 18 Jul 2018 08:52:08 +0000 Message-ID: <1531903926363.56642@cs.auckland.ac.nz> References: <20180717155550.1a18202e@computer> <20180717145727.8642646.41749.26614@blackberry.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 08:52:16 -0000 Eric=A0Rescorla writes:=0A= =0A= >Well, I note that the text also says "or have had very little usage,"=0A= =0A= When the Brainpool-with-TLS RFC was published, several implementers announc= ed=0A= that they'd added support within 24 hours of the RFC appearing (in some cas= es=0A= determined by time zones).=0A= =0A= I think that was the fastest uptake of any security RFC I've ever seen.=0A= =0A= Peter.=0A= From nobody Wed Jul 18 01:54:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96160130DDD for ; Wed, 18 Jul 2018 01:54:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXAWNJxpmYyD for ; Wed, 18 Jul 2018 01:54:53 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E47A130E0C for ; Wed, 18 Jul 2018 01:54:52 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id v22-v6so2878657lfe.8 for ; Wed, 18 Jul 2018 01:54:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=pWh1ZxgTEaHJCYCIJsjhYZI8uE1s7sM1rOYZ4oboO5I=; b=ZJd2NUthcYPJPTu+JarrB+C7O0rpKpvK0ro6y+xMDcvyU2pAjlFak3S6j3ZlqPtANe N2BkbsM8ASoX6AFh97pZx5E/gsaczkyu8uRiIRp0xl2sVClPrwtfxZ/0sRDf5rEaCOcV /MnvQnChUvAEKhSy9neD87sGHB1dlvvtJPfybMDc73lvMkXIxqSifBioihjcAPvJM0F+ JICdGoLnriKjg8W7t6URvBWFqzrP1/wdR66L/YX3zUc5cB+H56kNrNI33eyoCCK+jJga XLXARKb8m0oTnOdA/A5AP5+ZHAdGjGgBEYIY8tZlHkZTibel8ppZp8SDWUkf+ixj2q1k X5jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=pWh1ZxgTEaHJCYCIJsjhYZI8uE1s7sM1rOYZ4oboO5I=; b=QRABSq6dhPPgk3uKlCliYEB8BgQMVZ/hfqcGmGjVUmy0dVKWrOaI07IBQ4J/Gy2xw4 4Rmn0ULeV9+/TBPGhyPQwMfrqzLVICMeARX6X8+q4s0ndcUmJI91Fayv/QGUUcifQFit fDp7YXFLxxSVOoyQQh8ZH0E3U+HVjaaL5qHP8P0Yg4VGmcWtYQJeQB8aotE7GA5mcW9s aukskP7Jml3GUxMVMv9bAS+zKLX6Jkjd8uKm3C7mZ+kiERXwXDZFJQjOMFj6ZVMUccYE LYQLRGCsfCzH8AcXeKizPtFcxcFBG4laQEtwrg7m07WilPaXlu20KTQJVOvTPn1yRqgc L6rw== X-Gm-Message-State: AOUpUlFCxTTxQXHmNloOAp8PMsPvPm80i3vShbL3Ljt8bGu98Dr1Ip6n whsf5f0Q2thF8vhP3+F9b3kfl1gJDvuhkkZT7xhumk2x X-Google-Smtp-Source: AAOMgpex3llO9U1wRFxo2C+wqfxYzN51btDi2rM42n0J8qvs/PtrVlXor5B613XiPiAzlqWYiJjVYOf9J136m9AGo68= X-Received: by 2002:a19:1460:: with SMTP id k93-v6mr3279875lfi.15.1531904090503; Wed, 18 Jul 2018 01:54:50 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 01:54:09 -0700 (PDT) In-Reply-To: <20180718023039.GV33554@straasha.imrryr.org> References: <20180718023039.GV33554@straasha.imrryr.org> From: Eric Rescorla Date: Wed, 18 Jul 2018 01:54:09 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000250ea20571423753" Archived-At: Subject: Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 08:54:57 -0000 --000000000000250ea20571423753 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni wrote: > > c. Testing is not a good fit at this layer, all that's > pinned is the ability to deliver the extension, after a > previous connection delivered DANE TLSA records and a > non-zero extension support lifetime. There is no TLS-layer > mechanism for the client to inform servers that don't > offer the extension that this extension was expected > while continuing the connection. The closest we get is > the TLS 1.3 missing_extension(109) alert, which does not > carry the id of the mission extension, and is a failure > alert. Out-of-band notification would require HTTP > support in applications that can't generally be expected > to include an HTTP implementation. > To the extent to which this is true, it's an argument that one should be pinning at a different layer. -Ekr > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000250ea20571423753 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni <ietf-dane@dukhovni.= org> wrote:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 c. Testing is not a good fit at this layer, all= that's
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0pinned is the ability to deliver t= he extension, after a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0previous connection delivered DANE= TLSA records and a
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0non-zero extension support lifetim= e.=C2=A0 There is no TLS-layer
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0mechanism for the client to inform= servers that don't
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0offer the extension that this exte= nsion was expected
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0while continuing the connection.= =C2=A0 The closest we get is
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the TLS 1.3 missing_extension(109)= alert, which does not
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0carry the id of the mission extens= ion, and is a failure
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0alert.=C2=A0 Out-of-band notificat= ion would require HTTP
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0support in applications that can&#= 39;t generally be expected
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0to include an HTTP implementation.=

To the extent to which this is true, i= t's an argument that one should be
pinning at a different lay= er.

-Ekr


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

--000000000000250ea20571423753-- From nobody Wed Jul 18 04:13:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B481277C8 for ; Wed, 18 Jul 2018 04:13:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 994vx1G21W_f for ; Wed, 18 Jul 2018 04:13:51 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46E67127332 for ; Wed, 18 Jul 2018 04:13:51 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 50DAA401EF0B; Wed, 18 Jul 2018 11:13:50 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id 44AF8111E402; Wed, 18 Jul 2018 11:13:48 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Wed, 18 Jul 2018 13:13:48 +0200 Message-ID: <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> In-Reply-To: <1531903926363.56642@cs.auckland.ac.nz> References: <1531903926363.56642@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1708100.ifiNs6Lulj"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 18 Jul 2018 11:13:50 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 18 Jul 2018 11:13:50 +0000 (UTC) for IP:'10.11.54.3' DOMAIN:'int-mx03.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 11:13:54 -0000 --nextPart1708100.ifiNs6Lulj Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 18 July 2018 10:52:08 CEST Peter Gutmann wrote: > Eric Rescorla writes: > >Well, I note that the text also says "or have had very little usage," >=20 > When the Brainpool-with-TLS RFC was published, several implementers > announced that they'd added support within 24 hours of the RFC appearing > (in some cases determined by time zones). >=20 > I think that was the fastest uptake of any security RFC I've ever seen. just because implementations added them, doesn't mean they were deployed last time I performed scan looking for them, they haven't crossed 10%, 4 ye= ars=20 *after* the RFC7027 was published: https://securitypitfalls.wordpress.com/2017/04/ =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart1708100.ifiNs6Lulj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltPIOwACgkQkqjRuAHS 9fX1zg/+P6JLPb0vXhyMkPvtnc4g+oFHSqpKCcqLgWbqTcFMfAFeoXqHv7wLmFTh aenAr0KHHrP0NejAHcusFxbPi7L0T96KRW+Aj12yA28sjz4K9uQavQvgpdE1hXFa +XJ3I6Kv9wG1F9M8RMn3/GXlxlhx+5JgGIO1+cIJB2IdWxExEKVp2aCwpdeU13PQ OYd+k8GoOuH6X7/TzxPC/Ds2i07E0XxNp/XjQvRYyaEt4FuDeG4K3lelrldb9jto 9DR22Q4KPxy1L7JgwqgBb0zXFgOsmlRux+U+enmcEyA+WhewRmi4nt/zTGo8Y7mE 5L/miG+5C7GLyQFK7kaZPtY74QuQSoMurdCHo0+HwLbheRIptO6pfWG/LEu0kvbU bV7sQE/q/6VhDUuSqhdOcvPF7hBcPbYT0YvXnW+KSGvtiQaEN89sSwhUAzWoNCEt rV8aSsw/Ai00VlSV9NmHAYMIbcbXKinWV+QR8L49025xUIAZGTHoqt3ldiASCKtf 9zENwyoJprX/KAiTJbIIFAjhnNh4LiCrsz+pRSryx2zbblbs0huyQ5P/Wrcrgwyf g4suQNo9QOgiEm41umzkjLmInIxcIlYN1rB56rcOCOS4yR1ifdwvfQEZ+mZt/izZ 0ocNkkYz4g91IB3NsgrWbFXuRjdJPMDUtKjCipedgQAyyuC+SR8= =kkHx -----END PGP SIGNATURE----- --nextPart1708100.ifiNs6Lulj-- From nobody Wed Jul 18 05:42:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A07131189 for ; Wed, 18 Jul 2018 05:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzIZwebcWWJC for ; Wed, 18 Jul 2018 05:42:01 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7AC13117F for ; Wed, 18 Jul 2018 05:42:01 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id q129-v6so1650144ywg.8 for ; Wed, 18 Jul 2018 05:42:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=2Lfn9BYfhl3G3SqEqMUa7EY5FWuPjq/keWhf3icnf1I=; b=FXckC5aZSTVJobZUGOHrb8SkK7pFvthNhuYqRA+WSgZng51A8mBvfCnylQSI0T+GUK neUp6dZ4+K5K3q7vwe6PRX2NbsxGy/NBZLZYQvUNSh/6VpQMRHk0mm4RNG+HPhpm1DUC JHna3EI6PKU0I4N/I9DCXgplSUofOy3c7z2WB3TsMHUZ0GlKT8JlG8yZtJjV0CzSChNT mhHsJQcz6OkENz+zJNhJHuXxFCn6G/zAViYcuNSimYDklAM6oeaxVdwZ+JGNXqtHz9we jSe/mtcnECze9UoZP2cz0yiacfhq/WKwkcFaXn3QTMS+L2qimo6ajmJRIaPEk2Wj1e/v /A0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=2Lfn9BYfhl3G3SqEqMUa7EY5FWuPjq/keWhf3icnf1I=; b=hd/MoFJ9NcjKzAJv7fZJRnSgRf8Kt+dXm9dfuGoJ8lZ5NbTrNNBKWnMMSznuShynK7 bJcbu0EchTHojY8A0S6MCi9JRKIzLnt5QyMyhZG5h++EdG8GFP2gMH9cPu+3kFBjIbz0 wMbmC6IJCcfdQX3xua68BRy6KExIJJ0pd9q4aM+Mz3a3maor1fPlQWQBIiBqcSjWP7nU UeqOD2wtc2Wc5OsHl8aDPWWX3nVQwJaG2tB5Y2EwNToeD/pYLnUDf4/Ot6i5XPqDomZG GxWSr6FM1yrc/+2s/YUr3wBsVPppSwb3T+JpjuNmZem0sXF2Gh7QKT63hztTmqIDITcq oCrw== X-Gm-Message-State: AOUpUlGu2LqV4r9dBp6OQuFs+xG4wjQW4mwl4uzbbLrobbp2HIR60Tdb SxV8FwK/heX8sySS/8vYIglsy4KstdHbXhEyh/j4WXmHva4= X-Google-Smtp-Source: AAOMgpd7x8hfXRXPQftEBXnkV4O/FrXwTGXtjrwer18P4juzHxnJbP6bhA/thlb8Q6V8s4bhUx7NXJDOjYSQO0nyN04= X-Received: by 2002:a0d:c9c2:: with SMTP id l185-v6mr2971801ywd.164.1531917720481; Wed, 18 Jul 2018 05:42:00 -0700 (PDT) MIME-Version: 1.0 References: <20180718023039.GV33554@straasha.imrryr.org> In-Reply-To: From: Shumon Huque Date: Wed, 18 Jul 2018 08:41:59 -0400 Message-ID: To: TLS WG Content-Type: multipart/alternative; boundary="0000000000008df443057145636c" Archived-At: Subject: Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 12:42:04 -0000 --0000000000008df443057145636c Content-Type: text/plain; charset="UTF-8" On Wed, Jul 18, 2018 at 4:55 AM Eric Rescorla wrote: > > To the extent to which this is true, it's an argument that one should be > pinning at a different layer. > > (I've mentioned this in private email to some of you, but for broader input, I'm throwing it out on the list too.) On the topic of other layers .. At yesterday's WG meeting, Sam Weiler suggested that the pinning information could be conveyed via the DNS. That way you would not need new holes/fields in the TLS extension. Paul said it doesn't work. But Willem Toorop and I discussed it after the meeting, and think that it does. There could be a new DANEPIN RR type at the same TLSA record name (or TXT if we're opposed to new types) that could carry the pinning TTL and whatever else. This could be conveyed as just an additional record (and its signature) in the dnssec_chain extension data (which is designed as a sequence of RRsets), and authenticated in the same manner. It is of course vulnerable to stripping on first contact, but so is the entire TLS extension including any pinning fields, in the incremental deployment scenario. So it has no worse or better security properties. This could also express a generic DANE pinning capability that is not tied only to a TLS channel. Servers that don't want to be pinned would not advertise this record, and clients that don't implement pinning would just ignore this record if it is present in the chain. (It is probably possible to convey this DNS info in other ways, such as defining a new TLSA record usage field for pinning. So the TLSA RRset would include an additional record for pinning if needed. But I suspect there might be more arguments about such a design). This does need the dnssec_chain extension to allow authenticated denial chains to be delivered. Based on past list discussion, it appears to me that there is rough consensus to allow that, and the yet unpublished draft text in the github repo already includes it. Shumon Huque --0000000000008df443057145636c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jul 18= , 2018 at 4:55 AM Eric Rescorla <ekr@rtf= m.com> wrote:

To the extent to which this is true, it's an argument = that one should be
pinning at a different layer.


(I've mentioned = this in private email to some of you, but for broader input, I'm throwi= ng it out on the list too.)

On the topic of other = layers ..

At yesterday's WG meeting, Sam Weile= r suggested that the pinning information could be conveyed via the DNS. Tha= t way you would not need new holes/fields in the TLS extension. Paul said i= t doesn't work. But Willem Toorop and I discussed it after the meeting,= and think that it does.

There could be a new DANE= PIN RR type at the same TLSA record name (or TXT if we're opposed to ne= w types) that could carry the pinning TTL and whatever else. This could be = conveyed as just an additional record (and its signature) in the dnssec_cha= in extension data (which is designed as a sequence of RRsets), and authenti= cated in the same manner. It is of course vulnerable to stripping on first = contact, but so is the entire TLS extension including any pinning fields, i= n the incremental deployment scenario. So it has no worse or better securit= y properties.

This could also express a generic DA= NE pinning capability that is not tied only to a TLS channel.
Servers that don't want to be pinned would not advertise th= is record, and clients that don't implement pinning would just ignore t= his record if it is present in the chain.

(It is p= robably possible to convey this DNS info in other ways, such as defining a = new TLSA record usage field for pinning. So the TLSA RRset would include an= additional record for pinning if needed. But I suspect there might be more= arguments about such a design).

This does need th= e dnssec_chain extension to allow authenticated denial chains to be deliver= ed. Based on past list discussion, it appears to me that there is rough con= sensus to allow that, and the yet unpublished draft text in the github repo= already includes it.

Shumon Huque

<= /div>
--0000000000008df443057145636c-- From nobody Wed Jul 18 07:07:20 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4805D130EC1 for ; Wed, 18 Jul 2018 07:07:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZWJKCOxmNk1F for ; Wed, 18 Jul 2018 07:07:15 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE23E126F72 for ; Wed, 18 Jul 2018 07:07:14 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41VzVS4pb8zCyk; Wed, 18 Jul 2018 16:07:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1531922832; bh=ZHUqr6rJZ6ed4MEV2f57zqtYdo0vXymRD4Cbu4oEgKQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LNjnzcWOxz8c8yztndclC26mjIsHOk/HMgvlQ9t5h/vp1JINy8WD/bg6XfWQ8///l HX+w8dtxu09r8ZyC8TkWHgF7UfmZL6pzyX7l+R9esLrD7IQ/nmiKGOgXyQGzFoZa5N up8BMkn8WVvmNuToX7Q0Ho/FKYm+qkVp95PrNYYw= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bFZhz6xHxt-0; Wed, 18 Jul 2018 16:07:11 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 18 Jul 2018 16:07:11 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 84F08A7E0B; Wed, 18 Jul 2018 10:07:10 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 84F08A7E0B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 7AD334009E6D; Wed, 18 Jul 2018 10:07:10 -0400 (EDT) Date: Wed, 18 Jul 2018 10:07:10 -0400 (EDT) From: Paul Wouters To: Eric Rescorla cc: "" In-Reply-To: Message-ID: References: <20180718023039.GV33554@straasha.imrryr.org> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 14:07:19 -0000 On Wed, 18 Jul 2018, Eric Rescorla wrote: > detailed response to concerns raised in the room on Monday > > On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni wrote: >         c. Testing is not a good fit at this layer, all that's >            pinned is the ability to deliver the extension, after a >            previous connection delivered DANE TLSA records and a >            non-zero extension support lifetime.  There is no TLS-layer >            mechanism for the client to inform servers that don't >            offer the extension that this extension was expected >            while continuing the connection.  The closest we get is >            the TLS 1.3 missing_extension(109) alert, which does not >            carry the id of the mission extension, and is a failure >            alert.  Out-of-band notification would require HTTP >            support in applications that can't generally be expected >            to include an HTTP implementation. > > > To the extent to which this is true, it's an argument that one should be > pinning at a different layer. Those clients with clean DNS transport, like mail servers, already use the TLSA records the moment these appear in DNS. The zone owner already fully commited the service to this, regardless of what you do at other layers. So you are already commited to the DATA in DNS. Each transport has their own properties and we found that pinning the TLS extension is needed when using TLS stappling. It is a property of the transport lawyer, so anything about that transport layer should not happen elsewhere. Paul From nobody Wed Jul 18 09:55:00 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED9141311EE for ; Wed, 18 Jul 2018 09:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wZ5c3MdeB3Vw for ; Wed, 18 Jul 2018 09:54:55 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D35012DD85 for ; Wed, 18 Jul 2018 09:54:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 882A8201CD for ; Wed, 18 Jul 2018 20:54:38 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZENCNaQfbVHj for ; Wed, 18 Jul 2018 20:54:38 +0200 (CEST) Received: from mail-essen-02.secunet.de (mail-essen-02.secunet.de [10.53.40.205]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 01108201CA for ; Wed, 18 Jul 2018 20:54:38 +0200 (CEST) Received: from MAIL-ESSEN-01.secunet.de ([fe80::1c79:38b7:821e:46b4]) by mail-essen-02.secunet.de ([fe80::4431:e661:14d0:41ce%16]) with mapi id 14.03.0399.000; Wed, 18 Jul 2018 18:54:53 +0200 From: "Bruckert, Leonie" To: "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pP//9F8AgAAROgCAAAEvAIABKxEAgAAnlQD//4HO0A== Date: Wed, 18 Jul 2018 16:54:52 +0000 Message-ID: References: <1531903926363.56642@cs.auckland.ac.nz> <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> In-Reply-To: <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-g-data-mailsecurity-for-exchange-state: 0 x-g-data-mailsecurity-for-exchange-error: 0 x-g-data-mailsecurity-for-exchange-sender: 23 x-g-data-mailsecurity-for-exchange-server: cbe3d3f7-b9e3-4256-b890-f24c4306a01c x-exclaimer-md-config: 2c86f778-e09b-4440-8b15-867914633a10 x-g-data-mailsecurity-for-exchange-guid: 3E61EF0E-85F7-4B65-9506-39C206416EC3 Content-Type: multipart/alternative; boundary="_000_DE8E4C1F24911E469CC24DD4819274AA27734B81mailessen01secu_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 16:54:59 -0000 --_000_DE8E4C1F24911E469CC24DD4819274AA27734B81mailessen01secu_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgSSB1bmRlcnN0YW5kIGZyb20gdGhlIHRleHQsIHRoZSBCcmFpbnBvb2wgY3VydmVzIGl0c2Vs ZiBhcmUgbm90IHByb2hpYml0ZWQsIGJ1dCB0aGUgY29kZSBwb2ludHMgYXNzaWduZWQgdG8gdGhl bS4gU28sIGlmIHBlb3BsZSBzdGlsbCB3YW50IHRvIHVzZSB0aGUgQnJhaW5wb29sIGN1cnZlcyBp biBjb25mb3JtYW5jZSB3aXRoIHRoZSBzdGFuZGFyZCwgSSB3b3VsZCBjb25jbHVkZSB0aGF0IHRo ZXkgY2FuIHJlcXVlc3QgbmV3IGNvZGUgcG9pbnRzLiBUaGlzIHdvdWxkIHJlc3VsdCBpbiBhbiBJ QU5BIHJlZ2lzdHJ5IHdpdGggZHVwbGljYXRlZCBlbnRyaWVzIGZvciBicmFpbnBvb2wgY3VydmVz OiB0aGUgb2xkLCBub3cgcHJvaGliaXRlZCBjb2RlIHBvaW50cyBhbmQgdGhlIG5ldyBhc3NpZ25l ZCBvbmVzLiBJcyB0aGlzIGNvcnJlY3Q/DQoNCg0KDQpMZW9uaWUNCg== --_000_DE8E4C1F24911E469CC24DD4819274AA27734B81mailessen01secu_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvTm9TcGFjaW5nLCBsaS5N c29Ob1NwYWNpbmcsIGRpdi5Nc29Ob1NwYWNpbmcNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjE7DQoJ bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCnNwYW4uRS1NYWlsRm9ybWF0dm9ybGFnZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBw dDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDIuMGNtIDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0 aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJERSIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vU3BhY2luZyI+PHNwYW4gbGFuZz0iRU4tVVMiPkFzIEkgdW5kZXJzdGFu ZCBmcm9tIHRoZSB0ZXh0LCB0aGUgQnJhaW5wb29sIGN1cnZlcyBpdHNlbGYgYXJlIG5vdCBwcm9o aWJpdGVkLCBidXQgdGhlIGNvZGUgcG9pbnRzIGFzc2lnbmVkIHRvIHRoZW0uIFNvLCBpZiBwZW9w bGUgc3RpbGwgd2FudCB0byB1c2UgdGhlIEJyYWlucG9vbCBjdXJ2ZXMgaW4gY29uZm9ybWFuY2Ug d2l0aCB0aGUgc3RhbmRhcmQsIEkgd291bGQgY29uY2x1ZGUNCiB0aGF0IHRoZXkgY2FuIHJlcXVl c3QgbmV3IGNvZGUgcG9pbnRzLiBUaGlzIHdvdWxkIHJlc3VsdCBpbiBhbiBJQU5BIHJlZ2lzdHJ5 IHdpdGggZHVwbGljYXRlZCBlbnRyaWVzIGZvciBicmFpbnBvb2wgY3VydmVzOiB0aGUgb2xkLCBu b3cgcHJvaGliaXRlZCBjb2RlIHBvaW50cyBhbmQgdGhlIG5ldyBhc3NpZ25lZCBvbmVzLiBJcyB0 aGlzIGNvcnJlY3Q/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vU3BhY2lu ZyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob1NwYWNpbmciPjxzcGFuIGxhbmc9IkVOLVVTIj5MZW9uaWU8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_DE8E4C1F24911E469CC24DD4819274AA27734B81mailessen01secu_-- From nobody Wed Jul 18 10:19:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2370E131241 for ; Wed, 18 Jul 2018 10:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jyoch3cRN2my for ; Wed, 18 Jul 2018 10:18:48 -0700 (PDT) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D88131212 for ; Wed, 18 Jul 2018 10:18:48 -0700 (PDT) Received: by mail-oi0-x242.google.com with SMTP id y207-v6so10204428oie.13 for ; Wed, 18 Jul 2018 10:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=0+owjE7sp2MGXiOz/rKTqdliMwSJvpSAcfbIS9s4b3s=; b=sbjRGf6S6Hqo6/sbU3Rn7359vzcGDggmKkyMvONxaLajS8OPAxS0Ul0ADHV7LlZC5A WuJKblehs1NHAHvvZrM7ECIt6vLeRRWTCMWXHjMUA53eQrN93Yd0h3YDnilqgGSgxEHc Vk7Qy8Ri019Gh64T6R41+GfYet5a3WNElbLWQ+r1QgWiaxOlz04O8yzdF/U/3+1qKMBO Jh1v3Dxk9NjJeP37mWxsePvjHO5Ej5XENfgvEra15T8wZ1LxAGIxhICu4ds4+QDfAYna 1cIB2rxjauBbJIOy+sffO38uJYVR0+iFE+0vqiPPel2oA/u93NERS2ih9xOzHpRxUr0I 2Acw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=0+owjE7sp2MGXiOz/rKTqdliMwSJvpSAcfbIS9s4b3s=; b=tmIjYQ3ptTh0VFLJi7z2hHJ4iLnFhZViqFV9uRITtDEqALWApjZeddxWlAMK5lsd4o 9kWH/dTr3QTcucG9TgDuou0a5BQHGVMp4q0cM0Kid0Pg/6F3G+uoqB4yECFKko/DE0Va j9dsiaA0cjm+rikm7pSSwKEytEf6SlJiD16FUl6bCQ46knqnTxdhM2NecARlLFpnk2LQ hsnZfaD14RMBzFPK7hDlaWEtdqoaqwurA6YRzbaUkyqPcpjeRKtoaQ3x1SLIpeAn8TAu Hq7WOwIdCvibfvjaPgIqRVPjTBk+j62Ps0e2JP53rVuwM2BlYsRtwyiXIJJgi/eWU+sP RW0Q== X-Gm-Message-State: AOUpUlFwzlqAp3nnaMp3Qzzi55wDFboLeR7M+tBGJw958ASUVtVpH+2r yn8CkyjDWJtsty3Gw97lQDRFvP1SqlJ4USpEUpHj1a2v X-Google-Smtp-Source: AAOMgpe7JV8CxFDMrm9fvMmKGfi4z4M9tpGz9+ci2uCIJ6AMCwFk2RL1OPOWUUcqtlETJgFZ6FGzcK2Uyer0xlXRpkg= X-Received: by 2002:aca:f383:: with SMTP id r125-v6mr6963451oih.6.1531934327383; Wed, 18 Jul 2018 10:18:47 -0700 (PDT) MIME-Version: 1.0 References: <153176915207.21824.6939177297174810137.idtracker@ietfa.amsl.com> In-Reply-To: <153176915207.21824.6939177297174810137.idtracker@ietfa.amsl.com> From: Richard Barnes Date: Wed, 18 Jul 2018 13:18:33 -0400 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000673a27057149419e" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 17:19:01 -0000 --000000000000673a27057149419e Content-Type: text/plain; charset="UTF-8" Hey TLS WG, In response to some of the list discussion since the last IETF, Owen and I revised our TLS PAKE draft. In the current version, instead of binding to a single PAKE (SPAKE2+), it defines a general container that can carry messages for any PAKE that has the right shape. And we think that "right shape" covers several current PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, ... The chairs have graciously allotted us 5min on the agenda for Thursday, where I'd like to ask for the WG to adopt the document. So please speak up if you think this is an interesting problem for the TLS WG to work on, and if you think the approach in this document is a good starting point. Happy for comments here or at the microphone on Thursday! Thanks, --Richard ---------- Forwarded message --------- From: Date: Mon, Jul 16, 2018 at 3:25 PM Subject: New Version Notification for draft-barnes-tls-pake-04.txt To: Richard Barnes , Owen Friel A new version of I-D, draft-barnes-tls-pake-04.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-tls-pake Revision: 04 Title: Usage of PAKE with TLS 1.3 Document date: 2018-07-16 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.txt Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/ Htmlized: https://tools.ietf.org/html/draft-barnes-tls-pake-04 Htmlized: https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake Diff: https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-04 Abstract: The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. 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 --000000000000673a27057149419e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey TLS WG,

In response to s= ome of the list discussion since the last IETF, Owen and I revised our TLS = PAKE draft.=C2=A0 In the current version, instead of binding to a single PA= KE (SPAKE2+), it defines a general container that can carry messages for an= y PAKE that has the right shape.=C2=A0 And we think that "right shape&= quot; covers several current PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, ...

The chairs have graciously allotted us 5min on the a= genda for Thursday, where I'd like to ask for the WG to adopt the docum= ent.=C2=A0 So please speak up if you think this is an interesting problem f= or the TLS WG to work on, and if you think the approach in this document is= a good starting point.=C2=A0 Happy for comments here or at the microphone = on Thursday!

Thanks,
--Richard


---= ------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Mon, Jul 16, 2018 at 3:25 PM
Subject: New Version Notificatio= n for draft-barnes-tls-pake-04.txt
To: Richard Barnes <rlb@ipv.sx>= , Owen Friel <ofriel@cisco.com&g= t;



A new version of I-D, draft-barnes-tls-pake-04.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-barnes-tls-pake
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Usage of PAKE with TLS 1.3
Document date:=C2=A0 2018-07-16
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.t= xt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-barnes-tls-pake/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-barnes-tls-pake-04
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/html/draft-barnes-tls-pake
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-tls-pake-04

Abstract:
=C2=A0 =C2=A0The pre-shared key mechanism available in TLS 1.3 is not suita= ble for
=C2=A0 =C2=A0usage with low-entropy keys, such as passwords entered by user= s.
=C2=A0 =C2=A0This document describes an extension that enables the use of =C2=A0 =C2=A0password-authenticated key exchange protocols with TLS 1.3.



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

The IETF Secretariat

--000000000000673a27057149419e-- From nobody Wed Jul 18 10:33:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4893B131185 for ; Wed, 18 Jul 2018 10:33:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uYbbbZ9uNj5 for ; Wed, 18 Jul 2018 10:33:25 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod05.osg.ufl.edu [128.227.74.125]) (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 6849E13121C for ; Wed, 18 Jul 2018 10:33:24 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.35 Received: from exmbxprd04.ad.ufl.edu ([10.36.133.35]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w6IHWPgQ024722 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Wed, 18 Jul 2018 13:33:22 -0400 Received: from exmbxprd21.ad.ufl.edu (128.227.145.166) by exmbxprd04.ad.ufl.edu (10.36.133.35) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 18 Jul 2018 13:33:07 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd21.ad.ufl.edu (128.227.145.166) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 18 Jul 2018 13:33:07 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (216.32.180.17) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Wed, 18 Jul 2018 13:33:07 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHPR22MB0336.namprd22.prod.outlook.com (10.173.54.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Wed, 18 Jul 2018 17:33:05 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f%2]) with mapi id 15.20.0973.016; Wed, 18 Jul 2018 17:33:05 +0000 From: "Patton,Christopher J" To: Ilari Liusvaara CC: "tls@ietf.org" Thread-Topic: [TLS] Proposed changes to draft-ietf-tls-subcerts Thread-Index: AQHUHjQqsE1M6CF49EGVkJJk0Fkh4aSUjG8AgACw7A8= Date: Wed, 18 Jul 2018 17:33:05 +0000 Message-ID: References: , <20180718065616.GA18428@LK-Perkele-VII> In-Reply-To: <20180718065616.GA18428@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8800:f546:26a0:5f54:ae8a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB0336; 7:AJv3lbJkNC1OoGcm8omSXin1KWqoVObuu7vV3hRM34MUmGYlDFiJJRPFcGUAoliSk7tqlUNR65iUeD3bEhdqIQ4Ux1TJhh34bOtb9F9tFGL7szmrTgN6cXGVAPAVppCbBGpdOWK51s5dPzCEIhwLnK6czuRt3gCQRaurpM6fBfLYsx07FnWObX5I2pTfCcYN8ryfNqFT8oGsRAx+w8+dE5PbhbSU6iALPbR5A9WmXKgpPrI2lTkm/UFadEAI4e/t x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8d97d3b0-bdca-4ed5-7e09-08d5ecd48503 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0336; x-ms-traffictypediagnostic: MWHPR22MB0336: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR22MB0336; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0336; x-forefront-prvs: 0737B96801 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(366004)(39860400002)(376002)(53754006)(199004)(189003)(19627405001)(46003)(5250100002)(54896002)(25786009)(11346002)(316002)(476003)(786003)(6116002)(33656002)(6436002)(236005)(53936002)(9686003)(966005)(88552002)(68736007)(5660300001)(99286004)(478600001)(486006)(14454004)(6306002)(186003)(76176011)(106356001)(606006)(6246003)(75432002)(8936002)(6916009)(14444005)(6606003)(86362001)(105586002)(8676002)(7736002)(74316002)(81156014)(81166006)(7696005)(256004)(102836004)(229853002)(4326008)(2906002)(6506007)(53546011)(2900100001)(97736004)(446003)(575784001)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0336; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: CPPFO8/JjgVNsGS7+fcMdN4cMC5JJRyJ9eIq9mGHsrz42DsfBFxpNX2ZMpgwqbZ1RA4rmwxPynY7hZxpgX9Vg6vs4ooWhHSDtvrcdiOV3eKVVToirYFtrYP5o8XuZ0KNCNL9JXKInu3YZeAfog4LzOn9rhPJ63n5Hqmn+UOajNNoQAH/XKB0kw19/D71oiX8mCbnD4oC26PJ9ITr7h5gHv8k/nDKzItYLSduSuyf0Rh6yj2HsMQ5VZ1kj6QDlPcPr2QZSrsi2TCE0nCpTI5FkNlC8WXUK3wbGkBhWCYqbP1jXT12SG3gK0urySLfn7RnWclJskAfOO1zbQTiLJ2FONsUXtfvzszKAsSXAPw0t90= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB0461118EB7800D5163537091C6530MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8d97d3b0-bdca-4ed5-7e09-08d5ecd48503 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jul 2018 17:33:05.0332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0336 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180193 X-UFL-Spam-Level: * Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 17:33:35 -0000 --_000_MWHPR22MB0461118EB7800D5163537091C6530MWHPR22MB0461namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ilari, I suppose you mean that this condition violates the critical bit = semantics: "If the extension is marked critical, then the server MUST NOT o= ffer the certificate unless it offers a delegated credential as well." Your suggesting adding a "must-use-DC" flag to the extension body? The cond= ition would be: "If the flag of the extension is set, then th= e server MUST NOT offer the certificate unless ..." ________________________________ From: ilariliusvaara@welho.com on behalf of Ilar= i Liusvaara Sent: Wednesday, July 18, 2018 2:56 AM To: Patton,Christopher J Cc: tls@ietf.org Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts On Wed, Jul 18, 2018 at 01:17:44AM +0000, Patton,Christopher J wrote: > Hi all, > > > I've added a few pull requests to the draft "Delegated credentials for TL= S" that address the proposals discussed at IETF. > > Specifically: > > * https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_t= lswg_tls-2Dsubcerts_pull_8&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2K= ikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiFCDoqBxni= QnDZR8n5dA&s=3DJkn0aWEFHUhGyKTRFXHGPt7fdDUvxeXGJQkwmPR2HdU&e=3D -- Creates = a tighter binding of the DC to the handshake parameters; > * https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_t= lswg_tls-2Dsubcerts_pull_9&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2K= ikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiFCDoqBxni= QnDZR8n5dA&s=3DlsmtgnR-B-sA-BU_CcpbAtB7UC4Q0zyFqOLOGB3-FZM&e=3D -- Permits = mandatory delegation-key isolation, addresses the proposed"must-use-DC" TLS= feature extension; > * https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_t= lswg_tls-2Dsubcerts_pull_10&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2= KikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiFCDoqBxn= iQnDZR8n5dA&s=3DQ1-PUQoj_LL4tFA4UPxTUiiUNRYfsdAf9nhNCaAItZY&e=3D -- drops s= upport for TLS 1.2. > > Comments on these changes are welcome; feel free to chime in on GitHub. The way mandatory delegation-key usage is specified seems to violate how X.509 critical bit is supposed to work. The bit is not supposed to alter processing of recogized extensions, it is only supposed to alter processing of unrecognized extensions from ignore to reject. If you want to actually alter the processing to require such certificate to always only be used for DC, you need a flag somewhere else, which might be payload of the extension (and that extension should _also_ be marked critical to ensure that clients that do not understand DC do not accept it). -Ilari --_000_MWHPR22MB0461118EB7800D5163537091C6530MWHPR22MB0461namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ilari, I suppose yo= u mean that this condition violates the critical bit semantics: "If the extension is marked critical, then the server MUST NOT offer the certificate =

= Your suggesting adding a "must-use-DC" flag to the extension= body? The condition would be: "If the <must-use-DC> flag of the= extension is set, then the server MUST NOT offer the certificate unless ..."

=

=



From: ilariliusvaara@welho.= com <ilariliusvaara@welho.com> on behalf of Ilari Liusvaara <ilari= liusvaara@welho.com>
Sent: Wednesday, July 18, 2018 2:56 AM
To: Patton,Christopher J
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts
 
On Wed, Jul 18, 2018 at 01:17:44AM +0000, Patt= on,Christopher J wrote:
> Hi all,
>
>
> I've added a few pull requests to the draft "Delegated credential= s for TLS" that address the proposals discussed at IETF.
>
> Specifically:
>
>   *   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_tlswg_tls= -2Dsubcerts_pull_8&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2K= ikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiF= CDoqBxniQnDZR8n5dA&s=3DJkn0aWEFHUhGyKTRFXHGPt7fdDUvxeXGJQkwmPR2HdU&= e=3D -- Creates a tighter binding of the DC to the handshake parameters;
>   *   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_tlswg_tls= -2Dsubcerts_pull_9&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2K= ikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiF= CDoqBxniQnDZR8n5dA&s=3DlsmtgnR-B-sA-BU_CcpbAtB7UC4Q0zyFqOLOGB3-FZM&= e=3D -- Permits mandatory delegation-key isolation, addresses the proposed"= ;must-use-DC" TLS feature extension;
>   *   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_tlswg_tls= -2Dsubcerts_pull_10&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2= KikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0Uui= FCDoqBxniQnDZR8n5dA&s=3DQ1-PUQoj_LL4tFA4UPxTUiiUNRYfsdAf9nhNCaAItZY&= ;e=3D -- drops support for TLS 1.2.
>
> Comments on these changes are welcome; feel free to chime in on GitHub= .

The way mandatory delegation-key usage is specified seems to violate how X.509 critical bit is supposed to work. The bit is not supposed to alter processing of recogized extensions, it is only supposed to alter processing=
of unrecognized extensions from ignore to reject.

If you want to actually alter the processing to require such
certificate to always only be used for DC, you need a flag somewhere
else, which might be payload of the extension (and that extension
should _also_ be marked critical to ensure that clients that do not
understand DC do not accept it).


-Ilari
--_000_MWHPR22MB0461118EB7800D5163537091C6530MWHPR22MB0461namp_-- From nobody Wed Jul 18 10:33:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3906113121C for ; Wed, 18 Jul 2018 10:33:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXqbyBzkCfib for ; Wed, 18 Jul 2018 10:33:42 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58477131236 for ; Wed, 18 Jul 2018 10:33:42 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6IHVwdK014070; Wed, 18 Jul 2018 18:33:42 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=5yVBw72jZxJD//LkrLvzWL0IMmw/HQWJjoYKlT0FoOM=; b=cMfocf/nvOBHFjLwi4nD+hfUV38xdyhK8PCgO2Hkuk9hRJ9E04IFxrtMp1sPsYSLdbug mTISazgKRAnJVErCtL36LnVJRbkZjjc9HrwlerZ3TSfJ7gamidcsGZaF8Cs7UcvqnaBV vssQtbfpF6ZwSa2u6urzG+ELbD+MEL8dVhvJ5ItRmYO7eVgMdDDPOQatfPNP8jbqxRIW sxFxHm7bs3B7xqc+IOjQ8bPcDiG8j7dOao+B1BGOSNHZ/73RZF1WYEjDgZhW7a01sjEj kfIOaYpYkk/huCFim5VOKqj/WC5Y1OlXPqg1u+rxxajLhi5lkLfm0NncbUtVMKSSMqS6 +Q== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2ka77hrdyn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Jul 2018 18:33:41 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6IHJviw028905; Wed, 18 Jul 2018 13:33:40 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint1.akamai.com with ESMTP id 2k7cgugwfy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Jul 2018 13:33:40 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 18 Jul 2018 13:33:39 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Wed, 18 Jul 2018 13:33:39 -0400 From: "Salz, Rich" To: "Bruckert, Leonie" , "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowA///OLCuAAEQ9AIABKxEAgAAnlQCAAF9LAP//x8YA Date: Wed, 18 Jul 2018 17:33:39 +0000 Message-ID: <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> References: <1531903926363.56642@cs.auckland.ac.nz> <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.146] Content-Type: multipart/alternative; boundary="_000_1980F0B365DB48F7B8983389731C8125akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=729 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180191 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=648 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180193 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 17:33:50 -0000 --_000_1980F0B365DB48F7B8983389731C8125akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBUaGlzIHdvdWxkIHJlc3VsdCBpbiBhbiBJQU5BIHJlZ2lzdHJ5IHdpdGggZHVwbGljYXRlZCBl bnRyaWVzIGZvciBicmFpbnBvb2wgY3VydmVzOiB0aGUgb2xkLCBub3cgcHJvaGliaXRlZCBjb2Rl IHBvaW50cyBhbmQgdGhlIG5ldyBhc3NpZ25lZCBvbmVzLiBJcyB0aGlzIGNvcnJlY3Q/DQoNCg0K DQpOby4gIFRoZSByZXF1ZXN0IGNvdWxkIGFzayBmb3IgdGhlIGV4aXN0aW5nIHJlc2VydmVkIGNv ZGVwb2ludHMgdG8gYmUgcmUtdXNlZC4NCg0KDQo= --_000_1980F0B365DB48F7B8983389731C8125akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7D0832C999DB7B4DBDC6D530A8DEBB35@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu TXNvTm9TcGFjaW5nLCBsaS5Nc29Ob1NwYWNpbmcsIGRpdi5Nc29Ob1NwYWNpbmcNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNTYuN3B0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob1NwYWNpbmciPiZndDsgVGhpcyB3b3VsZCByZXN1bHQgaW4gYW4gSUFO QSByZWdpc3RyeSB3aXRoIGR1cGxpY2F0ZWQgZW50cmllcyBmb3IgYnJhaW5wb29sIGN1cnZlczog dGhlIG9sZCwgbm93IHByb2hpYml0ZWQgY29kZSBwb2ludHMgYW5kIHRoZSBuZXcgYXNzaWduZWQg b25lcy4gSXMgdGhpcyBjb3JyZWN0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vU3Bh Y2luZyI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9TcGFjaW5nIj5Oby4m bmJzcDsgVGhlIHJlcXVlc3QgY291bGQgYXNrIGZvciB0aGUgZXhpc3RpbmcgcmVzZXJ2ZWQgY29k ZXBvaW50cyB0byBiZSByZS11c2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vU3Bh Y2luZyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_1980F0B365DB48F7B8983389731C8125akamaicom_-- From nobody Wed Jul 18 10:37:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98DC130E3E for ; Wed, 18 Jul 2018 10:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FGSxOn0bGJh for ; Wed, 18 Jul 2018 10:37:35 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 013B8130E3B for ; Wed, 18 Jul 2018 10:37:34 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6IHW3VJ028497; Wed, 18 Jul 2018 18:37:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=QkiZSTK+gsgyLoQKMietAVgDrsSAYGVcj6VTe9HTZ9g=; b=F+In14W5rhXyd3SA9fb6p3/CetFJH/bGybWup53Lb2foSw7tVyhQtfpLpl2OOrpV/GxR R26EwjLRy2ZtDO1ZcOV8TT+tHJkwUOuRiKvrnCG1MmF2fFv2cKXDIsiqgEcrcXntfsJ+ 36UG/6xrMU39tdFDKC6wNlM5fLGmzPfbblEAXezIJzyBYI+Fndi+AfU1xyzn3e8JcOvp 8GhjsxbvUKZCypzlGCM0ATA38OwTNGeW04PVwG+7HaQ0AJ+ve2bKo2XM7mWsFTGfmvSj HfRkTUz9yKdZFZ+EPzkM4r8f+4jAkdnDZIBQcrEnORWA3K0x0AtqGmOpC6clWGD/M3+I sw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2k9ps72q3n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Jul 2018 18:37:32 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6IHYiSr012245; Wed, 18 Jul 2018 13:37:31 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2k7cgugwy5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Jul 2018 13:37:31 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 18 Jul 2018 13:37:30 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Wed, 18 Jul 2018 13:37:30 -0400 From: "Salz, Rich" To: "Salz, Rich" , "Bruckert, Leonie" , "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowA///OLCuAAEQ9AIABKxEAgAAnlQCAAF9LAP//x8YAgAABFIA= Date: Wed, 18 Jul 2018 17:37:29 +0000 Message-ID: References: <1531903926363.56642@cs.auckland.ac.nz> <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> In-Reply-To: <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.146] Content-Type: multipart/alternative; boundary="_000_A2AB0D16DC0848BBB3BD34DAF5D03DF4akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=565 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180193 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=484 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180193 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 17:37:37 -0000 --_000_A2AB0D16DC0848BBB3BD34DAF5D03DF4akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pj4gVGhpcyB3b3VsZCByZXN1bHQgaW4gYW4gSUFOQSByZWdpc3RyeSB3aXRoIGR1cGxpY2F0ZWQg ZW50cmllcyBmb3IgYnJhaW5wb29sIGN1cnZlczogdGhlIG9sZCwgbm93IHByb2hpYml0ZWQgY29k ZSBwb2ludHMgYW5kIHRoZSBuZXcgYXNzaWduZWQgb25lcy4gSXMgdGhpcyBjb3JyZWN0Pw0KDQoN Cg0KPk5vLiAgVGhlIHJlcXVlc3QgY291bGQgYXNrIGZvciB0aGUgZXhpc3RpbmcgcmVzZXJ2ZWQg Y29kZXBvaW50cyB0byBiZSByZS11c2VkLg0KDQoNCg0KQnV0IG5vdGUgdGhhdCB0aGUgV0cgZGVj aXNpb24gd2FzIHRvIHJlbW92ZSBhbGwgc29ydHMgb2YgdGhpbmdzLCBpbmNsdWRpbmcgQnJhaW5w b29sIGN1cnZlcywgYW5kIGl0IHdvdWxkIHByb2JhYmx5IGJlIGJlc3QgdG8gZGlzY3VzcyBicmlu Z2luZyB0aGVtIGJhY2sgdmlhIHRoZSBXRy4NCg0KDQoNClRoZSBUTFMgcmVnaXN0cmllcyBhcmUg bm93IGRvY3VtZW50LXJlcXVpcmVkIEJUVy4NCg0KDQo= --_000_A2AB0D16DC0848BBB3BD34DAF5D03DF4akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <061BE702EC2805458A5392B4CABC8DA0@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu TXNvTm9TcGFjaW5nLCBsaS5Nc29Ob1NwYWNpbmcsIGRpdi5Nc29Ob1NwYWNpbmcNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjcwLjg1cHQgNzAu ODVwdCA1Ni43cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vU3BhY2luZyI+Jmd0OyZndDsgVGhpcyB3b3VsZCByZXN1bHQgaW4gYW4gSUFOQSByZWdp c3RyeSB3aXRoIGR1cGxpY2F0ZWQgZW50cmllcyBmb3IgYnJhaW5wb29sIGN1cnZlczogdGhlIG9s ZCwgbm93IHByb2hpYml0ZWQgY29kZSBwb2ludHMgYW5kIHRoZSBuZXcgYXNzaWduZWQgb25lcy4g SXMgdGhpcyBjb3JyZWN0PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vU3BhY2luZyI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9TcGFjaW5nIj4mZ3Q7Tm8uJm5i c3A7IFRoZSByZXF1ZXN0IGNvdWxkIGFzayBmb3IgdGhlIGV4aXN0aW5nIHJlc2VydmVkIGNvZGVw b2ludHMgdG8gYmUgcmUtdXNlZC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob1NwYWNp bmciPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vU3BhY2luZyI+QnV0IG5v dGUgdGhhdCB0aGUgV0cgZGVjaXNpb24gd2FzIHRvIHJlbW92ZSBhbGwgc29ydHMgb2YgdGhpbmdz LCBpbmNsdWRpbmcgQnJhaW5wb29sIGN1cnZlcywgYW5kIGl0IHdvdWxkIHByb2JhYmx5IGJlIGJl c3QgdG8gZGlzY3VzcyBicmluZ2luZyB0aGVtIGJhY2sgdmlhIHRoZSBXRy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob1NwYWNpbmciPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vU3BhY2luZyI+VGhlIFRMUyByZWdpc3RyaWVzIGFyZSBub3cgZG9jdW1lbnQtcmVx dWlyZWQgQlRXLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vU3BhY2luZyI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A2AB0D16DC0848BBB3BD34DAF5D03DF4akamaicom_-- From nobody Wed Jul 18 10:40:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96BDD1311EF for ; Wed, 18 Jul 2018 10:40:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoxztljP0VhG for ; Wed, 18 Jul 2018 10:40:37 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 90793130F9C for ; Wed, 18 Jul 2018 10:40:36 -0700 (PDT) Received: from LLE2K16-MBX01.mitll.ad.local (LLE2K16-MBX01.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id w6IHeTMM029392; Wed, 18 Jul 2018 13:40:30 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: "Salz, Rich" , "Bruckert, Leonie" , "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowA///OLCuAAEQ9AIABKxEAgAAnlQCAAF9LAP//x8YAgAACGoA= Date: Wed, 18 Jul 2018 17:40:28 +0000 Message-ID: <7098419E-6F96-4398-A736-38C2F99E11FF@ll.mit.edu> References: <1531903926363.56642@cs.auckland.ac.nz> <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> In-Reply-To: <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.d.1.180523 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3614766069_1364456924" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=896 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180193 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 17:40:45 -0000 --B_3614766069_1364456924 Content-type: multipart/alternative; boundary="B_3614766069_491545346" --B_3614766069_491545346 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit > This would result in an IANA registry with duplicated entries for brainpool curves: the old, now prohibited code points and the new assigned ones. Is this correct? No. The request could ask for the existing reserved codepoints to be re-used. No offense meant, but this does not make sense. Code points were assigned, probably some apps were/are using them. Now those code points are to be invalidated, and new ones assigned instead?! --B_3614766069_491545346 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

> This would result= in an IANA registry with duplicated entries for brainpool curves: the old, = now prohibited code points and the new assigned ones. Is this correct?<= /o:p>

 

No.  The request could = ask for the existing reserved codepoints to be re-used.

 

No offense meant,= but this does not make sense. Code points were assigned, probably some apps= were/are using them. Now those code points are to be invalidated, and new o= nes assigned instead?!

--B_3614766069_491545346-- --B_3614766069_1364456924 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQg0Np9GV1OPoz9+JX/ icjSUH18xADsuk2140Vf9Hzx/HMwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTgwNzE4MTc0MTA5WjANBgkqhkiG9w0BAQEFAASCAQBBzlhdFt2vsv6SGOfA Df058lCLmeUSw3ZdZizL4feErmN5pynmUTVqqCfme8zOABchtqKxugHK6DNOTMomaWqWnIqv 9+8biK8KrC2ya1gVzDh16JEMn88WJ9bLRgiDhvcvaPxOAQ/RY1HUf7vc5L8jZ6Nal/uSAh14 umQMmNfG4fb3+IEgCX7yFQ0S2dO1rdpgdwNs/NL2OxEx0xAjc8esw+qORYpf5fjwKFyx3KgQ //XHUq92tXwluol6/lFYXhgqRQnTPujnwJrA3VVEPozOlqflmutWuSAStuvnAc9oZgmfZqna j1gGS15WX3BTtwSRo6cQeATI/tCvrYOOvVZp --B_3614766069_1364456924-- From nobody Wed Jul 18 10:42:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 744BB130E61 for ; Wed, 18 Jul 2018 10:42:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uLREvz5cCwQh for ; Wed, 18 Jul 2018 10:42:48 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36FD9130E33 for ; Wed, 18 Jul 2018 10:42:48 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6IHcSTC000365; Wed, 18 Jul 2018 18:42:47 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=oG8NWHMm7kMmgdJzpIeW4lJa7EcZrVxSLxl1PI/XPaA=; b=El5HVWVTu8XZlv64Au5tlJxE3SlLjeKWIJStr6DhCa3bjF2vj0Wu7IcDko3+UTbhGf2q sPx4xz/YocC5/PaQw4sXtEHfK4A3InfmIZRR0xElcbb+5PxNDfNu0ufT3nrIW0lDB7ZV W/MRyUMtzhgB5B2rNkUCf0ZOQ/Eiw1UF68PJJcH9adVyiw4Dnrjtz2sPz7/7pj9DQvRd 0OhezBitlKyXH4irm/8kLP/Zfp5/7tMhxHcOLYUsIxQmmWmid7BxpqnWu+S6rICIgs8Q ZD01vtZ/lbCQtw1f6oKcBPnLlAJrUU21iEHsmv8X3DYp+IVRagd65tCf318OJnBjruOm fw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2k9p34ttky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Jul 2018 18:42:47 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6IHYiP8008587; Wed, 18 Jul 2018 13:42:46 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2k7cgurvqk-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 18 Jul 2018 13:42:46 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 18 Jul 2018 13:42:45 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Wed, 18 Jul 2018 13:42:45 -0400 From: "Salz, Rich" To: "Blumenthal, Uri - 0553 - MITLL" , "Bruckert, Leonie" , "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowA///OLCuAAEQ9AIABKxEAgAAnlQCAAF9LAP//x8YAgAACGoCAAABxAA== Date: Wed, 18 Jul 2018 17:42:44 +0000 Message-ID: References: <1531903926363.56642@cs.auckland.ac.nz> <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> <7098419E-6F96-4398-A736-38C2F99E11FF@ll.mit.edu> In-Reply-To: <7098419E-6F96-4398-A736-38C2F99E11FF@ll.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.146] Content-Type: multipart/alternative; boundary="_000_C32B31CBCCDC457BB8CCD61B9441BE96akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=789 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180193 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=709 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180193 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 17:42:51 -0000 --_000_C32B31CBCCDC457BB8CCD61B9441BE96akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Pk5vIG9mZmVuc2UgbWVhbnQsIGJ1dCB0aGlzIGRvZXMgbm90IG1ha2Ugc2Vuc2UuIENvZGUgcG9p bnRzIHdlcmUgYXNzaWduZWQsIHByb2JhYmx5IHNvbWUgYXBwcyB3ZXJlL2FyZSB1c2luZyB0aGVt LiBOb3cgdGhvc2UgY29kZSBwb2ludHMgYXJlIHRvIGJlIGludmFsaWRhdGVkLCBhbmQgbmV3IG9u ZXMgYXNzaWduZWQgaW5zdGVhZD8hDQoNCg0KDQpQZXJoYXBzIEkgYW0gY29uZnVzZWQuDQoNCg0K DQpDb2RlIHBvaW50cyBmb3IgcHJlLTEuMyB3ZXJlIGFzc2lnbmVkLCBhbmQgdGhleSBhcmUgaW52 YWxpZCBmb3IgVExTIDEuMy4gIFRob3NlIOKAnHlvdSBzaG91bGQgbm90IHNlbmQgdGhlc2UgZm9y IDEuM+KAnSBjb3VsZCBiZSByZS11c2VkIGZvciBUTFMgMS4zLCBpZiB0aGF0IHdhcyBkZXNpcmVk Lg0K --_000_C32B31CBCCDC457BB8CCD61B9441BE96akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <37C3871AE5BF2E4B864660F8CAD4D3DF@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu TXNvTm9TcGFjaW5nLCBsaS5Nc29Ob1NwYWNpbmcsIGRpdi5Nc29Ob1NwYWNpbmcNCgl7bXNvLXN0 eWxlLXByaW9yaXR5OjE7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpz cGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxT dHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDU2Ljdw dCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9TcGFj aW5nIj4mZ3Q7Tm8gb2ZmZW5zZSBtZWFudCwgYnV0IHRoaXMgZG9lcyBub3QgbWFrZSBzZW5zZS4g Q29kZSBwb2ludHMgd2VyZSBhc3NpZ25lZCwgcHJvYmFibHkgc29tZSBhcHBzIHdlcmUvYXJlIHVz aW5nIHRoZW0uIE5vdyB0aG9zZSBjb2RlIHBvaW50cyBhcmUgdG8gYmUgaW52YWxpZGF0ZWQsIGFu ZCBuZXcgb25lcyBhc3NpZ25lZCBpbnN0ZWFkPyE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob1NwYWNpbmciPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vU3BhY2lu ZyI+UGVyaGFwcyBJIGFtIGNvbmZ1c2VkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v U3BhY2luZyI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9TcGFjaW5nIj5D b2RlIHBvaW50cyBmb3IgcHJlLTEuMyB3ZXJlIGFzc2lnbmVkLCBhbmQgdGhleSBhcmUgaW52YWxp ZCBmb3IgVExTIDEuMy4mbmJzcDsgVGhvc2Ug4oCceW91IHNob3VsZCBub3Qgc2VuZCB0aGVzZSBm b3IgMS4z4oCdIGNvdWxkIGJlIHJlLXVzZWQgZm9yIFRMUyAxLjMsIGlmIHRoYXQgd2FzIGRlc2ly ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C32B31CBCCDC457BB8CCD61B9441BE96akamaicom_-- From nobody Wed Jul 18 11:00:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB83130FFB for ; Wed, 18 Jul 2018 11:00:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g0AvKkigiL25 for ; Wed, 18 Jul 2018 10:59:56 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id ADDFF130FCF for ; Wed, 18 Jul 2018 10:59:47 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id w6IHxita039598; Wed, 18 Jul 2018 13:59:44 -0400 From: "Blumenthal, Uri - 0553 - MITLL" Message-ID: <132F1996-0866-4776-9F91-C80964A8C90B@ll.mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_B2649C6C-C106-4BEF-BAA7-F742406A0A26" MIME-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 18 Jul 2018 13:59:44 -0400 In-Reply-To: CC: "Bruckert, Leonie" , "tls@ietf.org" To: Rich Salz References: <1531903926363.56642@cs.auckland.ac.nz> <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> <7098419E-6F96-4398-A736-38C2F99E11FF@ll.mit.edu> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=817 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180196 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 18:00:12 -0000 --Apple-Mail=_B2649C6C-C106-4BEF-BAA7-F742406A0A26 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > On Jul 18, 2018, at 13:42, Salz, Rich wrote: >=20 > >No offense meant, but this does not make sense. Code points were = assigned, probably some apps were/are using them. Now those code points = are to be invalidated, and new ones assigned instead?! > =20 > Perhaps I am confused. Likelier that I am confused=E2=80=A6 It=E2=80=99s been a tough day. =20 > Code points for pre-1.3 were assigned, and they are invalid for TLS = 1.3. Those =E2=80=9Cyou should not send these for 1.3=E2=80=9D could be = re-used for TLS 1.3, if that was desired. Yes this makes sense. And I think that they should, documented as = something other than =E2=80=9CRecommended=E2=80=9D. --Apple-Mail=_B2649C6C-C106-4BEF-BAA7-F742406A0A26 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

On Jul 18, 2018, at 13:42, Salz, Rich <rsalz@akamai.com> = wrote:

>No = offense meant, but this does not make sense. Code points were assigned, = probably some apps were/are using them. Now those code points are to be = invalidated, and new ones assigned instead?!
 
Perhaps I = am confused.

Likelier that I am confused=E2=80=A6 It=E2=80=99s been = a tough day.
 
Code points for pre-1.3 = were assigned, and they are invalid for TLS 1.3.  Those =E2=80=9Cyou = should not send these for 1.3=E2=80=9D could be re-used for TLS 1.3, if = that was desired.

Yes = this makes sense. And I think that they should, documented as something = other than =E2=80=9CRecommended=E2=80=9D.

= --Apple-Mail=_B2649C6C-C106-4BEF-BAA7-F742406A0A26-- From nobody Wed Jul 18 11:37:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156C9130F5E for ; Wed, 18 Jul 2018 11:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaJ6TUE8t4XJ for ; Wed, 18 Jul 2018 11:37:36 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01D75130FBA for ; Wed, 18 Jul 2018 11:37:35 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6IIaV6M025042 for ; Wed, 18 Jul 2018 19:37:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=0IQKncbMKhjOmMFfLz13De+G/saP/1l8/EUxPVAGvUI=; b=GJ+YNM59HJVlWtoFQEDqXZZLZR/g2IgISFf8lPZ9kS5+R/6JDm468VpL3WJeIkyNVsxr spptjolxKlszshi6D4Kb5aaDNFLo/ASXnX7JGvL/CSCiTPdHoCQBrGdnn3nAIVJAoFRf v43hFT9XZGTDHK5woykLpHWJIV9mXQIaJ/3oGLgbN1yhqmWNG34iMFbt6Ur6g3fUBiCR YgJMHd1CktlYkDj5FZjU8p8/7hkLYRvacMrB0uH9irZQdS7OwUGxYt6190hXrI4blh/V ya44oD5cuKY6BaT2sknnt4UwlWThEC7OKGPE1umwvqukkBFq4tRlZfOyzN2f+NMdE4vH lA== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2k9ru8tabr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 18 Jul 2018 19:37:35 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6IIZHUY031165 for ; Wed, 18 Jul 2018 14:37:34 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2k7cgw6qtg-1 for ; Wed, 18 Jul 2018 14:37:34 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 7E3392008F for ; Wed, 18 Jul 2018 18:37:34 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1ffrKP-0005pc-On for tls@ietf.org; Wed, 18 Jul 2018 13:37:33 -0500 Date: Wed, 18 Jul 2018 13:37:33 -0500 From: Benjamin Kaduk To: tls@ietf.org Message-ID: <20180718183733.GC14551@akamai.com> References: <20180718023039.GV33554@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180718023039.GV33554@straasha.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180203 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-18_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807180203 Archived-At: Subject: Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 18:37:38 -0000 Hi Viktor, Thanks for writing up your thoughts; a couple notes inline: On Tue, Jul 17, 2018 at 10:30:39PM -0400, Viktor Dukhovni wrote: > > Below I shall try to address a few of the concerns raised in writing. > You can read just the high-level notes above my signature, diving > into the corresponding detailed exposition below my signature as > you see fit. Apologies for lack of hypertext links. > > 0. The draft as approved by the IESG, describes unilateral pinning > by the client. We all agree that was not a good idea, but it > was a well-intended attempt to address a real security gap. > > 1. The hypothetical "assertive use-case" Richard mentions that is I think that the use of the shorthand terms "assertive" and "restrictive" for use cases is only causing confusion at this point, not least because it could apply both to the TLSA Certificate Usage values and to whether DANE is treated as less trusted, equally trusted, or more trusted than PKIX. If I remember the detailed discussion below correctly, you refer to the case of "DANE is equally trusted as PKIX", for which the analysis of "all the costs of both with no benefits" is a tolerable summary. > based on just the current draft is a non-starter. [ Sadly, Paul > forgot to disabuse the audience of its possibility on Monday ] > > If the WebPKI is presumed never compromised then we don't need > a DANE alternative. With the present draft, DANE offers no > protection when the WebPKI is compromised. > > 2. Denial of existence reached consensus on list shortly after > London, we just need to polish up the text. It is also quite > useful for the greenfield applications that can make do without > pinning. I was surprised to hear some suggest that denial of > existence remains outside the WG consensus. I would also be surprised to hear such suggestions; text on denial of existence is already staged in github and is just waiting on a decision to publish a new draft. (Which is, I presume, waiting for an indication of whether we're likely to gain consensus soon on any other issues that could be addressed in the same update.) -Ben From nobody Wed Jul 18 15:00:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9639A1311B8 for ; Wed, 18 Jul 2018 15:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5I7oH4_N-uhL for ; Wed, 18 Jul 2018 15:00:48 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F192813111C for ; Wed, 18 Jul 2018 15:00:35 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id d22-v6so3239562qkc.8 for ; Wed, 18 Jul 2018 15:00:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language; bh=HuM5o7v48SuWsoodGOjCEp+S/Jim26Xk67GfRxjbRJc=; b=KTVhSVws8Qmo7Cp2uThkq4giSXxy9WTx/ULCbltnjXmuRZB1psZYVK7MGnFw28qemU YNHwCJXHSsiBlf7xo2rCyr/T9E+UKANbRewualtZZ+uDANlKLGUQVfhZy57+7+lqNYaV SVGf2hZ1n1lEi12Xf1QgW6S6JVthyRLmuWZ1vVXj4XsUr9PIGAbOGpOZjL20UIMvV7a3 XgHNdPHHavSJ48moAgOC4Bo8nweNm0Evq92BD8x4ScsuErbATVRfsgStshLAKZ9/oMgc C+VqHYBjKafK/OD1f9uE/+mTNeYGL+oEa9O3Wbxg78RmJMG4jVquomRklxFhexmU6EXB a9Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language; bh=HuM5o7v48SuWsoodGOjCEp+S/Jim26Xk67GfRxjbRJc=; b=kSW6bvGFXOvQIgQ0X9+PA/iTSyQEnLJMHHBAH3Dbbn2cSCv5VIiI/Gcu4Lh+Vcgf/F aERY1D/JYz3MU7tsv1IJnGXpHmF3Ob8QOznSTiH0MhxeDpfowZe7RZ6qaNrablzhVgOM qMawMcYi0+4I1yA0I9QQN4ij/PVd8JSCNwAxjNE4E8bvH/X8So2q7Vg8+eA4mnw1nds5 rxfWmpc/a0Ph3nxFhFf1O6ElEuT7FttW9JujsfClPJDZI17e6wucCBsfbvJ4FDuF6/Pr yedBQ53B+DznBthYJqmWPvOjvslUU6btoriqvdp9FjkEGFt9RJYEzEfYbR+QbBAT8iL/ unrQ== X-Gm-Message-State: AOUpUlESL8D4IiIJ7VTiiOeJurdiRk+40Gcmj+khD4i6oA6PUHRHKqJi lgF6Q1SZHUpCwv1420dtY1LGOg== X-Google-Smtp-Source: AAOMgpcX1ADEeQKAGpi5NEddm/Xm2wqMfVgy0rltuWD0lRU8w2M6AeQ39NllIJ/teu3qWArKJyh/Ng== X-Received: by 2002:a37:380f:: with SMTP id f15-v6mr7117542qka.177.1531951235053; Wed, 18 Jul 2018 15:00:35 -0700 (PDT) Received: from SantoshBrain (pool-173-73-191-57.washdc.fios.verizon.net. [173.73.191.57]) by smtp.gmail.com with ESMTPSA id x7-v6sm4643639qtc.66.2018.07.18.15.00.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 18 Jul 2018 15:00:34 -0700 (PDT) From: "Santosh Chokhani" To: "'Patton,Christopher J'" , "'Ilari Liusvaara'" Cc: References: , <20180718065616.GA18428@LK-Perkele-VII> In-Reply-To: Date: Wed, 18 Jul 2018 18:00:32 -0400 Message-ID: <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_18B4_01D41EC1.38E748F0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AQDTD+0iUkfWEj1LH5w14OwskPk+NAM7WQffAXcRgVmmchBl8A== Content-Language: en-us Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 22:00:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_18B4_01D41EC1.38E748F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I do not think you can change an extension syntax or semantic. It is three tuple: extn ID, criticality flag, and value. You can add the syntax and semantics within the extension value as to what it means. That may not help those who do not understand the extension and cannot process the value. From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Patton,Christopher J Sent: Wednesday, July 18, 2018 1:33 PM To: Ilari Liusvaara Cc: tls@ietf.org Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts Hi Ilari, I suppose you mean that this condition violates the critical bit semantics: "If the extension is marked critical, then the server MUST NOT offer the certificate unless it offers a delegated credential as well." Your suggesting adding a "must-use-DC" flag to the extension body? The condition would be: "If the flag of the extension is set, then the server MUST NOT offer the certificate unless ..." _____ From: ilariliusvaara@welho.com > on behalf of Ilari Liusvaara > Sent: Wednesday, July 18, 2018 2:56 AM To: Patton,Christopher J Cc: tls@ietf.org Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts On Wed, Jul 18, 2018 at 01:17:44AM +0000, Patton,Christopher J wrote: > Hi all, > > > I've added a few pull requests to the draft "Delegated credentials for TLS" that address the proposals discussed at IETF. > > Specifically: > > * https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2D subcerts_pull_8 &d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Jkn0aWEFHUhGyKTRFXHGPt7 fdDUvxeXGJQkwmPR2HdU&e= -- Creates a tighter binding of the DC to the handshake parameters; > * https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2D subcerts_pull_9 &d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=lsmtgnR-B-sA-BU_CcpbAtB 7UC4Q0zyFqOLOGB3-FZM&e= -- Permits mandatory delegation-key isolation, addresses the proposed"must-use-DC" TLS feature extension; > * https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls-2D subcerts_pull_10 &d=DwIBaQ&c=pZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=VKs6yUchJieNTSwm3A bwfg&m=RriZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=Q1-PUQoj_LL4tFA4UPxTUii UNRYfsdAf9nhNCaAItZY&e= -- drops support for TLS 1.2. > > Comments on these changes are welcome; feel free to chime in on GitHub.. The way mandatory delegation-key usage is specified seems to violate how X.509 critical bit is supposed to work. The bit is not supposed to alter processing of recogized extensions, it is only supposed to alter processing of unrecognized extensions from ignore to reject. If you want to actually alter the processing to require such certificate to always only be used for DC, you need a flag somewhere else, which might be payload of the extension (and that extension should _also_ be marked critical to ensure that clients that do not understand DC do not accept it). -Ilari ------=_NextPart_000_18B4_01D41EC1.38E748F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I do not think you can change an extension syntax or semantic.  It = is three tuple: extn ID, criticality flag, and = value.

 

You can add the syntax and semantics  within the extension value = as to what it means.   That may not help those who do not = understand the extension and cannot process the = value.

 

From:<= /b> = TLS [mailto:tls-bounces@ietf.org] On Behalf Of Patton,Christopher = J
Sent: Wednesday, July 18, 2018 1:33 PM
To: Ilari = Liusvaara <ilariliusvaara@welho.com>
Cc: = tls@ietf.org
Subject: Re: [TLS] Proposed changes to = draft-ietf-tls-subcerts

 

Hi Ilari, I = suppose you mean that this condition violates the critical bit = semantics: "If the extension is marked critical, then the = server MUST NOT offer the certificate unless it offers a delegated = credential as well."

 <= /span>

Your = suggesting adding a "must-use-DC" flag to the extension = body? The condition would be: "If the <must-use-DC> flag of = the extension is set, then the server MUST NOT offer the certificate = unless ..."

 <= /span>

 <= /span>

 <= /span>

F= rom: = ilariliusvaara@welho.com = <ilariliusvaara@welho.com>= on behalf of Ilari Liusvaara <ilariliusvaara@welho.com>=
Sent: Wednesday, July 18, 2018 2:56 AM
To: = Patton,Christopher J
Cc: tls@ietf.org
Subject: Re: = [TLS] Proposed changes to draft-ietf-tls-subcerts =

 <= /span>

O= n Wed, Jul 18, 2018 at 01:17:44AM +0000, Patton,Christopher J = wrote:
> Hi all,
>
>
> I've added a few pull = requests to the draft "Delegated credentials for TLS" that = address the proposals discussed at IETF.
>
> = Specifically:
>
>   *   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__g= ithub.com_tlswg_tls-2Dsubcerts_pull_8&d=3DDwIBaQ&c=3DpZJPUDQ3SB9J= plYbifm4nt2lEVG5pWx2KikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRr= iZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=3DJkn0aWEFHUhGyKTRFXHGPt7= fdDUvxeXGJQkwmPR2HdU&e=3D -- Creates a tighter binding of the DC = to the handshake parameters;
>   *   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__g= ithub.com_tlswg_tls-2Dsubcerts_pull_9&d=3DDwIBaQ&c=3DpZJPUDQ3SB9J= plYbifm4nt2lEVG5pWx2KikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRr= iZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=3DlsmtgnR-B-sA-BU_CcpbAtB= 7UC4Q0zyFqOLOGB3-FZM&e=3D -- Permits mandatory delegation-key = isolation, addresses the proposed"must-use-DC" TLS feature = extension;
>   *   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__g= ithub.com_tlswg_tls-2Dsubcerts_pull_10&d=3DDwIBaQ&c=3DpZJPUDQ3SB9= JplYbifm4nt2lEVG5pWx2KikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DR= riZv_awLgJt5QVpMsfl0UuiFCDoqBxniQnDZR8n5dA&s=3DQ1-PUQoj_LL4tFA4UPxTUi= iUNRYfsdAf9nhNCaAItZY&e=3D -- drops support for TLS 1.2.
> =
> Comments on these changes are welcome; feel free to chime in on = GitHub..

The way mandatory delegation-key usage is specified = seems to violate how
X.509 critical bit is supposed to work. The bit = is not supposed to alter
processing of recogized extensions, it is = only supposed to alter processing
of unrecognized extensions from = ignore to reject.

If you want to actually alter the processing to = require such
certificate to always only be used for DC, you need a = flag somewhere
else, which might be payload of the extension (and = that extension
should _also_ be marked critical to ensure that = clients that do not
understand DC do not accept = it).


-Ilari

------=_NextPart_000_18B4_01D41EC1.38E748F0-- From nobody Wed Jul 18 15:29:06 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 327B31311F5 for ; Wed, 18 Jul 2018 15:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zL4QzmUm4rI2 for ; Wed, 18 Jul 2018 15:29:01 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24D0A1311A8 for ; Wed, 18 Jul 2018 15:29:01 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id v17-v6so3275034qkb.11 for ; Wed, 18 Jul 2018 15:29:01 -0700 (PDT) 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=1aDDYebIXuSdy4Ij+W3j8kNlFLlytwLvy/G58OQoNQQ=; b=1elq2T7UYZftCnhwSMOcEHH6hTQnycbFXC00JFt1VJyJeT1Jcm2gkA6b3Yk0kF3Jzz weq/xY/WrNt0PqU5Fmc4mwldUWxzNAhI6+OJOgpkWTf03Bu51A7OqV8k5y0lcKFxv723 h/tFTYuGoa2rtK6K5x5oQDSgel47Bgos6fmVkQhp11nI5+mYCzsYm9hz4OVXsEC9hwHy AJ5ylrREMSm94gCrxMLJooYH/fhCWc1XY94iqUUVEFOQseml0V/fyy5eewuUhPexaEaC EIqgycSIsaezhhz2DL1NnKChYgyqnucQTzY8Ty7VV4PKb3AodyR9WhrDGySkbrppsSBN Hwuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1aDDYebIXuSdy4Ij+W3j8kNlFLlytwLvy/G58OQoNQQ=; b=o77hukjCnZum/5nacP7cg4ZKigvV484bRqvBl/H+lln0KIZaReL7W1bFE+tTH+rr0B Uy/yq2UALU52SYB3kGl4Jce+6KfO8ZdzlLTgUeW+DqKAxA0ah6NNgiELlR6D7xPt6PrX 8w2EEBVGvKxuB1WFh3yAf63hfOrEMpdVhVt1hBdfcQnDfAIDDdY76mHPsN8FfZcZiC/w dtHu0rvNl0n0miHZO159OUuHSNMkY45WE7MtpEzEyQVfP3i6AJQoPH+2VMHtRYib1wYz P597a1vb+O20/KySP9RsoXAcRJDK86DZso+INxpVYY30pokX/LxXBeaER73qZ/+TUJWO 37Jw== X-Gm-Message-State: AOUpUlELUEaZ6orzRRqUcvMnn9WvlQlIZNgONP25N5NI9Wp+/7ZxLivt QLx9p6MW8Ikr3hTrTfnsWi7jRaqkHyQsP1c6w9vt0uafD1A= X-Google-Smtp-Source: AAOMgpc+px1WfUJcbcYyqgjteslKiS9kY4LgJV7eye3cMBqAzN8WUjJJSFqk9S3zDaFvNkv2TPO+zdozTNJS32QCsSk= X-Received: by 2002:a37:a6c6:: with SMTP id p189-v6mr7263641qke.9.1531952939975; Wed, 18 Jul 2018 15:28:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2674:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 15:28:39 -0700 (PDT) From: Joseph Salowey Date: Wed, 18 Jul 2018 18:28:39 -0400 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000ccdd6805714d968e" Archived-At: Subject: [TLS] Update from side meeting on TLS DNSSEC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 22:29:04 -0000 --000000000000ccdd6805714d968e Content-Type: text/plain; charset="UTF-8" A group met this afternoon to discuss the TLS DNSSEC document. I want to thank the participants as I think it was a productive meeting. Here is chairs' summary of some of the important points of the discussion from notes from the meeting. The second section outlines some behavior that we need to clarify in the draft. THE NON-TLS BEHAVIOR Consider the following TLSA record: - domain example.com - record for key K1 - TTL of 3600s If I retrieved this record over DNS and then connected to example.com over TLS and it gave me key K2, which is WebPKI certified, but is different from K1 [0], then I would be required to terminate the connection per RFC6698 S 2.1.1. Similarly, if I later went to connect to example.com and it displayed K2, then assuming I still had the records in my cache, I would be required to terminate the connection. INTERACTION BETWEEN DNS TTLs AND THIS EXTENSION The current document is a bit unclear on the question of the behavior when these records are delivered via TLS as in this draft as-is, i.e., without pinning to the extension. Assume that my client is not configured to require this extension. It seems clear that if during the connection, the server negotiates the extension and provides this record but also key K2, I need to terminate the connection. It's not clear how this would happen other than misconfiguration; it wouldn't benefit an attacker. Now, consider what happens if I make an initial connection to the server and it provides K1, but immediately thereafter, I make a separate connection to the server and this time it does *not* negotiate the extension, and displays K2. What happens then? It seems to me that there are two answers: 1. Accept K2 (because it's WebPKI certified). 2. Reject K2 (because it doesn't match the TLSA record). Given that these have exactly the opposite effect, it seems like the first thing we need to do is clarify what the expected behavior. It seems like there are three things we could do: 1. Forbid clients from applying TLSA records received in one TLS connection to another TLS connection. This would seem to violate the spirit of "this is just another way to deliver DNS records". 2. Require/encourage (for some 2119 level) that clients apply TLSA records for as long as tehy remain valid. 3. Say nothing. We don't think (3) is acceptable. It's not OK for the servers not to have any idea how clients behave as it can break things. Specifically, if clients aren't forbidden to do this, some clients might which means servers have to expect it. We should start by addressing this issue. Moreover, it's pretty unobvious that things might behave this way. We need to decide on the behavior here. --000000000000ccdd6805714d968e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
A group met th= is afternoon to discuss the TLS DNSSEC document.=C2=A0 I=C2=A0
<= span style=3D"font-size:12.8px;text-decoration-style:initial;text-decoratio= n-color:initial;float:none;display:inline">want to thank the participants a= s I think it was a productive meeting.=C2=A0 Here=C2=A0
is chairs' summary of some of= the important points of the discussion from=C2=A0
notes from the meeting.=C2=A0 The seco= nd section outlines some behavior that=C2=A0
we need to clarify in the draft.
THE NON-TLS BEHAVIOR=C2=A0
Consider the following TLSA record:

=C2=A0=C2=A0=C2=A0 - domain=C2=A0example.com=C2=A0=C2=A0=C2=A0 - rec= ord for key K1
= =C2=A0=C2=A0=C2=A0 - TTL of 3600s

If I re= trieved this record over DNS and then connected to=C2=A0example.comover TLS and it gave me = key K2, which is WebPKI certified, but is
different from K1 [0], then I would be required t= o terminate the
= connection per RFC6698 S 2.1.1. Similarly, if I later went to connect
to=C2=A0= example.com= =C2=A0and it displayed K2, then assuming I still had th= e
records in my = cache, I would be required to terminate the connection.

INTERACTION BETWEEN DNS TTLs AND = THIS EXTENSION
The current document is a bit unclear on the question of the behavior=
when these records are delivered via=C2=A0TLS as in this draft as-is, i.e., without
pinning to the extension. Assume that my= =C2=A0client is not configured to= =C2=A0
require this=C2=A0extension.

It seems clear that if during the connec= tion, the server
negotiates the extension and provides this record but also key K2, I
need to terminate the= connection. It's not clear how this would happen
other than misconfiguration; it would= n't benefit an attacker.=C2=A0 Now,
consider what happens if I make an initial connecti= on to the server
and it provides K1, but immediately thereafter, I make a separateconnection to the server= and this time it does *not* negotiate the
extension, and displays K2.

What happens then? It seems to me that there are two answers:=

1. Accept K2 (because it's WebPKI ce= rtified).
2. Rej= ect K2 (because it doesn't match the TLSA record).

Given that these have exactly the opposite effect, it seems l= ike
the first th= ing we need to do is clarify what the expected behavior.
It seems like there are three thin= gs we could do:
1. Forbid clients from ap= plying TLSA records received in one TLS
=C2=A0=C2=A0 connection to another TLS connection. = This would seem to violate
=C2=A0=C2=A0 the spirit of "this is just another way to del= iver DNS records".

2. Require/encour= age (for some 2119 level) that clients apply TLSA
=C2=A0=C2=A0 records for as long as tehy = remain valid.

3. Say nothing.

We don't think (3) is acceptable. It's=C2=A0not OK for the servers not to=C2=A0
= have any idea how=C2=A0clients behave as it can break things. = Specifically,=C2=A0
if clients aren't f= orbidden to do this,=C2=A0some clients might which means=C2=A0
serve= rs have to expect it.=C2=A0 We=C2=A0should start by addressing this issue.=C2=A0=C2=A0
Moreover, it's pretty unobvious= =C2=A0that things might behave this= way. We=C2=A0
need to decide on the behavior here.=C2=A0

--000000000000ccdd6805714d968e-- From nobody Wed Jul 18 16:13:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 084EF13100D for ; Wed, 18 Jul 2018 16:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QA1nGfeI1pmY for ; Wed, 18 Jul 2018 16:13:24 -0700 (PDT) Received: from mail-it0-x242.google.com (mail-it0-x242.google.com [IPv6:2607:f8b0:4001:c0b::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1D3130FFC for ; Wed, 18 Jul 2018 16:13:24 -0700 (PDT) Received: by mail-it0-x242.google.com with SMTP id h2-v6so6581023itj.1 for ; Wed, 18 Jul 2018 16:13:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=KMzydkm1ytNWRAVy74rJkSBjxXJdwtZHeEv1jqb7AEg=; b=jcqnPWUk1dSpMLcaRP3wpYcR7IqaZENBSN+I94IwTGde7LbXrMzU2GSrcez5dQF5gz m5rRuKEYXUF70rAxf7adBJ+cMDkC3J8thxxDVAMwOHuWdMiT17ie1FCrBBGZqwa/u7p4 H9OYUeh36yF4rIAV86wPM6Itu6QccR15/kCJsyjxf/uS1uvHzlOFkjZgwp8RdS97nROd lXin+6pHgyRY5e9D239uwvsPyRG+Q70EhdpwMj5vuQEIPkg8PKEgEf8K1zNEuGivb2bj N7sNxU3p/BK6HzCvjHn4MuICZFhkrzLV5/XJvP2oAk2yTGQsVk05iecVVhYikquxwcWQ 6ZCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=KMzydkm1ytNWRAVy74rJkSBjxXJdwtZHeEv1jqb7AEg=; b=OZH+kloDvjlbNJaDLhfJa6aZsm2fyryMvQIIR57gfhJZEX/PR/ozjRh50B2ysjbWRc nnJCMo+LK8wqqzXCZ2khjLXo0E1UMa3QpoC/j1x21dEiABvJxCfWzqzCjhTv4v0eFsjj FD4N1ijBwUsjuSTcR0WKfV9tvPdBVT9sQn28miNNwR5Po+9rh0+4wv0Fb2U6Ppn2KsqE 2c7y3MCksFXqm3P1dRWcNck2PdY6yxTW2zq5WBynMgmKgYVkl0STKjPKoRYEEH6YrNkx oAT/LGNv3JT0lwC8lCCQcYyUlqrV+O/vRhlIsad0LvuhHvSzu97zApt+rIPlYA7Lpf/b WJXA== X-Gm-Message-State: AOUpUlHNMSLh8mwu3HPjm1jn4oFLtbK/z1rikUtw0GNQR9J4u1ggVK3o CrUU6mjSH7jMDYFQH6l9a45reAxwl14y3Ivuld0VxQ== X-Google-Smtp-Source: AAOMgpcWzl7CtI6DkpH6GhbTkseis+tqfDbqpaJ5YMvZ512uJuHCLuCzu6WuH4PuD6/cOMiyEryh4Y930Kxfvb4hB4Q= X-Received: by 2002:a24:6ccb:: with SMTP id w194-v6mr4006965itb.10.1531955603957; Wed, 18 Jul 2018 16:13:23 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 2002:a02:c502:0:0:0:0:0 with HTTP; Wed, 18 Jul 2018 16:12:53 -0700 (PDT) In-Reply-To: References: <153176915207.21824.6939177297174810137.idtracker@ietfa.amsl.com> From: Hugo Krawczyk Date: Wed, 18 Jul 2018 19:12:53 -0400 X-Google-Sender-Auth: kBfOk939RQbJmEo5m1lnns8WYjs Message-ID: To: Richard Barnes Cc: "" Content-Type: multipart/alternative; boundary="00000000000095eac905714e3536" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 18 Jul 2018 23:13:28 -0000 --00000000000095eac905714e3536 Content-Type: text/plain; charset="UTF-8" +1 for this work. If you are one of those that think, as I did 20 years ago, that password authentication is dying and practical replacements are just around the corner, do not support this document. Otherwise, please do. Asymmetric or augmented PAKE (aPAKE) protocols provide secure password authentication in the common client-server case (where the server stores a one-way mapping of the password) without relying on PKI - except during user/password registration. Passwords remain secure regardless of which middleboxes or endpoints spy into your decrypted TLS streams. The server never sees the password, not even during password registration. To see real deployment of such protocols, they need to be integrated with TLS which is what Barnes's draft facilitates. Not only this improve significantly the protection of passwords and password authentication, but aPAKE protocols also provide an hedge against PKI failures by enabling mutual client-server authentication without relying on regular server certificates. Hugo On Wed, Jul 18, 2018 at 1:18 PM, Richard Barnes wrote: > Hey TLS WG, > > In response to some of the list discussion since the last IETF, Owen and I > revised our TLS PAKE draft. In the current version, instead of binding to > a single PAKE (SPAKE2+), it defines a general container that can carry > messages for any PAKE that has the right shape. And we think that "right > shape" covers several current PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, ... > > The chairs have graciously allotted us 5min on the agenda for Thursday, > where I'd like to ask for the WG to adopt the document. So please speak up > if you think this is an interesting problem for the TLS WG to work on, and > if you think the approach in this document is a good starting point. Happy > for comments here or at the microphone on Thursday! > > Thanks, > --Richard > > > ---------- Forwarded message --------- > From: > Date: Mon, Jul 16, 2018 at 3:25 PM > Subject: New Version Notification for draft-barnes-tls-pake-04.txt > To: Richard Barnes , Owen Friel > > > > A new version of I-D, draft-barnes-tls-pake-04.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. > > Name: draft-barnes-tls-pake > Revision: 04 > Title: Usage of PAKE with TLS 1.3 > Document date: 2018-07-16 > Group: Individual Submission > Pages: 11 > URL: https://www.ietf.org/internet- > drafts/draft-barnes-tls-pake-04.txt > Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/ > Htmlized: https://tools.ietf.org/html/draft-barnes-tls-pake-04 > Htmlized: https://datatracker.ietf.org/ > doc/html/draft-barnes-tls-pake > Diff: https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-04 > > Abstract: > The pre-shared key mechanism available in TLS 1.3 is not suitable for > usage with low-entropy keys, such as passwords entered by users. > This document describes an extension that enables the use of > password-authenticated key exchange protocols with TLS 1.3. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --00000000000095eac905714e3536 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 for this work.

If you are one of those that think, as I di= d 20 years ago, that password authentication is dying and practical replace= ments are just around the corner, do not support this document. Otherwise, = please do.=C2=A0

Asymm= etric or augmented PAKE (aPAKE) protocols provide secure password authentic= ation in the common client-server case (where the server stores a one-way m= apping of the password) without relying on PKI - except during user/passwor= d registration. Passwords remain secure regardless of which middleboxes or = endpoints spy into your decrypted TLS streams.=C2=A0 The server never sees = the password, not even during password registration.=C2=A0

To see real deployment of such protoc= ols, they need to be integrated with TLS which is what Barnes's draft f= acilitates. Not only this improve significantly the protection of passwords= and password authentication, but aPAKE protocols also provide an hedge aga= inst PKI failures by enabling mutual client-server authentication without r= elying on regular server certificates.

Hugo


On Wed, Jul 18, 2018 at 1:18 P= M, Richard Barnes <rlb@ipv.sx> wrote:
Hey TLS WG,

In response= to some of the list discussion since the last IETF, Owen and I revised our= TLS PAKE draft.=C2=A0 In the current version, instead of binding to a sing= le PAKE (SPAKE2+), it defines a general container that can carry messages f= or any PAKE that has the right shape.=C2=A0 And we think that "right s= hape" covers several current PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, .= ..

The chairs have graciously allotted us 5min on = the agenda for Thursday, where I'd like to ask for the WG to adopt the = document.=C2=A0 So please speak up if you think this is an interesting prob= lem for the TLS WG to work on, and if you think the approach in this docume= nt is a good starting point.=C2=A0 Happy for comments here or at the microp= hone on Thursday!

Thanks,
--Richard<= br>


---------- Forwarded message ---------
From: <internet-drafts@= ietf.org>
Date: Mon, Jul 16, 2018 at 3:25 PM
Subject: N= ew Version Notification for draft-barnes-tls-pake-04.txt
To: Richard Bar= nes <rlb@ipv.sx>, Owen Friel <ofriel@cisco.com>



A new version of I-D, draft-barnes-tls-pake-04.txt
has been successfully submitted by Richard Barnes and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-barnes-tls-pake
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A004
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Usage of PAKE with TLS 1.3
Document date:=C2=A0 2018-07-16
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-barnes-tls-pake= -04.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http= s://datatracker.ietf.org/doc/draft-barnes-tls-pake/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tool= s.ietf.org/html/draft-barnes-tls-pake-04
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/html/draft-barnes-tls-pake
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-tls-pake-04=

Abstract:
=C2=A0 =C2=A0The pre-shared key mechanism available in TLS 1.3 is not suita= ble for
=C2=A0 =C2=A0usage with low-entropy keys, such as passwords entered by user= s.
=C2=A0 =C2=A0This document describes an extension that enables the use of =C2=A0 =C2=A0password-authenticated key exchange protocols with TLS 1.3.



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

The IETF Secretariat


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


--00000000000095eac905714e3536-- From nobody Wed Jul 18 17:12:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB091310D1 for ; Wed, 18 Jul 2018 17:12:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5vTLx7Jcb_h for ; Wed, 18 Jul 2018 17:12:50 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE80131207 for ; Wed, 18 Jul 2018 17:12:50 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id 3C8E229EB13; Wed, 18 Jul 2018 20:12:49 -0400 (EDT) Date: Wed, 18 Jul 2018 20:12:49 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180719001248.GD33554@straasha.imrryr.org> Reply-To: tls@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] Update from side meeting on TLS DNSSEC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 00:12:53 -0000 On Wed, Jul 18, 2018 at 06:28:39PM -0400, Joseph Salowey wrote: > THE NON-TLSA BEHAVIOR > Consider the following TLSA record: > > - domain example.com > - record for key K1 > - TTL of 3600s > > If I retrieved this record over DNS and then connected to example.com > over TLS and it gave me key K2, which is WebPKI certified, but is > different from K1 [0], then I would be required to terminate the > connection per RFC6698 S 2.1.1. Similarly, if I later went to connect > to example.com and it displayed K2, then assuming I still had the > records in my cache, I would be required to terminate the connection. TLSA record rollover requirements (and some suggested strategies) to effect non-disruptive key rollover are described in RFC7671 Section 8. The short version is that a correctly operated service will deploy dual TLSA records *ahead* of the introduction of a new certificate with K2. For example: _443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(K1)...> _443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(K2)...> the actual introduction of (K2) happens *after* any cached TLSA RRsets matching just K1 have expired. Such "caching" includes any delays in updating secondary nameservers + TTL of potentially stale data delivered by secondary servers. There are various ways of handling this. For example the TLSA RRset could include both a "3 1 1" record for the server key (KS) and a "2 1 1" for the issuer key (KI): _443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(KS)...> _443._tcp.www.example.com. IN TLSA 3 1 1 <...SHA2-256(KI)...> If the server key KS is updated to KS' from the *same* issuer CA, then the same TLSA RRset will still validate KS' via the shared issuer key KI. The hash matching KS can be replaced with the hash matching KS' during the key rollover without worrying about DNS caching delays. When the issuing CA switches keys from KI to KI', the server operator should obtain a new certificate for the *same* key KS, signed with KI'. And deploy that chain. This time it continues to be valid by matching KS. Again DNS caching can be ignored and the TLSA record update to match KI' concurrently with the issuer key rollover. It may be useful to write a new DANE operational RFC, covering some of the insights gained since the publication of 7671 section 8. > It seems clear that if during the connection, the server negotiates the > extension and provides this record but also key K2, I need to terminate > the connection. Yes. > Now, consider what happens if I make an initial connection to the server > and it provides K1, but immediately thereafter, I make a separate connection > to the server and this time it does *not* negotiate the extension, and > displays K2. [ The subtext here is that the client is doing local DNS caching (normal DNS no pinning) based on the DNS TTL. So it already knows the TLSA records, and does not even need to ask for the extension. ] If the TTL on the previously provided TLSA RRs has not expired, the client is free to apply those TLSA records, exactly as it would had it (and it is free to try) obtained them via DNS rather than via the extension. > What happens then? It seems to me that there are two answers: > > 1. Accept K2 (because it's WebPKI certified). There's little point in doing that. The client could perhaps proceed after a user dialogue, or an audit event, on the grounds that some attackers would hesitate at tamper-evident malfeasance, but that's rather minimal benefit for the cost of doing DANE. So the client could continue as a matter of local policy, but generally should not. > 2. Reject K2 (because it doesn't match the TLSA record). This is the expected behaviour with unexpired TLSA records matching only K1. > It seems like there are three things we could do: > > 1. Forbid clients from applying TLSA records received in one TLS > connection to another TLS connection. This would seem to violate > the spirit of "this is just another way to deliver DNS records". Yes, the violation of expectations is quite clear. The client must be at liberty to cache. The TLSA record publisher gets to choose suitably short TTLs, which the TLS server could further reduce at its discretion (TTLs are of course not DNSSEC signed, only an uppper bound on the TTL is covered by the RRSIG). > 2. Require/encourage (for some 2119 level) that clients apply TLSA > records for as long as tehy remain valid. The client may of course, at its discretion, cap the TTL it obtains from DNS at a maximum value lower than provided by the server. A client that does not cache TLSA records at all, effectively caps the TTL at 0. Clients are not obligated to cache, but may do so. Caching amortizes the overhead of receiving and processing the extension data on an initial connection over multiple subsequent connections. So caching should be encouraged, but is not required. > 3. Say nothing. > > We don't think (3) is acceptable. It's not OK for the servers not to > have any idea how clients behave as it can break things. Specifically, > if clients aren't forbidden to do this, some clients might, which means > servers have to expect it. We should start by addressing this issue. > Moreover, it's pretty unobvious that things might behave this way. We > need to decide on the behavior here. Since clients are in any case free to obtain the TLSA records via DNS, the behaviour of clients when records are obtained via the extension needs to as much as possible match the behaviour of clients that manage to obtaint the same records directly via DNS. The only difference (already noted in the draft) is that delivery via the extension guards against UKS attacks. This should be clear upon reflection, and I don't see that there's anything to be decided. But to the extent that what's clear upon relfection is not always clear to the casual reader, some text to make the unavoidable consequences also obvious may be appropriate. In summary, clients are free to cache DNS data (received via any suitable transport) up to the received TTL. They can act on cached data as though it were just freshly received. -- Viktor. From nobody Wed Jul 18 20:13:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3092C130EBD for ; Wed, 18 Jul 2018 20:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZqCyJkUp3KeM for ; Wed, 18 Jul 2018 20:13:20 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44EDD130E9F for ; Wed, 18 Jul 2018 20:13:20 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 860BE5000061E; Wed, 18 Jul 2018 20:13:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=hThMoWlQvF3gQt gGKB9AUY4+QIo=; b=L+/RA/ptWrWb1mocubL7nlIyWY2fb8ls+ehwEeqDhcDEnt i2dF+G8BNx4uTXb8QRBG3yWVnSvMG+lg2iPiO+NsRYOYyhpqBokzFNbxbBYwJeEl IsqzVN/ixm7dJ5cOZFs21Ch1aPNWIoh65/8YYSVz/FzIXf9hLA8mWRnGQu0L8= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 37F985000061D; Wed, 18 Jul 2018 20:13:18 -0700 (PDT) Date: Wed, 18 Jul 2018 22:13:16 -0500 From: Nico Williams To: Eric Rescorla Cc: "" Message-ID: <20180719031314.GI9723@localhost> References: <20180718023039.GV33554@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 03:13:22 -0000 On Wed, Jul 18, 2018 at 01:54:09AM -0700, Eric Rescorla wrote: > On Tue, Jul 17, 2018 at 7:30 PM, Viktor Dukhovni > wrote: > > > > c. Testing is not a good fit at this layer, all that's > > pinned is the ability to deliver the extension, after a > > previous connection delivered DANE TLSA records and a > > non-zero extension support lifetime. There is no TLS-layer > > mechanism for the client to inform servers that don't > > offer the extension that this extension was expected > > while continuing the connection. The closest we get is > > the TLS 1.3 missing_extension(109) alert, which does not > > carry the id of the mission extension, and is a failure > > alert. Out-of-band notification would require HTTP > > support in applications that can't generally be expected > > to include an HTTP implementation. > > > > To the extent to which this is true, it's an argument that one should be > pinning at a different layer. Whichever layer the pinning is to be done at, the thing to pin, and for how long, all need to be transported, and since that thing is in TLS, so should the "for how long". Nico -- From nobody Wed Jul 18 20:23:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D60130E9F for ; Wed, 18 Jul 2018 20:23:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LpSHEKSuGUt for ; Wed, 18 Jul 2018 20:23:52 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1D28130E51 for ; Wed, 18 Jul 2018 20:23:52 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 787E250000620; Wed, 18 Jul 2018 20:23:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LWDCjJ5kNAlkUV QatzWCUbZpTfg=; b=CqTJPrShWzxBoVS7DGcuWyCM/2PHIpfSlnpbJ/QR2fr0TI LY3Vpy2dUvv1w4h3PRUzu8Wwb2ivEBrKBEMm75p4VEyIbeE5MkXelxWM9lZaYIZw aIdTOCgHF1CvbSxbik0Pxbm4pOnbBMcrhGdMBs2VTpy2QQrN6dXpyPCAVEG8I= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 2EB275000061D; Wed, 18 Jul 2018 20:23:51 -0700 (PDT) Date: Wed, 18 Jul 2018 22:23:49 -0500 From: Nico Williams To: Shumon Huque Cc: TLS WG Message-ID: <20180719032347.GJ9723@localhost> References: <20180718023039.GV33554@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 03:23:55 -0000 On Wed, Jul 18, 2018 at 08:41:59AM -0400, Shumon Huque wrote: > At yesterday's WG meeting, Sam Weiler suggested that the pinning > information could be conveyed via the DNS. That way you would not need new > holes/fields in the TLS extension. Paul said it doesn't work. But Willem > Toorop and I discussed it after the meeting, and think that it does. I agree that it _could_ be done with a DNS RR. However, that has two negative effects: 1) it will bloat the extension's payload more than the two bytes we're asking for, 2) it complicates deployment / the operator's life. With a pin TTL in the extension the server operator can change it at any time without further ado -- it's just a config file setting. With a pin TTL in a DNS RR the server operator has to make a zone file update. That could be easy or not -- it varies. > This could also express a generic DANE pinning capability that is not tied > only to a TLS channel. That's more like the other flavors of pinning we've been told have rougher operations characteristics. It's certainly true that we could specify and implement such a thing, and that it would be useful for some applications. However, it wouldn't be as convenient as just the extension pinning in this case. For example, with pinning to the extension + DoE, a server could implement the extension asynchronously from deploying DANE. In fact, it could just be enabled by default, and always send DoE when you don't have DANE deployed. And then the moment you deploy DANE, presto, you're protected. And if you want to turn off pinning? Just edit the server's configuration file -- no need to go update the zone(s). We should always look to make deployment easier, and extension pinning does that more than a DANE pin DNS RR type would. Surely we want our protocols to be deployable. Nico -- From nobody Thu Jul 19 03:28:01 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065C112777C for ; Thu, 19 Jul 2018 03:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYYedL8lCWcf for ; Thu, 19 Jul 2018 03:27:56 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [62.96.220.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 540BA126BED for ; Thu, 19 Jul 2018 03:27:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id CF3E4201C4 for ; Thu, 19 Jul 2018 14:27:38 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4dEANugXHqix for ; Thu, 19 Jul 2018 14:27:38 +0200 (CEST) Received: from mail-essen-01.secunet.de (mail-essen-01.secunet.de [10.53.40.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by a.mx.secunet.com (Postfix) with ESMTPS id 8577F201BE for ; Thu, 19 Jul 2018 14:27:38 +0200 (CEST) Received: from [10.208.1.212] (10.208.1.212) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.399.0; Thu, 19 Jul 2018 12:27:53 +0200 To: References: <1531903926363.56642@cs.auckland.ac.nz> <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> <7098419E-6F96-4398-A736-38C2F99E11FF@ll.mit.edu> <132F1996-0866-4776-9F91-C80964A8C90B@ll.mit.edu> From: Johannes Merkle Openpgp: preference=signencrypt Message-ID: <1c28fd3f-aac6-31ad-54af-425030612b3c@secunet.com> Date: Thu, 19 Jul 2018 12:27:52 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <132F1996-0866-4776-9F91-C80964A8C90B@ll.mit.edu> Content-Type: text/plain; charset="utf-8" Content-Language: de-DE Content-Transfer-Encoding: 8bit X-G-Data-MailSecurity-for-Exchange-State: 0 X-G-Data-MailSecurity-for-Exchange-Error: 0 X-G-Data-MailSecurity-for-Exchange-Sender: 23 X-G-Data-MailSecurity-for-Exchange-Server: d65e63f7-5c15-413f-8f63-c0d707471c93 X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 X-G-Data-MailSecurity-for-Exchange-Guid: D91350CB-7C9A-4E21-9196-93FD5D503726 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 10:27:59 -0000 >> Code points for pre-1.3 were assigned, and they are invalid for TLS 1.3. Those “you should not send these for 1.3” could be re-used for TLS 1.3, if that was desired. > > Yes this makes sense. And I think that they should, documented as something other than “Recommended”. > I still don't get it. If the existing code points are re-used, the TLS 1.3 standard is violated. Johannes From nobody Thu Jul 19 04:18:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1F1B130E2F for ; Thu, 19 Jul 2018 04:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJnoU_dK9FNQ for ; Thu, 19 Jul 2018 04:18:24 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 1D794124D68 for ; Thu, 19 Jul 2018 04:18:23 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w6JBIM8D047275; Thu, 19 Jul 2018 07:18:22 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Johannes Merkle CC: "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowA///OLCuAAEQ9AIABKxEAgAAnlQCAAF9LAP//x8YAgAACGoCAAABxAIAAR84AgAEUFQCAAA4bgA== Date: Thu, 19 Jul 2018 11:18:21 +0000 Message-ID: <83F53ABE-C723-4EF9-A25C-3EECF0A96E12@ll.mit.edu> References: <1531903926363.56642@cs.auckland.ac.nz> <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> <7098419E-6F96-4398-A736-38C2F99E11FF@ll.mit.edu> <132F1996-0866-4776-9F91-C80964A8C90B@ll.mit.edu> <1c28fd3f-aac6-31ad-54af-425030612b3c@secunet.com> In-Reply-To: <1c28fd3f-aac6-31ad-54af-425030612b3c@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-5D63CC02-8FE4-4F93-8FA7-FD1E9BB72F49"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190123 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 11:18:27 -0000 --Apple-Mail-5D63CC02-8FE4-4F93-8FA7-FD1E9BB72F49 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 U0hPVUxEIE5PVCB3b3VsZCBwcm9iYWJseSBiZSBmaW5lLiBNVVNUIE5PVCBpcyB0b28gc3Ryb25n LCBhbmQgcHJvYmFibHkgbmVlZHMgcmV2aXNpdGluZy4NCg0KUmVnYXJkcywNClVyaQ0KDQpTZW50 IGZyb20gbXkgaVBob25lDQoNCk9uIEp1bCAxOSwgMjAxOCwgYXQgMDY6MzIsIEpvaGFubmVzIE1l cmtsZSA8am9oYW5uZXMubWVya2xlQHNlY3VuZXQuY29tPiB3cm90ZToNCg0KPj4+IENvZGUgcG9p bnRzIGZvciBwcmUtMS4zIHdlcmUgYXNzaWduZWQsIGFuZCB0aGV5IGFyZSBpbnZhbGlkIGZvciBU TFMgMS4zLiAgVGhvc2Ug4oCceW91IHNob3VsZCBub3Qgc2VuZCB0aGVzZSBmb3IgMS4z4oCdIGNv dWxkIGJlIHJlLXVzZWQgZm9yIFRMUyAxLjMsIGlmIHRoYXQgd2FzIGRlc2lyZWQuDQo+PiANCj4+ IFllcyB0aGlzIG1ha2VzIHNlbnNlLiBBbmQgSSB0aGluayB0aGF0IHRoZXkgc2hvdWxkLCBkb2N1 bWVudGVkIGFzIHNvbWV0aGluZyBvdGhlciB0aGFuIOKAnFJlY29tbWVuZGVk4oCdLg0KPj4gDQo+ IA0KPiBJIHN0aWxsIGRvbid0IGdldCBpdC4gSWYgdGhlIGV4aXN0aW5nIGNvZGUgcG9pbnRzIGFy ZSByZS11c2VkLCB0aGUgVExTIDEuMyBzdGFuZGFyZCBpcyB2aW9sYXRlZC4NCj4gDQo+IEpvaGFu bmVzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBUTFMgbWFpbGluZyBsaXN0DQo+IFRMU0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K --Apple-Mail-5D63CC02-8FE4-4F93-8FA7-FD1E9BB72F49 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTgwNzE5MTExODIxWjAjBgkqhkiG9w0BCQQxFgQUwzNH686jXN0qITPqPgze8TEDIDYwbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBAAv9vCbr3dKjnI940LfTKbQ6MI5+Fjf33Xvl9TD9XM2VX+TxoyMMD5Gj1hu10rM6 MO3e5DKQHVC4hzOWWhdH51Kvg4mBDQT70rMtSPcxhitLPGEp/PxciVX5x3EkkzcZSuIfFHi2GfFU vfp4+hi1pTBMQVOgyvNLh66TkS/frRIQnn9+ZCaqCwqYhfTReeQsspeL281t3ES78eN7fpsmXDrY AfIFWLQDxCRY5c41UCZmmmpoCY1NxVTNvOeGyw8a7VfS+jV5MFpfuaIrK4zPs21iDNdd+ShZj/c8 TUhQR47LsFrSr2oMMlzOwkYpResOQt/bHbHVKj5XHZdJPL2pQugAAAAAAAA= --Apple-Mail-5D63CC02-8FE4-4F93-8FA7-FD1E9BB72F49-- From nobody Thu Jul 19 06:18:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 163E0130DD8 for ; Thu, 19 Jul 2018 06:18:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi6GsUvvZunc for ; Thu, 19 Jul 2018 06:18:32 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B96A130DCE for ; Thu, 19 Jul 2018 06:18:32 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6JDH0YX009128; Thu, 19 Jul 2018 14:18:31 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=sglaNZ0ZwWZHs1oBXsO1kY1sW3ngo8wHwgSBZk2s9BU=; b=Kw6b8aW14gZRcOiFT4DiYQ42uCCl0SbLQcGAcz5MAqC5G0VD1C1/6KIlj3XU7yWRATW2 plnSBUnUWtZoI8V296D9thoQz5vpIyABLfoDzXZN7g2JHlBGnkbit48lqZM40tuWCptf M8GcqB0bgKVDkhU9qCyADbCrlpmXlnTW0P9k2neh4hXhHgBEKsTDrt59ZFfBZNokPVgf QN4vOVhj4tOAL77HT5ilEjbBn8H9bHGKMDSMw2eF320sJLElIZ7SKjZQ43IdM2UfKuZ7 8H9YLTG45a5QMSlHeqWKXrcuhkKBlGcF8xuHMxnO710MHac3wXbga0kcRgWrzRCNlUyj /Q== Received: from prod-mail-ppoint3 (a96-6-114-86.deploy.static.akamaitechnologies.com [96.6.114.86] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2k9ps756ee-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Jul 2018 14:18:31 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6JD5In6010875; Thu, 19 Jul 2018 09:18:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint3.akamai.com with ESMTP id 2k7cgw9msb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 19 Jul 2018 09:18:29 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 19 Jul 2018 09:18:28 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Thu, 19 Jul 2018 09:18:28 -0400 From: "Salz, Rich" To: Johannes Merkle , "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowA///OLCuAAEQ9AIABKxEAgAAnlQCAAF9LAP//x8YAgAACGoCAAABxAIAAR84AgAEUFQD//+yaAA== Date: Thu, 19 Jul 2018 13:18:27 +0000 Message-ID: References: <1531903926363.56642@cs.auckland.ac.nz> <2386527.GkuWJfRkxc@pintsize.usersys.redhat.com> <1980F0B3-65DB-48F7-B898-3389731C8125@akamai.com> <7098419E-6F96-4398-A736-38C2F99E11FF@ll.mit.edu> <132F1996-0866-4776-9F91-C80964A8C90B@ll.mit.edu> <1c28fd3f-aac6-31ad-54af-425030612b3c@secunet.com> In-Reply-To: <1c28fd3f-aac6-31ad-54af-425030612b3c@secunet.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.45.235] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=474 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190141 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=384 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190143 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 13:18:34 -0000 PiAgICBJIHN0aWxsIGRvbid0IGdldCBpdC4gSWYgdGhlIGV4aXN0aW5nIGNvZGUgcG9pbnRzIGFy ZSByZS11c2VkLCB0aGUgVExTIDEuMyBzdGFuZGFyZCBpcyB2aW9sYXRlZC4NCiAgDQpSaWdodC4g IFNvIGEgZG9jdW1lbnQgd2lsbCBoYXZlIHRvIGJlIHdyaXR0ZW4gdGhhdCB1cGRhdGVzIHRoZSBS RkMgdG8gdXNlIHRoZW0uICBPciwgZ28gZm9yIG90aGVyIGNvZGVwb2ludHMuDQoNCkVpdGhlciB3 YXksIEkgdGhpbmsgaXQgd2lsbCBiZSBhbiB1cGhpbGwgc3RydWdnbGUgdG8gY29udmluY2UgdGhl IFdHLCB3aG8gd291bGQgcHJvYmFibHkgZGVmZXIgdG8gQ0ZSRyBzbyBjb252aW5jZSB0aGVtIGFz IHdlbGwsIHRoYXQgQnJhaW5wb29sIGN1cnZlcyBhcmUgbmVjZXNzYXJ5IGZvciBUTFMgMS4zLiAg anVzdCBzb21lIGFkdmljZS4NCg0K From nobody Thu Jul 19 07:10:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A68130F72 for ; Thu, 19 Jul 2018 07:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=digicert.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1l_hAM7HNc4 for ; Thu, 19 Jul 2018 07:10:15 -0700 (PDT) Received: from mail1.bemta24.messagelabs.com (mail1.bemta24.messagelabs.com [67.219.250.210]) (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 EB197130F06 for ; Thu, 19 Jul 2018 07:10:14 -0700 (PDT) Received: from [67.219.251.52] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-3.bemta.az-c.us-west-2.aws.symcld.net id 4D/D9-01615-5CB905B5; Thu, 19 Jul 2018 14:10:13 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTf0wbZRjHfXvX3m1QcxwwHiszWN2yQa6hGLG K6P7A2GkwRP8SXOZBD9pYDtIrPw1mKkECcyK0jHURGIMtENhcxUAmDFIYhHYZk2XLts4SsrlI QWQz0aAI3vVuKPfHk8/7/T7v8zzvm/dIjD5F6Eiu0sk5eNau1+zEbyUNxjMTJ3PyUodXkenn8 HHM5D6WaXo024AOYOah1gXC3N29pjK3XPDgOViu2sbnl1R+qLYeHavDS5fPoMr50/uOoPETqA HtJHHqKAZL/k1CWtBUkwo6hkZV8mIegbdnHm9AO0gNlQo3R6dVEsdRb0LX5gwmMUY9By0bdwm JY6l34Ua4Xsl5D75v6cJlfgVCtT0Rxqk9sBjqRhJrqUPQHHyglpvdRjDk8mokY4dY6O6nAbXE iNoFf/r7VXKzBLhzvyPCQMXBwo8BjczxsHhvQ8n/AL753afoehg8vUTIvBvmOhojZwZqjICBj nuKwcCq243JnA2djetqOSmI4Jfab5FsJEPQu6J0tsPm3LSi14B/dhyX+Rno+3JB4UsYnPv1fZ kTof5rv9IsqIH2eZ3ENGUBV59P04RSPP87nEfsjVGdCM66BjBP5JpiYObEfVxOyoXm79yYzMn gHggregqcObUk6qTI+2Hqun67TIj8KgxaZPVZcDUuEDKnQ93Vh5pOFNWHTPkOW5HVWcza7Iwx NZUxGtMY4wsmxvhiuoGtZgoMZQJTwQlOJs3AVggGoaq4wG4x8JzTi8Rn+YT4DaM1n8WHniJV+ nht9ew7efST+SWWKisrWA87yuyc4EOJJKkH7YgnJ4+OcXBFXGWhzS6+7cc2kNH6OG1AsrVCKV ss2Ipky4/eIFd6m5sxcjLkEuO1SFy57Bbj+m9ipHG+hOd0CdpWaTMlbbaW8VulH/85c2i3Lla LxGHp6FLOUWxzbvfDKIFE+litU6oSbeOdWxOExeFU4nBPf5wtDedk/7N0R5D3WMkPr5f2X5z0 WE/+dDjQvdFeM1wTs/j8/gufXT1U98UVV6FRaJje80fC58GMrB6i+qzw8tTBv+nEwqSRLHPRV yH+pYy2t44b9x5gPpqgHkSxE5tMeRuaaaNfK8xcC/+Vtrdu+Z/ZpU+mOnvPZ2HmkdxwMLPrVi ijmnm7jS+vqQ3occHKGpMxh8D+CxbLS0k0BAAA X-Env-Sender: tim.hollebeek@digicert.com X-Msg-Ref: server-12.tower-364.messagelabs.com!1532009409!1698591!1 X-Originating-IP: [216.32.180.21] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.9.15; banners=-,-,- X-VirusChecked: Checked Received: (qmail 20043 invoked from network); 19 Jul 2018 14:10:10 -0000 Received: from mail-sn1nam02lp0021.outbound.protection.outlook.com (HELO NAM02-SN1-obe.outbound.protection.outlook.com) (216.32.180.21) by server-12.tower-364.messagelabs.com with AES256-SHA256 encrypted SMTP; 19 Jul 2018 14:10:10 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=digicert.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=eviE6uAihGmGgxnf4NQEA+c61NV9HNxkvEEpl1kT6/Q=; b=g3j0Hxb+04+YFKvgDZxBGq2FUlby6MqQBwdEFfzv0Hov3iNdy85uCT1+bUdOCcEnIxmUlT5SJrg2HCi6ViEJZRlhPSulbazprHnKa4sW73hC5u+DWbbyWXbv9Ltx2TnWGMt+krlaCPlNc6N0Gqj4d+mu4jMGwDIo/te8t+ORLcE= Received: from BN6PR14MB1106.namprd14.prod.outlook.com (10.173.161.15) by BN6PR14MB1730.namprd14.prod.outlook.com (10.171.176.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Thu, 19 Jul 2018 14:10:08 +0000 Received: from BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::f861:ae59:39b3:8960]) by BN6PR14MB1106.namprd14.prod.outlook.com ([fe80::f861:ae59:39b3:8960%6]) with mapi id 15.20.0952.021; Thu, 19 Jul 2018 14:10:08 +0000 From: Tim Hollebeek To: Hugo Krawczyk , Richard Barnes CC: "" Thread-Topic: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt Thread-Index: AQHUHrt4BgTH4X4ju02o9CBvtNNX4KSVnD6AgAD6YJA= Date: Thu, 19 Jul 2018 14:10:08 +0000 Message-ID: References: <153176915207.21824.6939177297174810137.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.155.200] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR14MB1730; 6:suC4tZGPqC9ORWZ8wOHTo+uu3j2XgChfcr1Q5VjjZ8j4ofMAzeHTeeEktP1n8oIRJ7iFA7WIdUF+COVaiJDEgm41F0ALM9zwdy0ZGGAL7nJYgknZHMHrQvYgQO2OHp1jGv1NJYBhe90TZbVARLOycswIEo5I99n/4LDfxeCzyAbKAsUUuVRE5NmeS6QeLd3soBwRkW+tAf/aOtYpz3zbUynwQyq0SW8NhNi886qKomJAv431u11gUB6kAChj0W1ZqbN0W2KUf6bygdfVkmrdDc4wzHQX94Ajmc69EzY4egoW3sLWxcJf++R1I5MUVXEJxBO5HtHGFC3GvfbWKZgKDwCvXbg435QVUnB4TlkrKZEymtbbZj6xLWO5bulVTH35/UFX8aFhrm02b0hKMEiF6/19xsXeVhaK+NQzoh8djCivih8LVFb613DzD9iPH0sWb2cHzbqs0WRLg+mycELkxQ==; 5:ZEI4KlZZe3BWIGQg3qlRCnOJ0XWSDvCE6bofJQhHWw/Ualv9TBhT5y/pmEYh4SO0g846aQx2Wa527CIp4iM9UPCY/AEYjKmIxvMb713RoK5n0MMqOfbctKzg/qsROselmNFyN73fe08y1uqMK/FTZR2reVKj5x/PNa31OkT84xE=; 7:yoDUax/mle16RamRFcmIalMFADfrHKaAf+wK9kQv5dbAYcdWkV4sReHQGWL5Hsk6yKyhbKAzEBJfkkpH8nT75g0Tp3sgu6VS82BoUGY5n7uMuUx0O0hyav56slGja4yF7miuIue8p73UPL7mGuaUlb6h7IaZ4TUTnrltVURQEV/w4bk/CJ/pzwLyYziU9i+Q3Mj7kXeh1W6L86V8x3xwWjDixp8/MMhpfgyRrwUqIZdKwkUhrVElMgPRciYVJl7s x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a7ac8537-0384-47e3-b863-08d5ed815573 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(49563074)(7193020); SRVR:BN6PR14MB1730; x-ms-traffictypediagnostic: BN6PR14MB1730: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(120809045254105)(95692535739014)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:BN6PR14MB1730; BCL:0; PCL:0; RULEID:; SRVR:BN6PR14MB1730; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(136003)(346002)(376002)(189003)(199004)(22974007)(102836004)(99286004)(97736004)(74316002)(256004)(5250100002)(11346002)(186003)(44832011)(26005)(476003)(790700001)(68736007)(486006)(7736002)(14444005)(316002)(110136005)(446003)(53936002)(7110500001)(4326008)(3846002)(6116002)(53386004)(478600001)(606006)(2420400007)(966005)(25786009)(15650500001)(14454004)(6246003)(229853002)(2906002)(10710500007)(86362001)(81166006)(106356001)(2900100001)(551544002)(105586002)(5660300001)(81156014)(8936002)(8676002)(76176011)(6436002)(9686003)(6306002)(99936001)(53546011)(7696005)(236005)(66066001)(55016002)(14971765001)(54896002)(33656002)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR14MB1730; H:BN6PR14MB1106.namprd14.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: digicert.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: ziUnL8tyQDhb2Ht6SZtTVEqyih3IUBQQRfs4BQvnTibHZOoF3FxUX/pC0KCf+WrmCfdlKOVb47ibKAWn05fdXh9jB3ABl+x09Y/9/D+05on0PVLYHtq+CpmGRx0EJgJ3HgFsPlbfvEfA/Tldt7Cjz0RT7rQMhcvUowDw+nwLOOQLDzFDletCNNs8PoBcT+7kgcmS4K8FcFkjtaS2NEku6KuTvZe0ZvqBjoPsnKlI7rSq8PDVqt9x6IsJZm3iGeiCOPKnglr3HFauSW1OGzqCoy9z61Ab2XBuGTcM7gUT3BzDUat3PZrBO8hTexrhSaO9V3WqGyuzsgo0dJJfpR50TCFNoLfk2dTO2VP36d3hdfY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=2.16.840.1.101.3.4.2.1; boundary="----=_NextPart_000_0085_01D41F48.A59C0940" MIME-Version: 1.0 X-OriginatorOrg: digicert.com X-MS-Exchange-CrossTenant-Network-Message-Id: a7ac8537-0384-47e3-b863-08d5ed815573 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 14:10:08.1910 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: cf813fa1-bde5-4e75-9479-f6aaa8b1f284 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR14MB1730 Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 14:10:23 -0000 ------=_NextPart_000_0085_01D41F48.A59C0940 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0086_01D41F48.A59C0940" ------=_NextPart_001_0086_01D41F48.A59C0940 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Unfortunately, I haven=E2=80=99t had time to review the document, but +1 = for interesting problem, and +1 for anything Richard writes as a good = starting point, even if I haven=E2=80=99t read it. =20 -Tim =20 From: TLS On Behalf Of Hugo Krawczyk Sent: Wednesday, July 18, 2018 7:13 PM To: Richard Barnes Cc: Subject: Re: [TLS] Fwd: New Version Notification for = draft-barnes-tls-pake-04.txt =20 +1 for this work. =20 If you are one of those that think, as I did 20 years ago, that password = authentication is dying and practical replacements are just around the = corner, do not support this document. Otherwise, please do.=20 =20 Asymmetric or augmented PAKE (aPAKE) protocols provide secure password = authentication in the common client-server case (where the server stores = a one-way mapping of the password) without relying on PKI - except = during user/password registration. Passwords remain secure regardless of = which middleboxes or endpoints spy into your decrypted TLS streams. The = server never sees the password, not even during password registration.=20 =20 To see real deployment of such protocols, they need to be integrated = with TLS which is what Barnes's draft facilitates. Not only this improve = significantly the protection of passwords and password authentication, = but aPAKE protocols also provide an hedge against PKI failures by = enabling mutual client-server authentication without relying on regular = server certificates. =20 Hugo =20 =20 On Wed, Jul 18, 2018 at 1:18 PM, Richard Barnes > wrote: Hey TLS WG, =20 In response to some of the list discussion since the last IETF, Owen and = I revised our TLS PAKE draft. In the current version, instead of = binding to a single PAKE (SPAKE2+), it defines a general container that = can carry messages for any PAKE that has the right shape. And we think = that "right shape" covers several current PAKEs: SPAKE2+, Dragonfly, = SRP, OPAQUE, .... =20 The chairs have graciously allotted us 5min on the agenda for Thursday, = where I'd like to ask for the WG to adopt the document. So please speak = up if you think this is an interesting problem for the TLS WG to work = on, and if you think the approach in this document is a good starting = point. Happy for comments here or at the microphone on Thursday! =20 Thanks, --Richard =20 =20 ---------- Forwarded message --------- From: > Date: Mon, Jul 16, 2018 at 3:25 PM Subject: New Version Notification for draft-barnes-tls-pake-04.txt To: Richard Barnes >, Owen Friel = > A new version of I-D, draft-barnes-tls-pake-04.txt has been successfully submitted by Richard Barnes and posted to the IETF repository. Name: draft-barnes-tls-pake Revision: 04 Title: Usage of PAKE with TLS 1.3 Document date: 2018-07-16 Group: Individual Submission Pages: 11 URL: = https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.txt Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/ Htmlized: https://tools.ietf.org/html/draft-barnes-tls-pake-04 Htmlized: = https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-tls-pake-04 Abstract: The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3. Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at tools.ietf.org = . The IETF Secretariat _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls =20 ------=_NextPart_001_0086_01D41F48.A59C0940 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Unfortunately, I haven=E2=80=99t had time to review = the document, but +1 for interesting problem, and +1 for anything = Richard writes as a good starting point, even if I haven=E2=80=99t read = it.

 

-Tim

 

From: TLS = <tls-bounces@ietf.org> On Behalf Of Hugo = Krawczyk
Sent: Wednesday, July 18, 2018 7:13 PM
To: = Richard Barnes <rlb@ipv.sx>
Cc: <tls@ietf.org> = <tls@ietf.org>
Subject: Re: [TLS] Fwd: New Version = Notification for = draft-barnes-tls-pake-04.txt

 

+1 for this = work.

 

If you are one = of those that think, as I did 20 years ago, that password authentication = is dying and practical replacements are just around the corner, do not = support this document. Otherwise, please = do. 

 

Asymmetric or = augmented PAKE (aPAKE) protocols provide secure password authentication = in the common client-server case (where the server stores a one-way = mapping of the password) without relying on PKI - except during = user/password registration. Passwords remain secure regardless of which = middleboxes or endpoints spy into your decrypted TLS streams.  The = server never sees the password, not even during password = registration. 

 

To see real = deployment of such protocols, they need to be integrated with TLS which = is what Barnes's draft facilitates. Not only this improve significantly = the protection of passwords and password authentication, but aPAKE = protocols also provide an hedge against PKI failures by enabling mutual = client-server authentication without relying on regular server = certificates.

 

Hugo=

 

 

On Wed, = Jul 18, 2018 at 1:18 PM, Richard Barnes <rlb@ipv.sx> = wrote:

Hey TLS WG,

 

In response to some of the list discussion since the = last IETF, Owen and I revised our TLS PAKE draft.  In the current = version, instead of binding to a single PAKE (SPAKE2+), it defines a = general container that can carry messages for any PAKE that has the = right shape.  And we think that "right shape" covers = several current PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, = ....

 

The chairs have graciously allotted us 5min on the = agenda for Thursday, where I'd like to ask for the WG to adopt the = document.  So please speak up if you think this is an interesting = problem for the TLS WG to work on, and if you think the approach in this = document is a good starting point.  Happy for comments here or at = the microphone on Thursday!

 

Thanks,

--Richard

 

 

---------- Forwarded message ---------
From: <internet-drafts@ietf.org>
Date: Mon, Jul 16, = 2018 at 3:25 PM
Subject: New Version Notification for = draft-barnes-tls-pake-04.txt
To: Richard Barnes <rlb@ipv.sx>, Owen Friel <ofriel@cisco.com>




A new = version of I-D, draft-barnes-tls-pake-04.txt
has been successfully = submitted by Richard Barnes and posted to the
IETF = repository.

Name:          =  draft-barnes-tls-pake
Revision:      =  04
Title:          Usage of PAKE with = TLS 1.3
Document date:  2018-07-16
Group:      =     Individual Submission
Pages:        =   11
URL:            https://www.ietf.org/internet-drafts/draft-barnes-tls-p= ake-04.txt
Status:         https://datatracker.ietf.org/doc/draft-barnes-tls-pake/=
Htmlized:       https://tools.ietf.org/html/draft-barnes-tls-pake-04
Htmlized:       https://datatracker.ietf.org/doc/html/draft-barnes-tls-= pake
Diff:           https://www.ietf.org/rfcdiff?url2=3Ddraft-barnes-tls-pa= ke-04

Abstract:
   The pre-shared key mechanism = available in TLS 1.3 is not suitable for
   usage with = low-entropy keys, such as passwords entered by users.
  =  This document describes an extension that enables the use = of
   password-authenticated key exchange protocols with = TLS 1.3.




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

The IETF = Secretariat


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

 

------=_NextPart_001_0086_01D41F48.A59C0940-- ------=_NextPart_000_0085_01D41F48.A59C0940 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCD0sw ggO3MIICn6ADAgECAhAM5+DlF9hG/o/lYPwb8DA5MA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYT AlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xJDAi BgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTAeFw0wNjExMTAwMDAwMDBaFw0zMTEx MTAwMDAwMDBaMGUxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsT EHd3dy5kaWdpY2VydC5jb20xJDAiBgNVBAMTG0RpZ2lDZXJ0IEFzc3VyZWQgSUQgUm9vdCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK0OFc7kQ4BcsYfzt2D5cRKlrtwmlIiq9M71 IDkoWGAM+IDaqRWVMmE8tbEohIqK3J8KDIMXeo+QrIrneVNcMYQq9g+YMjZ2zN7dPKii72r7IfJS Yd+fINcf4rHZ/hhk0hJbX/lYGDW8R82hNvlrf9SwOD7BG8OMM9nYLxj+KA+zp4PWw25EwGE1lhb+ WZyLdm3X8aJLDSv/C3LanmDQjpA1xnhVhyChz+VtCshJfDGYM2wi6YfQMlqiuhOCEe05F52ZOnKh 5vqk2dUXMXWuhX0irj8BRob2KHnIsdrkVxfEfhwOsLSSplazvbKX7aqn8LfFqD+VFtD/oZbrCF8Y d08CAwEAAaNjMGEwDgYDVR0PAQH/BAQDAgGGMA8GA1UdEwEB/wQFMAMBAf8wHQYDVR0OBBYEFEXr oq/0ksuCMS1Ri6enIZ3zbcgPMB8GA1UdIwQYMBaAFEXroq/0ksuCMS1Ri6enIZ3zbcgPMA0GCSqG SIb3DQEBBQUAA4IBAQCiDrzf4u3w43JzemSUv/dyZtgy5EJ1Yq6H6/LV2d5Ws5/MzhQouQ2XYFwS TFjk0z2DSUVYlzVpGqhH6lbGeasS2GeBhN9/CTyU5rgmLCC9PbMoifdf/yLil4Qf6WXvh+DfwWdJ s13rsgkq6ybteL59PyvztyY1bV+JAbZJW58BBZurPSXBzLZ/wvFvhsb6ZGjrgS2U60K3+owe3WLx vlBnt2y98/Efaww2BxZ/N3ypW2168RJGYIPXJwS+S86XvsNnKmgR34DnDDNmvxMNFG7zfx9jEB76 jRslbWyPpbdhAbHSoyahEHGdreLD+cOZUbcrBwjOLuZQsqf6CkUvovDyMIIFOjCCBCKgAwIBAgIQ Di7WjgxCjxTrYbReNHesEzANBgkqhkiG9w0BAQsFADBlMQswCQYDVQQGEwJVUzEVMBMGA1UEChMM RGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3d3cuZGlnaWNlcnQuY29tMSQwIgYDVQQDExtEaWdpQ2Vy dCBTSEEyIEFzc3VyZWQgSUQgQ0EwHhcNMTcxMTI4MDAwMDAwWhcNMjIwMjI1MTIwMDAwWjBWMQsw CQYDVQQGEwJVUzENMAsGA1UECBMEVXRhaDENMAsGA1UEBxMETGVoaTERMA8GA1UEChMIRGlnaUNl cnQxFjAUBgNVBAMTDVRpbSBIb2xsZWJlZWswggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDKUTIS9F3d7CfkCjsf4my28pYoZJDkEAiXVqGP4jzbFkszUQNfW3PYpFUo1GnKQykl/tM0qnzw 05bfVLo1+ce0e9fyAwYfulr+HaAVCPqx+PZw9CDY6c0NYd7Fc7S0scONxKekNF4q1mUucfGuGapW sEsyix0CuR0NMuJ4I+w8qMn9MzjzI7bvduG+uVLmZIi0p6D8+2R5BOQFy0tVeQ/aLfS91fG1DTYF YkPF+a/6JlFxzywPzCth8KW2Po4w8JqQWtam/ADKrgMaOnEJs9csefTW/FWRDeGQk5t3rnyS19FP QfpyPPau4ChB5xokfRcg3VEwqfOoIIexjUhZY5X9AgMBAAGjggHzMIIB7zAfBgNVHSMEGDAWgBTn AiOAAE/Y17yUC9k/dDlJMjyKeTAdBgNVHQ4EFgQUjqBhf3GcBV6YGYSmp2iS4Wi/3N4wDAYDVR0T AQH/BAIwADAlBgNVHREEHjAcgRp0aW0uaG9sbGViZWVrQGRpZ2ljZXJ0LmNvbTAOBgNVHQ8BAf8E BAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMEMGA1UdIAQ8MDowOAYKYIZIAYb9 bAQBAjAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BTMIGIBgNVHR8E gYAwfjA9oDugOYY3aHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFzc3VyZWRJ RENBLWcyLmNybDA9oDugOYY3aHR0cDovL2NybDQuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkFz c3VyZWRJRENBLWcyLmNybDB5BggrBgEFBQcBAQRtMGswJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3Nw LmRpZ2ljZXJ0LmNvbTBDBggrBgEFBQcwAoY3aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0Rp Z2lDZXJ0U0hBMkFzc3VyZWRJRENBLmNydDANBgkqhkiG9w0BAQsFAAOCAQEAmOLw9+cVMHn8tJ0k 76baCfFZwkvfvxSAlCXo+Fcsv55/og0V065Rpb4HvVTi0e0qKCMbBxc71NWxhMvKJHt+sfSmVatX mAOPNDRvtVvJBkcd0bvzMut/r3npQqs1wezHLtAq+MlQZDjgiJB+DkNblnnphzEQSp7q/4K9oMoP KViRxBv+/kseA8GOfhHU6EVmeu9xQrBqexH1DPUrUSGpNGDyvtUaU+bBy8Kz2hQfOu6f/73wLqUx e583C9y2Gqn1xCB77yPxXqRSLLRC6FbrToJbKiFYQJ4znZZyhPYJHL0SOpWyXfVKp4PEO54A/xr5 oVyPhEQhOtasoIRCLtHZrzCCBk4wggU2oAMCAQICEASueWBmZpAaucV/pmxb3M0wDQYJKoZIhvcN AQELBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3 LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMB4XDTEz MTEwNTEyMDAwMFoXDTI4MTEwNTEyMDAwMFowZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lD ZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hB MiBBc3N1cmVkIElEIENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3PgRIz9qte/A J3kbLQWHohBDMd8O1BUbT3ekIs4+jHDwvgeO3ScqvAEdtiwKyt1pWB9B7WoFH9pjeFkeIiwr+Lp+ yTU7VvEffEJ+JbAjGcZFONc9RPkgfGCuHLBaGAS+jzv3qfCUmqYMY0m2QRdTQDK9T+ZQelAfJUXo 8Ymvzf9e/1Dz8BcR/73FifW9YrnY+45FBIVtmc3FSE39JqsCNkXqNtdfauIagkEK3OnZ9ZEXjsYh rTg8E+Yef2ac1U3ZRtr2z1KnfTskw7TBUTXGm+vU737kewPhRL16CzfgT8uCig1xGOSm4IksG/Oy czzBsJKeGH29q33FfQihLMKfcwIDAQABo4IC+DCCAvQwEgYDVR0TAQH/BAgwBgEB/wIBADAOBgNV HQ8BAf8EBAMCAYYwNAYIKwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdp Y2VydC5jb20wgYEGA1UdHwR6MHgwOqA4oDaGNGh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdp Q2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwOqA4oDaGNGh0dHA6Ly9jcmwzLmRpZ2ljZXJ0LmNvbS9E aWdpQ2VydEFzc3VyZWRJRFJvb3RDQS5jcmwwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwME MIIBswYDVR0gBIIBqjCCAaYwggGiBgpghkgBhv1sAAIEMIIBkjAoBggrBgEFBQcCARYcaHR0cHM6 Ly93d3cuZGlnaWNlcnQuY29tL0NQUzCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMA ZQAgAG8AZgAgAHQAaABpAHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0 AHUAdABlAHMAIABhAGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMA ZQByAHQAIABDAFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABh AHIAdAB5ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkA YQBiAGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjAdBgNVHQ4EFgQU5wIjgABP 2Ne8lAvZP3Q5STI8inkwHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNtyA8wDQYJKoZIhvcN AQELBQADggEBAE7UiSe5/R2Hd34PKAWQ8QovyTs+vZOckMav+pFRhzJUa+jKwXFRXJmOtfrgYhmZ pgeafBMn2+UCooQS2RX2CkRXxDSPbXMfOtagAT3e44LkRWuy6yX9gF4dOZC+W0L2zpFg4/mgVgxI EM4zaHvNk6vwastPWA+5e10bBIGepyLiV0kn7pKTCL5pCFMCOi5dyBn0UIBOAtmwXZG0k4f5lpaB VUCOZu2C2LsoX+1MYe0GWCgZUxFEvEcgKbIEbNiJVJk7ddtneCweknjGVT1YEhEybr1DDE0023vG QtvsvqubYUwGkuOO3yEqUFcEwGCiNdUknmY3CUnP1fhls+DibsIxggO/MIIDuwIBATB5MGUxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5j b20xJDAiBgNVBAMTG0RpZ2lDZXJ0IFNIQTIgQXNzdXJlZCBJRCBDQQIQDi7WjgxCjxTrYbReNHes EzANBglghkgBZQMEAgEFAKCCAhcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0B CQUxDxcNMTgwNzE5MTQwOTU3WjAvBgkqhkiG9w0BCQQxIgQgHDvZUXV532z4SevY11JVz6O+rszj c8bgbjL0IR9vBKYwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERp Z2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQg U0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOthtF40d6wTMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2lj ZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgU0hBMiBBc3N1cmVkIElEIENBAhAOLtaODEKPFOth tF40d6wTMIGTBgkqhkiG9w0BCQ8xgYUwgYIwCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBFjAKBggq hkiG9w0DBzALBglghkgBZQMEAQIwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAsGCWCG SAFlAwQCATALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAcGBSsOAwIaMA0GCSqGSIb3DQEBAQUA BIIBALqJzwdpn2IzcdceXl8dHcH/OGXDCyKbDa6uAIx432rxn4AZYcLQIav3GqxyaYzQ/UCJ/oGQ tnUzJz/7BSZdJuiESqtQpjxFtXmYyJbsuCJfkt6eezAxfVHRBeCYfv/E1f2PV9I2nRgguLs5PipR YR3iTXbQ4L5PTPzf6OfRyKgljvj2hc+zkPlLbYSSsHEt5Kh3jvyC09SWP/9SATRZlAliqwfRK94a fAEGXP7YyrFNIegQFu6jMx8D+/crtVsUUqEC6K5EbaCJpk/5iM6iD8S0/dMHX06RT+yTm2yYTIvW ATLKhYnPno3uVmsphohbK058CmULnFGJMG/laeA/z64AAAAAAAA= ------=_NextPart_000_0085_01D41F48.A59C0940-- From nobody Thu Jul 19 09:16:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FB61130ECF for ; Thu, 19 Jul 2018 09:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VvXklfdz8n8C for ; Thu, 19 Jul 2018 09:16:20 -0700 (PDT) Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A0D48130E84 for ; Thu, 19 Jul 2018 09:16:20 -0700 (PDT) Received: by straasha.imrryr.org (Postfix, from userid 1001) id D1E3A29E0FC; Thu, 19 Jul 2018 12:16:18 -0400 (EDT) Date: Thu, 19 Jul 2018 12:16:18 -0400 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20180719161618.GT33554@straasha.imrryr.org> Reply-To: tls@ietf.org References: <20180718023039.GV33554@straasha.imrryr.org> <20180719032347.GJ9723@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180719032347.GJ9723@localhost> User-Agent: Mutt/1.9.4 (2018-02-28) Archived-At: Subject: Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 16:16:25 -0000 On Wed, Jul 18, 2018 at 10:23:49PM -0500, Nico Williams wrote: > > At yesterday's WG meeting, Sam Weiler suggested that the pinning > > information could be conveyed via the DNS. That way you would not need new > > holes/fields in the TLS extension. Paul said it doesn't work. But Willem > > Toorop and I discussed it after the meeting, and think that it does. > > I agree that it _could_ be done with a DNS RR. However, that has two > negative effects: 1) it will bloat the extension's payload more than the > two bytes we're asking for, 2) it complicates deployment / the > operator's life. In any realistic deployment, the publisher of the TLSA records is the *same* entity that provisions the certificate chain, anything else is operationally untenable. In absence of indirection via SRV records, the only way to combine DANE with hosting by a provider that is not also managing the domain's DNS records is to use CNAMEs as follows: Customer1 DNSSEC zone: www.example.com. IN CNAME dane-host.example.net. _443._tcp.www.example.com. IN CNAME _443._tcp.dane-host.example.net. Provider DNSSEC zone: dane-host.example.net. IN A 192.0.2.1 _443._tcp.dane-host.example.net. IN TLSA 3 1 1 b7ebd7545ab9e7b80ba39885063ec7c07fcaff16226f2a76287ed7b168cfbf34 _443._tcp.dane-host.example.net. IN TLSA 3 1 1 8a0956311647187d73d47ac672d55da73c8feae40cd9fd177414b72e75e0693f The client will send an SNI of "www.example.com", which the server needs to be pre-configured to accept. The server will then return the corresponding cached CNAME and shared TLSA RRset with all approrpriate signatures, DNSKEY and DS records. ; per-customer CNAME RR, cached on server. ; _443._tcp.www.example.org. IN CNAME _443._tcp.dane-host.example.net. ; shared target TLSA RRset, cached on servr. ; _443._tcp.dane-host.example.net. IN TLSA 3 1 1 b7ebd7545ab9e7b80ba39885063ec7c07fcaff16226f2a76287ed7b168cfbf34 _443._tcp.dane-host.example.net. IN TLSA 3 1 1 8a0956311647187d73d47ac672d55da73c8feae40cd9fd177414b72e75e0693f With the DANE TLSA records published by the provider, and extension support deployment across the various server farms also in the hands of the provider, there is little point in fetching the extension support lifetime from DNS. Either way the *provider* includes it with the chain data, but it is much easier to manage it as just configuration. The extension support lifetime is a TLS-specific property, and has no relevance for clients that can (afford to) do direct DNS lookups. It belongs in the TLS extension and not in DNS. -- Viktor. From nobody Thu Jul 19 12:05:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28681131168 for ; Thu, 19 Jul 2018 12:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lejey-Ku4xxx for ; Thu, 19 Jul 2018 12:05:12 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod06.osg.ufl.edu [128.227.74.254]) (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 8ECA8130F0F for ; Thu, 19 Jul 2018 12:04:36 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.39 Received: from exmbxprd13.ad.ufl.edu ([10.36.133.39]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w6JJ4YoU050410 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2018 15:04:34 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd13.ad.ufl.edu (10.36.133.39) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 19 Jul 2018 15:04:33 -0400 Received: from exmbxprd21.ad.ufl.edu (128.227.145.166) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 19 Jul 2018 15:04:34 -0400 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (216.32.181.119) by exmbxprd21.ad.ufl.edu (128.227.145.166) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Thu, 19 Jul 2018 15:04:34 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHPR22MB0750.namprd22.prod.outlook.com (10.171.150.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.19; Thu, 19 Jul 2018 19:04:32 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f%2]) with mapi id 15.20.0973.018; Thu, 19 Jul 2018 19:04:31 +0000 From: "Patton,Christopher J" To: Santosh Chokhani , "'Ilari Liusvaara'" CC: "tls@ietf.org" Thread-Topic: [TLS] Proposed changes to draft-ietf-tls-subcerts Thread-Index: AQHUHjQqsE1M6CF49EGVkJJk0Fkh4aSUjG8AgACw7A+AAEu7AIABYHq/ Date: Thu, 19 Jul 2018 19:04:31 +0000 Message-ID: References: , <20180718065616.GA18428@LK-Perkele-VII> , <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> In-Reply-To: <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8800:f546:26a0:5f54:ae8a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB0750; 7:trBIXjUBKQL6xG+Bn3WEuZu1ltw7zsxrydo7TpoSGEv8MbIPni6ISG6dTAdCANG1/FPBgJVsg1yFwT6myVryMMbuW301peoY3BA97xiGqMpQiMsfk6es82u2VSIfZG3oho5mOWDie1RsXuVeBqu7bNpdxdxT7PLmCdpBJp3F9gn2jtzOyjfuNo4g4NcQf9P7pNKj2GByF2AJDDXeJOseuhCVcbemVdb4/xy0kuK6r2tlgT/CB/0rJq+AEVy0cHfC x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: edf3f7e4-b494-48af-600e-08d5edaa75b8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0750; x-ms-traffictypediagnostic: MWHPR22MB0750: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(166708455590820)(85827821059158); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:MWHPR22MB0750; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0750; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(396003)(136003)(366004)(346002)(39860400002)(53754006)(189003)(199004)(7736002)(5250100002)(74316002)(2900100001)(88552002)(33656002)(2906002)(93886005)(229853002)(55016002)(236005)(6436002)(6306002)(9686003)(606006)(54896002)(6116002)(53546011)(6506007)(53936002)(186003)(102836004)(110136005)(476003)(19627405001)(75432002)(446003)(486006)(6606003)(575784001)(7696005)(86362001)(25786009)(106356001)(105586002)(76176011)(6246003)(4326008)(11346002)(39060400002)(8936002)(46003)(81156014)(966005)(81166006)(478600001)(8676002)(14454004)(99286004)(5660300001)(786003)(68736007)(14444005)(97736004)(256004)(316002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0750; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: LfO4OiQGIvmY6pfTngCSnbXCueN/ItzIJuqZyW2uZrvyLOh/tYu9QZ1DBxFIY6kSWVTPy4UvkEPoYvuVcCKxp9UbfE1K9fOy1ks/wp6cvB6jnK9Fi6G8zzCyXf1an0z+358aDMVwFztomPLjm0iFBsPvlT0BOHMwTpy8oe4eaT409zAys6zllYP+AaQj7gvf7p8t7u68XSJV0LYZ7zPnZWyMZaM5XVI+NuIwr6oYZA1u6HiegCLUv86TSvd4QhJL43aNMPUiQ5KyAMQICk7U5YwmjYpAoIocoEQXI3NFzLmKqE83fG0REsWmVfeQakI9Ta1ASFQrz/V7fZTrXm+9QgOrHwBgWY67jPrtOfUeefA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB0461AF67BCD113C16385021AC6520MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: edf3f7e4-b494-48af-600e-08d5edaa75b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 19:04:31.0677 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0750 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190198 X-UFL-Spam-Level: * Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 19:05:24 -0000 --_000_MWHPR22MB0461AF67BCD113C16385021AC6520MWHPR22MB0461namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks both of you for the feedback. I've revised the PR: https://github.com/tlswg/tls-subcerts/pull/9 There's now a "strict" flag that, if set, requires the server to offer a DC= . In Sec. 6.1, I describe why I think this is sufficient. Let me know what = you think! Best, Chris ________________________________ From: Santosh Chokhani Sent: Wednesday, July 18, 2018 6:00 PM To: Patton,Christopher J; 'Ilari Liusvaara' Cc: tls@ietf.org Subject: RE: [TLS] Proposed changes to draft-ietf-tls-subcerts I do not think you can change an extension syntax or semantic. It is three= tuple: extn ID, criticality flag, and value. You can add the syntax and semantics within the extension value as to what= it means. That may not help those who do not understand the extension an= d cannot process the value. From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Patton,Christopher J Sent: Wednesday, July 18, 2018 1:33 PM To: Ilari Liusvaara Cc: tls@ietf.org Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts Hi Ilari, I suppose you mean that this condition violates the critical bit = semantics: "If the extension is marked critical, then the server MUST NOT o= ffer the certificate unless it offers a delegated credential as well." Your suggesting adding a "must-use-DC" flag to the extension body? The cond= ition would be: "If the flag of the extension is set, then th= e server MUST NOT offer the certificate unless ..." ________________________________ From: ilariliusvaara@welho.com > on behalf of Ilari Liusvaa= ra > Sent: Wednesday, July 18, 2018 2:56 AM To: Patton,Christopher J Cc: tls@ietf.org Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts On Wed, Jul 18, 2018 at 01:17:44AM +0000, Patton,Christopher J wrote: > Hi all, > > > I've added a few pull requests to the draft "Delegated credentials for TL= S" that address the proposals discussed at IETF. > > Specifically: > > * https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_t= lswg_tls-2Dsubcerts_pull_8&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2K= ikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiFCDoqBxni= QnDZR8n5dA&s=3DJkn0aWEFHUhGyKTRFXHGPt7fdDUvxeXGJQkwmPR2HdU&e=3D -- Creates = a tighter binding of the DC to the handshake parameters; > * https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_t= lswg_tls-2Dsubcerts_pull_9&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2K= ikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiFCDoqBxni= QnDZR8n5dA&s=3DlsmtgnR-B-sA-BU_CcpbAtB7UC4Q0zyFqOLOGB3-FZM&e=3D -- Permits = mandatory delegation-key isolation, addresses the proposed"must-use-DC" TLS= feature extension; > * https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_t= lswg_tls-2Dsubcerts_pull_10&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2= KikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiFCDoqBxn= iQnDZR8n5dA&s=3DQ1-PUQoj_LL4tFA4UPxTUiiUNRYfsdAf9nhNCaAItZY&e=3D -- drops s= upport for TLS 1.2. > > Comments on these changes are welcome; feel free to chime in on GitHub.. The way mandatory delegation-key usage is specified seems to violate how X.509 critical bit is supposed to work. The bit is not supposed to alter processing of recogized extensions, it is only supposed to alter processing of unrecognized extensions from ignore to reject. If you want to actually alter the processing to require such certificate to always only be used for DC, you need a flag somewhere else, which might be payload of the extension (and that extension should _also_ be marked critical to ensure that clients that do not understand DC do not accept it). -Ilari --_000_MWHPR22MB0461AF67BCD113C16385021AC6520MWHPR22MB0461namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Thanks both of you for the feedba= ck.


I've revised the PR:

https://github.com/tlswg/tls-subcerts/pull/9

There's now a "strict" = flag that, if set, requires the server to offer a DC. In Sec. 6.1, I descri= be why I think this is sufficient. Let me know what you think!


Best,

Chris


From: Santosh Chokhani <= santosh.chokhani@gmail.com>
Sent: Wednesday, July 18, 2018 6:00 PM
To: Patton,Christopher J; 'Ilari Liusvaara'
Cc: tls@ietf.org
Subject: RE: [TLS] Proposed changes to draft-ietf-tls-subcerts
 

I do not think you can change an = extension syntax or semantic.  It is three tuple: extn ID, criticality= flag, and value.

 

You can add the syntax and semant= ics  within the extension value as to what it means.   That = may not help those who do not understand the extension and cannot process the value.

 

From: TLS [mailto:tls-bounces@ie= tf.org] On Behalf Of Patton,Christopher J
Sent: Wednesday, July 18, 2018 1:33 PM
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

 

= Hi Ilari, I suppose you mean that this condition violates the critical= bit semantics: "If the extension is marked critical, then the se= rver MUST NOT offer the certificate unless it offers a delegated credential as well."

=  

= Your suggesting adding a "must-use-DC" flag to the extension= body? The condition would be: "If the <must-use-DC> flag of the= extension is set, then the server MUST NOT offer the certificate unless ..."

=  

=  

 

From: ilariliusvaara@welho.com <ilariliu= svaara@welho.com> on behalf of Ilari Liusvaara <ilariliusvaara@welho.com>
Sent: Wednesday, July 18, 2018 2:56 AM
To: Patton,Christopher J
Cc: tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts

 

On Wed, Jul 18, 2018 at 01:17:44AM = +0000, Patton,Christopher J wrote:
> Hi all,
>
>
> I've added a few pull requests to the draft "Delegated credential= s for TLS" that address the proposals discussed at IETF.
>
> Specifically:
>
>   *   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_tlswg_tls= -2Dsubcerts_pull_8&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2K= ikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiF= CDoqBxniQnDZR8n5dA&s=3DJkn0aWEFHUhGyKTRFXHGPt7fdDUvxeXGJQkwmPR2HdU&= e=3D -- Creates a tighter binding of the DC to the handshake parameters;
>   *   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_tlswg_tls= -2Dsubcerts_pull_9&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2K= ikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0UuiF= CDoqBxniQnDZR8n5dA&s=3DlsmtgnR-B-sA-BU_CcpbAtB7UC4Q0zyFqOLOGB3-FZM&= e=3D -- Permits mandatory delegation-key isolation, addresses the proposed"= ;must-use-DC" TLS feature extension;
>   *   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_tlswg_tls= -2Dsubcerts_pull_10&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2= KikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3DRriZv_awLgJt5QVpMsfl0Uui= FCDoqBxniQnDZR8n5dA&s=3DQ1-PUQoj_LL4tFA4UPxTUiiUNRYfsdAf9nhNCaAItZY&= ;e=3D -- drops support for TLS 1.2.
>
> Comments on these changes are welcome; feel free to chime in on GitHub= ..

The way mandatory delegation-key usage is specified seems to violate how X.509 critical bit is supposed to work. The bit is not supposed to alter processing of recogized extensions, it is only supposed to alter processing=
of unrecognized extensions from ignore to reject.

If you want to actually alter the processing to require such
certificate to always only be used for DC, you need a flag somewhere
else, which might be payload of the extension (and that extension
should _also_ be marked critical to ensure that clients that do not
understand DC do not accept it).


-Ilari

--_000_MWHPR22MB0461AF67BCD113C16385021AC6520MWHPR22MB0461namp_-- From nobody Thu Jul 19 12:44:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587B4130DC9 for ; Thu, 19 Jul 2018 12:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25RPEzPVozlE for ; Thu, 19 Jul 2018 12:44:09 -0700 (PDT) Received: from homiemail-a131.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2FB4130DC6 for ; Thu, 19 Jul 2018 12:44:09 -0700 (PDT) Received: from homiemail-a131.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a131.g.dreamhost.com (Postfix) with ESMTP id 148026000171C; Thu, 19 Jul 2018 12:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=oQcdd2u/OF5Ugoy63bg+y/BHG10 =; b=up1P6oOWZrek9GKOPk8+opzT8kkJbBh2isj5rVdnF5keHis85tGQzsDrBJg 9lyBE6Noi1NlETu93OZKR+gOvejZLcxgZq3xP0uG3zmlkP53pe14x5eIEL08cHQ1 iPb+mPpay5ZSfkGPVDwIbo0xOfV/8TMTnVNEw6b0cpqzZqmk= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a131.g.dreamhost.com (Postfix) with ESMTPSA id CB1526000171B; Thu, 19 Jul 2018 12:44:08 -0700 (PDT) Date: Thu, 19 Jul 2018 14:44:06 -0500 From: Nico Williams To: tls@ietf.org Message-ID: <20180719194405.GK9723@localhost> References: <20180718023039.GV33554@straasha.imrryr.org> <20180719032347.GJ9723@localhost> <20180719161618.GT33554@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180719161618.GT33554@straasha.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 19:44:12 -0000 On Thu, Jul 19, 2018 at 12:16:18PM -0400, Viktor Dukhovni wrote: > On Wed, Jul 18, 2018 at 10:23:49PM -0500, Nico Williams wrote: > > > At yesterday's WG meeting, Sam Weiler suggested that the pinning > > > information could be conveyed via the DNS. That way you would not need new > > > holes/fields in the TLS extension. Paul said it doesn't work. But Willem > > > Toorop and I discussed it after the meeting, and think that it does. > > > > I agree that it _could_ be done with a DNS RR. However, that has two > > negative effects: 1) it will bloat the extension's payload more than the > > two bytes we're asking for, 2) it complicates deployment / the > > operator's life. > > In any realistic deployment, the publisher of the TLSA records is > the *same* entity that provisions the certificate chain, anything > else is operationally untenable. To make it short, the problem is that with A RRs the customer has to update TLSA RRs to match the hosting site's, and has to do this on a timely basis. That can certainly be arranged, but I agree that at least initially, and until this is generally automated, that will indeed be a problem. But I'm not too concerned because it is just a matter of automation. My issues with a new DNS RR for specification of pinning remain. Nico -- From nobody Thu Jul 19 12:47:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C113130DC9 for ; Thu, 19 Jul 2018 12:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZHDhnNAP6RU for ; Thu, 19 Jul 2018 12:47:19 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0435A130DC6 for ; Thu, 19 Jul 2018 12:47:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id B0408339A1; Thu, 19 Jul 2018 22:47:16 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 2ccKUaMS9eYW; Thu, 19 Jul 2018 22:47:16 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 5DEE32317; Thu, 19 Jul 2018 22:39:38 +0300 (EEST) Date: Thu, 19 Jul 2018 22:39:38 +0300 From: Ilari Liusvaara To: "Patton,Christopher J" Cc: Santosh Chokhani , "tls@ietf.org" Message-ID: <20180719193938.GA24141@LK-Perkele-VII> References: <20180718065616.GA18428@LK-Perkele-VII> <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 19:47:23 -0000 On Thu, Jul 19, 2018 at 07:04:31PM +0000, Patton,Christopher J wrote: > Thanks both of you for the feedback. > > > I've revised the PR: > > https://github.com/tlswg/tls-subcerts/pull/9 > > > There's now a "strict" flag that, if set, requires the server to > offer a DC. In Sec. 6.1, I describe why I think this is sufficient. > Let me know what you think! Ugh, it occurs to me that to have proper processing in all cases, including client that does not support DC and client that does and ignores criticality of supported extensions, you need to have critical flag and strict flag mirror each other. -Ilari From nobody Thu Jul 19 12:56:15 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99156130DC9 for ; Thu, 19 Jul 2018 12:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1KDO0Q-eWiHp for ; Thu, 19 Jul 2018 12:56:10 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod05.osg.ufl.edu [128.227.74.125]) (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 9AA9A130EB2 for ; Thu, 19 Jul 2018 12:56:09 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.41 Received: from exmbxprd15.ad.ufl.edu ([10.36.133.41]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w6JJu6LN013893 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2018 15:56:08 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd15.ad.ufl.edu (10.36.133.41) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 19 Jul 2018 15:56:07 -0400 Received: from exmbxprd23.ad.ufl.edu (2002:80e3:91a7::80e3:91a7) by exmbxprd23.ad.ufl.edu (2002:80e3:91a7::80e3:91a7) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 19 Jul 2018 15:56:06 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (216.32.180.15) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Thu, 19 Jul 2018 15:56:06 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHPR22MB0093.namprd22.prod.outlook.com (10.168.249.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.952.18; Thu, 19 Jul 2018 19:56:05 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f%2]) with mapi id 15.20.0973.018; Thu, 19 Jul 2018 19:56:05 +0000 From: "Patton,Christopher J" To: Ilari Liusvaara CC: Santosh Chokhani , "tls@ietf.org" Thread-Topic: [TLS] Proposed changes to draft-ietf-tls-subcerts Thread-Index: AQHUHjQqsE1M6CF49EGVkJJk0Fkh4aSUjG8AgACw7A+AAEu7AIABYHq/gAAKfACAAAOdcw== Date: Thu, 19 Jul 2018 19:56:05 +0000 Message-ID: References: <20180718065616.GA18428@LK-Perkele-VII> <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> , <20180719193938.GA24141@LK-Perkele-VII> In-Reply-To: <20180719193938.GA24141@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8800:f546:26a0:5f54:ae8a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB0093; 7:Gz4pG+puNheV0kudSMLWgI3jfyjpsJBOBgdJqCfDy39D8lgKvo3DVyEH+YvZrUVq/8acGdEs6OdKwKRZ7/ivSlsPPSLb1JRk984aT/1Pd6wKXQhAtfWPg3NccfHpvonPMLGcphfQgSvXIfRFZNC5y0kgKUdGq/817sktvLvn9nDNkRYLxdTT9FBajTG+pub3rgARC1QR2M6eAgt1DLjrsTGql6M8c6nHP9firoZ4SdR9jXQ5TLZgqx3L7yMTYWSi x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 5d437341-4814-4be0-54c6-08d5edb1a98a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0093; x-ms-traffictypediagnostic: MWHPR22MB0093: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:MWHPR22MB0093; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0093; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(366004)(39860400002)(199004)(189003)(54896002)(81156014)(81166006)(14454004)(7696005)(6506007)(102836004)(2900100001)(33656002)(76176011)(6916009)(8936002)(5250100002)(6116002)(9686003)(236005)(2906002)(53546011)(19627405001)(46003)(8676002)(478600001)(5660300001)(55016002)(88552002)(606006)(68736007)(316002)(966005)(786003)(4326008)(229853002)(6606003)(6306002)(446003)(186003)(86362001)(575784001)(97736004)(7736002)(93886005)(476003)(54906003)(486006)(75432002)(11346002)(6246003)(74316002)(99286004)(106356001)(53936002)(256004)(105586002)(6436002)(39060400002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0093; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: Q2JlRfxrgobPo2TEE/52fLVGYBTq89B8J/aJSv6C7DiiUm4YVqB/CcN/LaBnw2dUr0ncXs6N11snsbJVIFg61/eO5cI71UUB60sd64aUTMeTJ7FIDV3LuSePteTfa54tQKA9QDViwuvjmwomMznKYH669ywtiS7GFeg4drF8nOZ6uaEU2WOg3Wlb+g7kY/5ZdJmPvrM73vtXkUUuaGoN8XlsQfTxH80eszjRBXZpZrjpX3ydp9PYpSm8LH8PlLrKrK7+TyOFNWaO7WajmSpSNbzAzHvfcrTANx90ZuI3U7ZERhsOC5FaLFga0JkTVjuAEIYMb3p4oXiMCwezA2iNq1XlNXwQBDVWAZ3ny4vm3pU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB046123EF1C0E7B7F9B1C6CB0C6520MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5d437341-4814-4be0-54c6-08d5edb1a98a X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 19:56:05.0521 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0093 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190208 X-UFL-Spam-Level: * Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 19:56:14 -0000 --_000_MWHPR22MB046123EF1C0E7B7F9B1C6CB0C6520MWHPR22MB0461namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So you think we need that the extension is marked critical if and only if t= he strict flag is set? That wouldn't be ideal. Can you explain your thinkin= g? Which case presents a problem? ________________________________ From: ilariliusvaara@welho.com on behalf of Ilar= i Liusvaara Sent: Thursday, July 19, 2018 3:39 PM To: Patton,Christopher J Cc: Santosh Chokhani; tls@ietf.org Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts On Thu, Jul 19, 2018 at 07:04:31PM +0000, Patton,Christopher J wrote: > Thanks both of you for the feedback. > > > I've revised the PR: > > https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_tlswg_t= ls-2Dsubcerts_pull_9&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2KikqINp= WlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3D_AoKRFspNsT-b4Jjhi1qtaEQ7O68i_qvVS7Gwt9= TkB0&s=3DfZWPg8E9BJ_dXERlQXMDWwzI0uzp5mFFkN9roNzSXpk&e=3D > > > There's now a "strict" flag that, if set, requires the server to > offer a DC. In Sec. 6.1, I describe why I think this is sufficient. > Let me know what you think! Ugh, it occurs to me that to have proper processing in all cases, including client that does not support DC and client that does and ignores criticality of supported extensions, you need to have critical flag and strict flag mirror each other. -Ilari --_000_MWHPR22MB046123EF1C0E7B7F9B1C6CB0C6520MWHPR22MB0461namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

So you think we need that the ext= ension is marked critical if and only if the strict flag is set? That would= n't be ideal. Can you explain your thinking? Which case presents a problem?=


From: ilariliusvaara@welho.= com <ilariliusvaara@welho.com> on behalf of Ilari Liusvaara <ilari= liusvaara@welho.com>
Sent: Thursday, July 19, 2018 3:39 PM
To: Patton,Christopher J
Cc: Santosh Chokhani; tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts
 
On Thu, Jul 19, 2018 at 07:04:31PM +0000, Patt= on,Christopher J wrote:
> Thanks both of you for the feedback.
>
>
> I've revised the PR:
>
> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__github.com_tlswg_tls= -2Dsubcerts_pull_9&d=3DDwIBaQ&c=3DpZJPUDQ3SB9JplYbifm4nt2lEVG5pWx2K= ikqINpWlZM&r=3DVKs6yUchJieNTSwm3Abwfg&m=3D_AoKRFspNsT-b4Jjhi1qtaEQ7= O68i_qvVS7Gwt9TkB0&s=3DfZWPg8E9BJ_dXERlQXMDWwzI0uzp5mFFkN9roNzSXpk&= e=3D

>
>
> There's now a "strict" flag that, if set, requires the serve= r to
> offer a DC. In Sec. 6.1, I describe why I think this is sufficient. > Let me know what you think!

Ugh, it occurs to me that to have proper processing in all cases,
including client that does not support DC and client that does and
ignores criticality of supported extensions, you need to have
critical flag and strict flag mirror each other.


-Ilari
--_000_MWHPR22MB046123EF1C0E7B7F9B1C6CB0C6520MWHPR22MB0461namp_-- From nobody Thu Jul 19 13:18:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D71F130EB2 for ; Thu, 19 Jul 2018 13:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52l_OrTtDPI9 for ; Thu, 19 Jul 2018 13:18:52 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FF27130DC9 for ; Thu, 19 Jul 2018 13:18:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id BC9314863F; Thu, 19 Jul 2018 23:18:50 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id LnjDz42Jp2Wz; Thu, 19 Jul 2018 23:18:50 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 0AA022308; Thu, 19 Jul 2018 23:18:46 +0300 (EEST) Date: Thu, 19 Jul 2018 23:18:46 +0300 From: Ilari Liusvaara To: "Patton,Christopher J" Cc: Santosh Chokhani , "tls@ietf.org" Message-ID: <20180719201846.GA24678@LK-Perkele-VII> References: <20180718065616.GA18428@LK-Perkele-VII> <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> <20180719193938.GA24141@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 20:18:55 -0000 On Thu, Jul 19, 2018 at 07:56:05PM +0000, Patton,Christopher J wrote: > So you think we need that the extension is marked critical if and > only if the strict flag is set? That wouldn't be ideal. Can you > explain your thinking? Which case presents a problem? There are two types of clients: 1) Clients that do not know about DC. - These clients never use DC. - These do not understand the DC extension. - If you want non-strict certificate, it has to have critical=false on DC extension. - If you want strict certificate, it has to have critical=true on DC extension. 2) Clients that support DC. - These clients may or may not use DC. - These understand the DC extension. - As consequence, criticality of DC extension is ignored by X.509 rules. - So to specify if certificate is strict, you need a flag inside the extension. And in the end, the two flags always end up mirroring each other, but signifying different things. -Ilari From nobody Thu Jul 19 13:39:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E6B1130F46 for ; Thu, 19 Jul 2018 13:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N9E549zZwx1f for ; Thu, 19 Jul 2018 13:39:17 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod04.osg.ufl.edu [128.227.74.220]) (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 21159130F43 for ; Thu, 19 Jul 2018 13:39:16 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.36 Received: from exmbxprd05.ad.ufl.edu ([10.36.133.36]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w6JKdEJp031854 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 19 Jul 2018 16:39:14 -0400 Received: from exmbxprd21.ad.ufl.edu (128.227.145.166) by exmbxprd05.ad.ufl.edu (10.36.133.36) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 19 Jul 2018 16:39:14 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd21.ad.ufl.edu (128.227.145.166) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 19 Jul 2018 16:39:14 -0400 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (216.32.181.111) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Thu, 19 Jul 2018 16:39:14 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHPR22MB0224.namprd22.prod.outlook.com (10.168.250.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.16; Thu, 19 Jul 2018 20:39:11 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f%2]) with mapi id 15.20.0973.018; Thu, 19 Jul 2018 20:39:11 +0000 From: "Patton,Christopher J" To: Ilari Liusvaara CC: Santosh Chokhani , "tls@ietf.org" Thread-Topic: [TLS] Proposed changes to draft-ietf-tls-subcerts Thread-Index: AQHUHjQqsE1M6CF49EGVkJJk0Fkh4aSUjG8AgACw7A+AAEu7AIABYHq/gAAKfACAAAOdc4AAB1IAgAABKuI= Date: Thu, 19 Jul 2018 20:39:11 +0000 Message-ID: References: <20180718065616.GA18428@LK-Perkele-VII> <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> <20180719193938.GA24141@LK-Perkele-VII> , <20180719201846.GA24678@LK-Perkele-VII> In-Reply-To: <20180719201846.GA24678@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [198.41.129.2] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB0224; 6:KzGDE3O9UVgD0L+2HWCYfDYZ4nY18S58o5vzgYhWWXoMjS0PCWAcbezzr/50r5NA1goBUpJHG/YsVVm/K0jcEsaU/jCX4Zj1soZoOFC365iKhBddz+SQf1YOhcJkhJUS573+oUAzNG+N72wOj6yTrU4LvOm1ScfslDK2fMbWfevSgQ4+JO1WG0fnnk2X0T0Q+lbZFLW8+ShlYcgAaZxBwBY7mzKIl9inTylJPojpk23i9oUAQCuSS7MfOzLwT33BMb7JEF8IZQR5FBaoD16fmKoxolooqZyFfNFWfHQickfP/Em+j6P79YY3MultMtG6Cj4IEl7uQbgK5OZd5/OY+YD2o9WDwfZ+dd+cEXtkq39AkNMVzFuBbvZS/521orp5un65Xh7qBaLSCcTNFnaEYSqb44WDqDmWLgJocNp9b/772b+NZ1daxH86DN/QPaonu+ZDUHlkyx5bt9ttwKvvgw==; 5:ymziqjtNH141IsaM888DIuzRT1VdH6FsezoN7uMXm07lJC9SxtNBW7cAPi4pa5+iSUy+eOfb6AeMhVOLTg2NsfO6r2NNP7vnFI7kSzI7TkyK8Yhss35eFYP5PSkJoWBuPU4C/15wa+9B0zXq0wJqlY692ODR0We5Dvr+0kPleAk=; 7:16nGTX2IH9POJNyrWeOEFmgIfD9MJ4GrLTUpIgi20oykUM4BlObmdOy/IVkxOLhCvvhCvMfw67FFkvgrB/1YtGyPvrKmCM5wztwYOkb3RlwlacTzK5fK5dx/QIs0vFi2a6njNdRXliF2RwBZMr9BIpG6SOMz/h+XJgGjpib2M0EDy6aWu1bWsR0vfTl5zXZ6iOGL9hxBSEDfuxcL6gU4Nyw4u36PgSNLyMuPFvIsCnYvKU3E3OuSc+/AAAw0t/Bh x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 8da4594f-3859-4b0d-7bc5-08d5edb7af53 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600053)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0224; x-ms-traffictypediagnostic: MWHPR22MB0224: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(17755550239193); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231311)(944501410)(52105095)(93006095)(93001095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MWHPR22MB0224; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0224; x-forefront-prvs: 0738AF4208 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(396003)(346002)(366004)(376002)(199004)(189003)(256004)(6916009)(186003)(74316002)(3846002)(6116002)(14444005)(102836004)(6606003)(26005)(75432002)(6436002)(7696005)(9686003)(68736007)(54906003)(55016002)(786003)(316002)(54896002)(93886005)(5660300001)(86362001)(53546011)(7736002)(229853002)(6506007)(486006)(478600001)(33656002)(88552002)(14454004)(4326008)(53936002)(25786009)(476003)(81166006)(81156014)(446003)(5250100002)(99286004)(8936002)(6246003)(39060400002)(2900100001)(8676002)(97736004)(76176011)(66066001)(11346002)(106356001)(2906002)(19627405001)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0224; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9uogzbrPKTLX3sqxrJLt0ElhvLVocO/LxI5CV+MtAFdpoH+hxpFPOuNJCUtz7ZWZsczwxJcdD6NhferTsZwfqe6cXr9hssZ+qHEGf87uKhnSZpAzDyNBsyar7yzRQwXDi+2+roI7ZcpnMxQ+khBYuEeouPVq774Eq8cIqvCknPn49Q536irDVvOo8RMU73CdOTddaN4SmkJKPrOq6uyLFKmCeuhnqzOoT1TzfspboQFwvTe76qSx32F/H+EK+1DPOzJvV6RXztRsFfCjrfSHjLUGOdNsRQmYnp5PQRPmEtEOiP9ZAc7RrQ4gscs45tRTylfde5zKCOfWx6rZCHsgk2rQNH1h7FcuEiamavFGS8Y= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB046158E91E8C329DD62C9A43C6520MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8da4594f-3859-4b0d-7bc5-08d5edb7af53 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jul 2018 20:39:11.8284 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0224 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=914 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190215 X-UFL-Spam-Level: * Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 20:39:21 -0000 --_000_MWHPR22MB046158E91E8C329DD62C9A43C6520MWHPR22MB0461namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Suppose that strict delegation usage is required (strict=3Dtrue). Is it val= id for the extension to be non-critical (crit=3Dfalse)? No, because the ser= ver has to serve a DC, even if the client doesn't request one. Thus, strict= =3Dtrue implies that crit=3Dtrue. Now let's check the converse. Suppose that the crit=3Dtrue. Is it valid for= strict to be false? Yes, because the extension being critical only means t= hat the client has to understand DC in order to accept the certificate. But= this doesn't mean they must negotiate a DC. So I agree with one case you point out: If strict delegation usage is requi= red, then the extension must be critical. However, if the extension is crit= ical, both strict and non-strict delegation usage are valid. Do you agree? If so, I'll amend the draft accordingly. Chris ________________________________ From: ilariliusvaara@welho.com on behalf of Ilar= i Liusvaara Sent: Thursday, July 19, 2018 4:18 PM To: Patton,Christopher J Cc: Santosh Chokhani; tls@ietf.org Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts On Thu, Jul 19, 2018 at 07:56:05PM +0000, Patton,Christopher J wrote: > So you think we need that the extension is marked critical if and > only if the strict flag is set? That wouldn't be ideal. Can you > explain your thinking? Which case presents a problem? There are two types of clients: 1) Clients that do not know about DC. - These clients never use DC. - These do not understand the DC extension. - If you want non-strict certificate, it has to have critical=3Dfalse on DC extension. - If you want strict certificate, it has to have critical=3Dtrue on DC extension. 2) Clients that support DC. - These clients may or may not use DC. - These understand the DC extension. - As consequence, criticality of DC extension is ignored by X.509 rules. - So to specify if certificate is strict, you need a flag inside the extension. And in the end, the two flags always end up mirroring each other, but signifying different things. -Ilari --_000_MWHPR22MB046158E91E8C329DD62C9A43C6520MWHPR22MB0461namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Suppose that strict delegation us= age is required (strict=3Dtrue). Is it valid for the extension to be non-cr= itical (crit=3Dfalse)? No, because the server has to serve a DC, even if th= e client doesn't request one. Thus, strict=3Dtrue implies that crit=3Dtrue.


Now let's check the converse. Sup= pose that the crit=3Dtrue. Is it valid for strict to be false? Yes, because= the extension being critical only means that the client has to unders= tand DC in order to accept the certificate. But this doesn't mean they must negotiate a DC.


So I agree with one case you poin= t out: If strict delegation usage is required, then the extension must be c= ritical. However, if the extension is critical, both strict and n= on-strict delegation usage are valid.


Do you agree? If so, I'll amend t= he draft accordingly.


Chris



From: ilariliusvaara@welho.= com <ilariliusvaara@welho.com> on behalf of Ilari Liusvaara <ilari= liusvaara@welho.com>
Sent: Thursday, July 19, 2018 4:18 PM
To: Patton,Christopher J
Cc: Santosh Chokhani; tls@ietf.org
Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts
 
On Thu, Jul 19, 2018 at 07:56:05PM +0000, Patt= on,Christopher J wrote:
> So you think we need that the extension is marked critical if and
> only if the strict flag is set? That wouldn't be ideal. Can you
> explain your thinking? Which case presents a problem?

There are two types of clients:

1) Clients that do not know about DC.

- These clients never use DC.
- These do not understand the DC extension.
- If you want non-strict certificate, it has to have critical=3Dfalse
  on DC extension.
- If you want strict certificate, it has to have critical=3Dtrue on
  DC extension.

2) Clients that support DC.

- These clients may or may not use DC.
- These understand the DC extension.
- As consequence, criticality of DC extension is ignored by X.509
  rules.
- So to specify if certificate is strict, you need a flag inside
  the extension.


And in the end, the two flags always end up mirroring each other,
but signifying different things.


-Ilari
--_000_MWHPR22MB046158E91E8C329DD62C9A43C6520MWHPR22MB0461namp_-- From nobody Thu Jul 19 16:00:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7ADE130DD2 for ; Thu, 19 Jul 2018 16:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZQTkIEe29wk for ; Thu, 19 Jul 2018 16:00:12 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935C4130EE8 for ; Thu, 19 Jul 2018 16:00:12 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6JMvPXx018135 for ; Fri, 20 Jul 2018 00:00:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : subject : message-id : mime-version : content-type; s=jan2016.eng; bh=6tabot/lQBi4542QzNY1tVK4ChsMKoqXSlkG0N2qSsE=; b=YtWGEI3i3Gvf4uGMXRcq4RpygoPRCn7nP/cSoaUu8ufl5MKyuQUsK/kiEbjdOBDsh5Fp q4RUZBvC9XGXiCYoZDonDmuzF26qEFmfWx/JAwO2kaw92zaFwMFNhRwL1cxXJe4NaCb7 ELq4FrhfY0I8vKxFr31M7Kxcs4LqB82MTvo+D4zghAl8ZEY1XBZEPBpwkM4CV0d9DrOx CwRZDIKKGMdvfuSGPLXEOsAtp5ufYJtIrDH37h5JOXFM4UYpzpHK04PAdYKvUL1FGZ7g ytIOpDHg/4i7NvzNQ22Skh3H7jB7K6m7fDwMxWCHHMgIpZHuHj8R73pxCFys0xcIFtHc bg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2kadm2k3rp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 20 Jul 2018 00:00:12 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6JMnwvr008978 for ; Thu, 19 Jul 2018 19:00:10 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2k7cgura4q-1 for ; Thu, 19 Jul 2018 19:00:10 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 6A29C225C1 for ; Thu, 19 Jul 2018 23:00:10 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fgHu5-0003Ts-U5 for tls@ietf.org; Thu, 19 Jul 2018 18:00:09 -0500 Date: Thu, 19 Jul 2018 18:00:09 -0500 From: Benjamin Kaduk To: tls@ietf.org Message-ID: <20180719230009.GD14551@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=1 mlxscore=1 mlxlogscore=190 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190237 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-19_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=1 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=1 clxscore=1015 lowpriorityscore=0 mlxscore=1 impostorscore=0 mlxlogscore=189 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807190239 Archived-At: Subject: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 19 Jul 2018 23:00:15 -0000 Hi all, As I mentioned at the mic today, there is a question that has been raised about whether it's wise to reuse an existing (TLS 1.2) PSK directly in the TLS 1.3 key ladder. At a high level, the reason why one might want to restrict this is that the security proofs for TLS 1.3 rely on the pre-shared key being only used with a single key-derivation function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different key-derivation function, so formally the proofs do not hold. We don't currently know of a specifc attack against such reuse, of course, but perhaps it is prudent to restrict our usage to adhere to the verified scenarios. This is somewhat timely, as if we do want to introduce a restriction, it would ideally be in the form of some text in the TLS 1.3 specification, which is very nearly done. It would be good to hear more opinions on this question, particularly from those who have worked on the formal verification directly. If I can attempt to summarize some discussion that occurred in the mic line today, Hannes was surprised that we would care, likening this case to the regular version negotiation, where we are happy to use the same certificate to sign messages for both TLS 1.2 and 1.3. David Benjamin points out that we explicitly go to the trouble of putting 64 bytes of 0x20 padding at the front of the content that gets signed for CertificateVerify, to enforce separation between the TLS versions. My own personal opinion is that we should enforce a domain separation between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal PSKs" proposal seems like a potential mechanism by which to do so without doubling the provisioning needs. -Ben (with no hat) From nobody Thu Jul 19 19:55:57 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4537013104A for ; Thu, 19 Jul 2018 19:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ktjmONyPRbw for ; Thu, 19 Jul 2018 19:55:52 -0700 (PDT) Received: from mail-io0-x243.google.com (mail-io0-x243.google.com [IPv6:2607:f8b0:4001:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14F8C13103F for ; Thu, 19 Jul 2018 19:55:52 -0700 (PDT) Received: by mail-io0-x243.google.com with SMTP id z20-v6so8812558iol.0 for ; Thu, 19 Jul 2018 19:55:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=ZovJC2gN5QLZIRJYPthcx/b+3LHviYRCn4ilK17/Puk=; b=p8gLg3f/VNewEHD/RXsG0ZlH4LOi6yRM+oykiB0644mfnk/JHflbQsk+eVmn40vCKo ESVdD2Pq7QNU9p2xiHpom0gQegZTGG/RP1MjOI/nBc3FhZuUoKF3BnE5mC61JAhGBazD Vf/TO7jha/LXTK6uXXv3JoJmyc5OgEbVl+NUfM7y7MZglfC1ur6wTlx8cibiBjIw8bdJ a6HqhvElyWYDcn+Kd8oB4j+aRzB4gbF1vmLSgGtTPnprgRYgcR4R1w/VZROflvD+IPXP +p10YNo7ULlCWapY6KOXB3myXDxtPcYwMRSoCXNdEwZydpamKUsdG71zzBkMWT0Fg6fp 2zdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZovJC2gN5QLZIRJYPthcx/b+3LHviYRCn4ilK17/Puk=; b=C49lnwjqhrTSUb8ZdwQSgy/e5cUvFBXzXxNdSOMvxH3J2GdH5rQdx2fXI1TgcwJdGk aW6Ejr8m35Gu6V+WziolXmsWrbo/ztTiw7wltuxKn4Tq8ukoOnusVAf+MuzR1G+mBCPb 40IKFAvCGhOG0LIRQ2pV4s/hOCQ/YfosFm30ajcUpwwsp0Vdrh5uH268cx8l0b1wsMlc +Xu18suXYlc8I+fyi5WeT2UsaXC2o44CcnM8Z9bHq1sZJ7wf64YQ0ssbgTdKl0DpEwzJ algNG+xH1LUu7+S/M6IWU5jzLf3F+8+VxyMG4PU2hnw+oIV1Vv27Sf1WwZ2d7ynUqQfN xwPQ== X-Gm-Message-State: AOUpUlFfxsVNlKmKAeuoPBFv7NAUwNHfeVPLcJ2T+dhHehzuX1YysLpR xxY3pm5GgyRN5y7tMMfCm5sD4U1bA8g= X-Google-Smtp-Source: AAOMgpcNUPsyrB70n4ied6ydF6A2jf7gqFZMzBFOuNYVp3pxnAIDmyHU8AAlrhhAoPivkwN1Nb9MMA== X-Received: by 2002:a6b:8828:: with SMTP id k40-v6mr186445iod.68.1532055351250; Thu, 19 Jul 2018 19:55:51 -0700 (PDT) Received: from [172.20.5.95] ([207.115.103.227]) by smtp.gmail.com with ESMTPSA id u12-v6sm601108ita.1.2018.07.19.19.55.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 19:55:50 -0700 (PDT) To: Tim Hollebeek , Hugo Krawczyk , Richard Barnes Cc: "" References: <153176915207.21824.6939177297174810137.idtracker@ietfa.amsl.com> From: Yaron Sheffer Message-ID: <95483aa1-710a-4e05-c131-09e467999524@gmail.com> Date: Thu, 19 Jul 2018 22:55:48 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-barnes-tls-pake-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 02:55:56 -0000 I strongly support this work. Also, having made this mistake myself in the past: please make sure that we have one fully specified PAKE in this document, and not only a generic envelope. This will ensure that TLS libraries have at least one working, and interoperable, PAKE, Thanks, Yaron On 19/07/18 10:10, Tim Hollebeek wrote: > Unfortunately, I haven’t had time to review the document, but +1 for > interesting problem, and +1 for anything Richard writes as a good > starting point, even if I haven’t read it. > > -Tim > > *From:* TLS *On Behalf Of *Hugo Krawczyk > *Sent:* Wednesday, July 18, 2018 7:13 PM > *To:* Richard Barnes > *Cc:* > *Subject:* Re: [TLS] Fwd: New Version Notification for > draft-barnes-tls-pake-04.txt > > +1 for this work. > > If you are one of those that think, as I did 20 years ago, that password > authentication is dying and practical replacements are just around the > corner, do not support this document. Otherwise, please do. > > Asymmetric or augmented PAKE (aPAKE) protocols provide secure password > authentication in the common client-server case (where the server stores > a one-way mapping of the password) without relying on PKI - except > during user/password registration. Passwords remain secure regardless of > which middleboxes or endpoints spy into your decrypted TLS streams.  The > server never sees the password, not even during password registration. > > To see real deployment of such protocols, they need to be integrated > with TLS which is what Barnes's draft facilitates. Not only this improve > significantly the protection of passwords and password authentication, > but aPAKE protocols also provide an hedge against PKI failures by > enabling mutual client-server authentication without relying on regular > server certificates. > > Hugo > > On Wed, Jul 18, 2018 at 1:18 PM, Richard Barnes > wrote: > > Hey TLS WG, > > In response to some of the list discussion since the last IETF, Owen > and I revised our TLS PAKE draft.  In the current version, instead > of binding to a single PAKE (SPAKE2+), it defines a general > container that can carry messages for any PAKE that has the right > shape.  And we think that "right shape" covers several current > PAKEs: SPAKE2+, Dragonfly, SRP, OPAQUE, ..... > > The chairs have graciously allotted us 5min on the agenda for > Thursday, where I'd like to ask for the WG to adopt the document. > So please speak up if you think this is an interesting problem for > the TLS WG to work on, and if you think the approach in this > document is a good starting point.  Happy for comments here or at > the microphone on Thursday! > > Thanks, > > --Richard > > ---------- Forwarded message --------- > From: > > Date: Mon, Jul 16, 2018 at 3:25 PM > Subject: New Version Notification for draft-barnes-tls-pake-04.txt > To: Richard Barnes >, Owen Friel > > > > > > > A new version of I-D, draft-barnes-tls-pake-04.txt > has been successfully submitted by Richard Barnes and posted to the > IETF repository. > > Name:           draft-barnes-tls-pake > Revision:       04 > Title:          Usage of PAKE with TLS 1.3 > Document date:  2018-07-16 > Group:          Individual Submission > Pages:          11 > URL: https://www.ietf.org/internet-drafts/draft-barnes-tls-pake-04.txt > Status: https://datatracker.ietf.org/doc/draft-barnes-tls-pake/ > Htmlized: https://tools.ietf.org/html/draft-barnes-tls-pake-04 > Htmlized: https://datatracker.ietf.org/doc/html/draft-barnes-tls-pake > Diff: https://www.ietf.org/rfcdiff?url2=draft-barnes-tls-pake-04 > > Abstract: >    The pre-shared key mechanism available in TLS 1.3 is not > suitable for >    usage with low-entropy keys, such as passwords entered by users. >    This document describes an extension that enables the use of >    password-authenticated key exchange protocols with TLS 1.3. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org > . > > The IETF Secretariat > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Jul 20 00:29:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06FF1131068 for ; Fri, 20 Jul 2018 00:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afkotToZW4Wv for ; Fri, 20 Jul 2018 00:29:07 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 960C51310E1 for ; Fri, 20 Jul 2018 00:29:07 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id l2-v6so3516817wme.1 for ; Fri, 20 Jul 2018 00:29:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=7zSLFQTfyhYONit3/Nw6hXjjSDpHI1b6uBkU0rLk6/w=; b=WRArBYKN1kJtmxX0T7JT/KJUdnnMooYSOhJIQB9q3jK1vXqt3M2M6EFrP27g1KY08W ZPxj3eJKiXrn7Vhwgrlt8nZqgnPI0iw+rpRyfnwTpsogBKiwU4xaMbWT10BLAxwH/8kC /E3KL8AKgPrLYO7zjvK1Lp+NTSCxFq9TJ7/BEe8HbcBVkd8XQMYuenMKUvo97C3K7VWO d+fyuQlVktpR8Z5c920CkarNrZdmXCtWOfaIz9IOj8J30cOjUUFulsIxemGYyOKDZvnD YmxlIhfx7dMtnHWzqulSrdaVswNMqh36AbT3B9pdJPDzlm23/xsS1c78+GwGqXgTgGD9 e5SA== X-Gm-Message-State: AOUpUlHugPL7zBn0nipYpN8XeXzwaLJbWCaF5nQTBV32x5m4XP3ATy5g BsxR9hfpPwulOj/HaJqclAerTvxIZLs= X-Google-Smtp-Source: AAOMgpdlQujSBWlc6beH+UHfOFQaG+L5+8nLwrWTHXuBO7GpUR8xTA0Sgkra/bQHlz0w8b2Vf/YQvQ== X-Received: by 2002:a1c:dc89:: with SMTP id t131-v6mr826518wmg.50.1532071745759; Fri, 20 Jul 2018 00:29:05 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id t9-v6sm981229wra.62.2018.07.20.00.29.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Jul 2018 00:29:04 -0700 (PDT) Message-ID: From: Nikos Mavrogiannopoulos To: Benjamin Kaduk , tls@ietf.org Date: Fri, 20 Jul 2018 09:29:03 +0200 In-Reply-To: <20180719230009.GD14551@akamai.com> References: <20180719230009.GD14551@akamai.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.3 (3.28.3-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 07:29:18 -0000 On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote: > Hi all, > > As I mentioned at the mic today, there is a question that has been > raised about whether it's wise to reuse an existing (TLS 1.2) PSK > directly in the TLS 1.3 key ladder. At a high level, the reason why > one > might want to restrict this is that the security proofs for TLS 1.3 > rely > on the pre-shared key being only used with a single key-derivation > function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different > key-derivation function, so formally the proofs do not hold. We > don't > currently know of a specifc attack against such reuse, of course, but > perhaps it is prudent to restrict our usage to adhere to the verified > scenarios. > > This is somewhat timely, as if we do want to introduce a restriction, > it > would ideally be in the form of some text in the TLS 1.3 > specification, > which is very nearly done. > > It would be good to hear more opinions on this question, particularly > from those who have worked on the formal verification directly. > > If I can attempt to summarize some discussion that occurred in the > mic > line today, Hannes was surprised that we would care, likening this > case > to the regular version negotiation, where we are happy to use the > same > certificate to sign messages for both TLS 1.2 and 1.3. David > Benjamin > points out that we explicitly go to the trouble of putting 64 bytes > of > 0x20 padding at the front of the content that gets signed for > CertificateVerify, to enforce separation between the TLS versions. > > My own personal opinion is that we should enforce a domain separation > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal > PSKs" > proposal seems like a potential mechanism by which to do so without > doubling the provisioning needs. I think the same rules should apply for PSK and RSA/ECDSA/EdDSA keys. There is no inherent difference between the two keys types. I could have deployed TLS with PKI or TLS with PSK. I should be able to upgrade protocols the same way. If RSA keys can be re-used between TLS1.2 and TLS1.3, then so should PSK keys. The current document specifically allows that re-use, and if you fear that the current document did not take cross-protocol attacks in mind during design, then let's fix that instead. regards, Nikos From nobody Fri Jul 20 02:24:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44D6131114 for ; Fri, 20 Jul 2018 02:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9F8v4AlnVkvz for ; Fri, 20 Jul 2018 02:24:16 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4DC131277BB for ; Fri, 20 Jul 2018 02:24:16 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 35CE3B80D6E; Fri, 20 Jul 2018 02:24:10 -0700 (PDT) To: amedvins@excitecorp.com, matt.hur@cybersafe.com, kaduk@mit.edu, ekr@rtfm.com, christopherwood07@gmail.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: eugene.adell@gmail.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20180720092410.35CE3B80D6E@rfc-editor.org> Date: Fri, 20 Jul 2018 02:24:10 -0700 (PDT) Archived-At: Subject: [TLS] [Editorial Errata Reported] RFC2712 (5432) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 09:24:18 -0000 The following errata report has been submitted for RFC2712, "Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5432 -------------------------------------- Type: Editorial Reported by: Eugene Adell Section: Appendix Original Text ------------- Corrected Text -------------- Appendix RFC 2712 introduces new cipher suites values, starting with the cipher value { 0x00, 0x1E }. This cipher value was earlier known as a Fortezza cipher suite, and this could lead to a conflict. Notes ----- Errata 5409 was rejected and I was suggested to post another one at this place. RFC 2712 (Addition of Kerberos Cipher Suites to Transport Layer Security) in its Draft 01 version introduces new cipher suites values, among them three are colliding with the Fortezza cipher suites. The Draft 02 version partially corrects that, by shifting all of the Kerberos cipher suites values by two. This omission of the third Fortezza cipher suite has never been corrected, and this remains in the same state in the final RFC 2712. As a result, the cipher suite value { 0x00, 0x1E } is now officially known as a Kerberos one. Although not documented themselves by any RFC, the two non conflicting Fortezza cipher suites are mentionned in the same note in the TLS protocol RFC (2246, 4346, 5246). This gives an explanation on how the Kerberos cipher suite values were chosen. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC2712 (draft-ietf-tls-kerb-cipher-suites-04) -------------------------------------- Title : Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) Publication Date : October 1999 Author(s) : A. Medvinsky, M. Hur Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Jul 20 02:39:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E172C131136 for ; Fri, 20 Jul 2018 02:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9xF5hegb73hZ for ; Fri, 20 Jul 2018 02:39:15 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34EF5131133 for ; Fri, 20 Jul 2018 02:39:15 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id j143-v6so1359442lfj.12 for ; Fri, 20 Jul 2018 02:39:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PmmUGZctUBvo8ygUu+cLZJWGJGv7xIyAn+vAmTxad6c=; b=MsCFQ7uNW2zewhvwUOHjHfQQ2SddMu4ePWDWDzOCdkNBWjJrl85PZbcXDXzTnC+XPA sz6FXC8l3Ojb0NSoq2fAlonNmz2IPgMMkdYcNKbTbcCKg/kJquRrccjXJaxj/f22RnDA cbdsezdXAt8eAby1GWp2l7Hjh5e0Dn4n0/k4NSc3Kd/ryoiqRvKVaIV5kP1NlZRSdj7S DnsIikis4ikkLBU9DG4tWAp5Qxtj8OCNC/U9RejHR3iDjFb95rLKw1s+qDGgfAwGfbLe 9GOrnsPP91YtH7okl1ry7dQI8JoiC476ZMFMZQ31dadPKBi7UYp0wj00zQUDvNe4DPbh qDng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PmmUGZctUBvo8ygUu+cLZJWGJGv7xIyAn+vAmTxad6c=; b=VaBB6NFB6WVx18j9uwER6fZ9eiDbh9LOsdq0YOfx+FGYQQ+N+bBFwElPhGAEWhfaLF 1mp9nBpQx6pb09HSxJA8UEox6a7Uck3UlMFAADZ5DKIrE1axpAJCIq2HjF+WBgtSy0Iw /wd7VFbOYPDjhwMv3vwMu9nVO1COaPYmKSV9shRuIcACw15jVQnU0032MkccpsXo8CYe AWvF+G3jqBI0FNcQsyGg79TjL5bQ9dbkXRQqIHmdOErd9Ioc/f0aHVqSZB7xGU7GKWs6 EEuI9o65Tub+bBsRYDh7HtxDuSY2bnyiqpR45EYyzzXW3wMMGr8GmNHhLA2E2cvLMmOI tdyA== X-Gm-Message-State: AOUpUlEYWKNxgfaNP0h6FJYHot0HqBIWJcysRmFZ5RizP4mTnsIBfobi l0uMq66YlO/ZDdZDFMrI0YHKL1WiCGWP50hjCeZJcg== X-Google-Smtp-Source: AAOMgpckZrzdNKKz0rnO2LknBJ4LME7Y65WBY5qVXNWkxh6ttayea+UEGwy0qqNRQd/YX3e5GA3k+e5HD3B6XpYIam0= X-Received: by 2002:a19:6308:: with SMTP id x8-v6mr968982lfb.104.1532079553429; Fri, 20 Jul 2018 02:39:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 02:38:32 -0700 (PDT) In-Reply-To: References: <20180719230009.GD14551@akamai.com> From: Eric Rescorla Date: Fri, 20 Jul 2018 02:38:32 -0700 Message-ID: To: Nikos Mavrogiannopoulos Cc: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary="0000000000008cd74405716b11a7" Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 09:39:18 -0000 --0000000000008cd74405716b11a7 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 20, 2018 at 12:29 AM, Nikos Mavrogiannopoulos wrote: > On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk wrote: > > Hi all, > > > > As I mentioned at the mic today, there is a question that has been > > raised about whether it's wise to reuse an existing (TLS 1.2) PSK > > directly in the TLS 1.3 key ladder. At a high level, the reason why > > one > > might want to restrict this is that the security proofs for TLS 1.3 > > rely > > on the pre-shared key being only used with a single key-derivation > > function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different > > key-derivation function, so formally the proofs do not hold. We > > don't > > currently know of a specifc attack against such reuse, of course, but > > perhaps it is prudent to restrict our usage to adhere to the verified > > scenarios. > > > > This is somewhat timely, as if we do want to introduce a restriction, > > it > > would ideally be in the form of some text in the TLS 1.3 > > specification, > > which is very nearly done. > > > > It would be good to hear more opinions on this question, particularly > > from those who have worked on the formal verification directly. > > > > If I can attempt to summarize some discussion that occurred in the > > mic > > line today, Hannes was surprised that we would care, likening this > > case > > to the regular version negotiation, where we are happy to use the > > same > > certificate to sign messages for both TLS 1.2 and 1.3. David > > Benjamin > > points out that we explicitly go to the trouble of putting 64 bytes > > of > > 0x20 padding at the front of the content that gets signed for > > CertificateVerify, to enforce separation between the TLS versions. > > > > My own personal opinion is that we should enforce a domain separation > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal > > PSKs" > > proposal seems like a potential mechanism by which to do so without > > doubling the provisioning needs. > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA keys. > There is no inherent difference between the two keys types. I could > have deployed TLS with PKI or TLS with PSK. I should be able to upgrade > protocols the same way. > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so should > PSK keys. The current document specifically allows that re-use, and if > you fear that the current document did not take cross-protocol attacks > in mind during design, then let's fix that instead. > The issue is not cross-protocol attacks; it's the reuse of PSKs with different KDFs, which we don't have any analysis for and which the TLS 1.3 document prohibits. -Ekr > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000008cd74405716b11a7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 20, 2018 at 12:29 AM, Nikos Mavrogiannopoulos <nmav@redhat.c= om> wrote:
On Thu, 2018-07-19 at 18:00 -0500, Benjamin Kaduk w= rote:
> Hi all,
>
> As I mentioned at the mic today, there is a question that has been
> raised about whether it's wise to reuse an existing (TLS 1.2) PSK<= br> > directly in the TLS 1.3 key ladder.=C2=A0 At a high level, the reason = why
> one
> might want to restrict this is that the security proofs for TLS 1.3 > rely
> on the pre-shared key being only used with a single key-derivation
> function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different<= br> > key-derivation function, so formally the proofs do not hold.=C2=A0 We<= br> > don't
> currently know of a specifc attack against such reuse, of course, but<= br> > perhaps it is prudent to restrict our usage to adhere to the verified<= br> > scenarios.
>
> This is somewhat timely, as if we do want to introduce a restriction,<= br> > it
> would ideally be in the form of some text in the TLS 1.3
> specification,
> which is very nearly done.
>
> It would be good to hear more opinions on this question, particularly<= br> > from those who have worked on the formal verification directly.
>
> If I can attempt to summarize some discussion that occurred in the
> mic
> line today, Hannes was surprised that we would care, likening this
> case
> to the regular version negotiation, where we are happy to use the
> same
> certificate to sign messages for both TLS 1.2 and 1.3.=C2=A0 David
> Benjamin
> points out that we explicitly go to the trouble of putting 64 bytes > of
> 0x20 padding at the front of the content that gets signed for
> CertificateVerify, to enforce separation between the TLS versions.
>
> My own personal opinion is that we should enforce a domain separation<= br> > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Univ= ersal
> PSKs"
> proposal seems like a potential mechanism by which to do so without > doubling the provisioning needs.

I think the same rules should apply for PSK and RSA/ECDSA/EdDSA= keys.
There is no inherent difference between the two keys types. I could
have deployed TLS with PKI or TLS with PSK. I should be able to upgrade
protocols the same way.

If RSA keys can be re-used between TLS1.2 and TLS1.3, then so should
PSK keys. The current document specifically allows that re-use, and if
you fear that the current document did not take cross-protocol attacks
in mind during design, then let's fix that instead.

The issue is not cross-protocol attacks; it's the reus= e of PSKs with different KDFs, which we don't have any analysis for and= which the TLS 1.3 document prohibits.

-Ekr


regards,
Nikos

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

--0000000000008cd74405716b11a7-- From nobody Fri Jul 20 02:43:56 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCBF3127148 for ; Fri, 20 Jul 2018 02:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vr7sIvmJOzmf for ; Fri, 20 Jul 2018 02:43:52 -0700 (PDT) Received: from mta.openssl.org (xmpp.openssl.org [IPv6:2001:608:c00:180::1:e6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FA75130DDF for ; Fri, 20 Jul 2018 02:43:52 -0700 (PDT) Received: from [10.82.10.6] (ip-9-84-52-196.southampton.uk.amsterdamresidential.com [196.52.84.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 10D82EAB74 for ; Fri, 20 Jul 2018 09:43:50 +0000 (UTC) To: tls@ietf.org References: <20180719230009.GD14551@akamai.com> From: Matt Caswell Openpgp: preference=signencrypt Autocrypt: addr=matt@openssl.org; prefer-encrypt=mutual; keydata= xsBNBFGALsIBCADBkh6zfxbewW2KJjaMaishSrpxuiVaUyvWgpe6Moae7JNCW8ayhJbwAtsQ 69SGA4gUkyrR6PBvDMVYEiYqZwXB/3IErStESjcu+gkbmsa0XcwHpkE3iN7I8aU66yMt710n GEmcrR5E4u4NuNoHtnOBKEh+RCLGp5mo6hwbUYUzG3eUI/zi2hLApPpaATXnD3ZkhgtHV3ln 3Z16nUWQAdIVToxYhvVno2EQsqe8Q3ifl2Uf0YpaN19BDBrxM3WPOAKbJk0Ab1bjgEadavrF BCOl9CrbThewRGmkOdxJWaVkERXMShlzUzjJvKOUEUGOxJCmnfQimPQoCdQyVFLgHfRFABEB AAHNH01hdHQgQ2Fzd2VsbCA8bWF0dEBvcGVuc3NsLm9yZz7CwHgEEwECACIFAlPevrwCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJENnE0m0OYESRoD0H/1lEJXfr66rdvskyOi0z U0ARvUXHjbmmYkZ7ETkdXh7Va/Tjn81T3pwmr3F4IcLGNLDz4Eg67xbq/T8rrsEPOx5nV/mR nUT97UmsQuLnR2wLGbRBu24FKM7oX3KQvgIdJWdxHHJsjpGCViE1mIFARAzlN+6p3tPbnQzA NjRy7i/PYU/niGdqVcMhcnZCX5F7YH6w6t0ZmYH3m1QeREnWqfxu7eyHsIvebMgKTI/bMG8Z 7KlLZha9HwrFXQAPIST6sfc1blKJ9INUDM9iK6DR/ulkw7e0hmHLqjWqYs5PzyXeoNnsPXJt 69wiADYqj4KNDIdNp1RoF9qfb1nE+DM6rgbOwE0EUYAuwgEIAM9nUJAEpsVBYwK92PP9Mlo1 /etXp6JgBI68sOCJxTwzBrbTzIlevVQXqW9zdODD6ObKcgGNuG+G6Nwn54P6McRpd2dxor9Y A+yaI0yT6CVnhxsXjwc/vuQ4tBAL6tfuMAXRVIeEVk22cKk4HJB68ImXCCRdyRi9HIE5iTrZ HsHC4sjAsirhlc0o8hU3gqkKh2Ehwa6+U8lzNx06hoFEZxIVRteoz1jzCHImF7EXztEcDIam O8uckVKAuKbJgFGkU3bkvNgWlc8Pgx4tRUNJGC1LE4nYqaSEwee1SpA/VewiDObj97PozCTF zRCUBCnSvaAlTnpA90TnODH7ar+L5aEAEQEAAcLAXwQYAQIACQUCUYAuwgIbDAAKCRDZxNJt DmBEkQs2B/96XB9hyFpX/bhu41YNr7nSA65dDi9d+PkMqvLppickG3VR4xXWywzEJTw6W2DN MyFO6mOtdXWgNdgDF7HKZYvHBr6pyttLAMP7BfWBvU7YY59uKmUSc5vl0NzsaSbx5PDSQEkS ICLI+/hIwuEXOb6Z7gOrX7F1uy83TmHFOOjD2mLl5isUzFhaLVk0fZSY+mCgg3/inbwb8g31 91Ybk2LfXmndaEsdEzMLrT0g6wIgmybz6UdVuVPfSPGly0VWVAG1sNPOCpAuJpNV6+VxrdVi Ax3vQPbx3XzqDFS1ISlnd0qS/7RXwMuFDpVH/BDvzQcoikWnpRY/loPGkSg4TB7a Message-ID: <444e453f-14d7-b0c7-3cb5-18a6d4af9cd1@openssl.org> Date: Fri, 20 Jul 2018 10:43:48 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 09:43:55 -0000 On 20/07/18 10:38, Eric Rescorla wrote: > The issue is not cross-protocol attacks; it's the reuse of PSKs with > different KDFs, which we don't have any analysis for and which the TLS > 1.3 document prohibits. Can you supply the reference for that prohibition? Thanks Matt From nobody Fri Jul 20 03:43:29 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C347E130F1A for ; Fri, 20 Jul 2018 03:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4x4aeV3c4fj for ; Fri, 20 Jul 2018 03:43:24 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54FFD130DD6 for ; Fri, 20 Jul 2018 03:43:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4FFE1233B4; Fri, 20 Jul 2018 13:43:21 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id n1QVf0Y4H6qb; Fri, 20 Jul 2018 13:43:21 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id BC02E289; Fri, 20 Jul 2018 13:43:18 +0300 (EEST) Date: Fri, 20 Jul 2018 13:43:18 +0300 From: Ilari Liusvaara To: Matt Caswell Cc: tls@ietf.org Message-ID: <20180720104318.GA27223@LK-Perkele-VII> References: <20180719230009.GD14551@akamai.com> <444e453f-14d7-b0c7-3cb5-18a6d4af9cd1@openssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <444e453f-14d7-b0c7-3cb5-18a6d4af9cd1@openssl.org> User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 10:43:27 -0000 On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote: > > > On 20/07/18 10:38, Eric Rescorla wrote: > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > > different KDFs, which we don't have any analysis for and which the TLS > > 1.3 document prohibits. > > Can you supply the reference for that prohibition? > Section 'Pre-Shared Key Extension'. In practicular, the paragraph starting "Each PSK is associated with a single Hash algorithm." That one prohibits using PSK associated with a hash with another hash. However, I did not find prohibition of using PSKs from prior versions of TLS using SHA-256 as the associated hash (as that is the default). -Ilari From nobody Fri Jul 20 04:06:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98650130E31 for ; Fri, 20 Jul 2018 04:06:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iLuTZaFZ2uAs for ; Fri, 20 Jul 2018 04:06:12 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 66C51130DD6 for ; Fri, 20 Jul 2018 04:06:12 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id p6-v6so10795328ljc.5 for ; Fri, 20 Jul 2018 04:06:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FIcSIdE76Sh47ymU0PWpfwMRh4dGlwyupaj9ExgQD5g=; b=Q20k4J/Bk0R/Wgf03guxvrl/445sF3ExKcuLsh6ToIzW3QFSINnEpHaRVM1/kSMJBi SFxz1/GfVwCuzLg2kN9kW0BQkluMv5yPVzw/eqDG8SKgDz6M0oCu3qC4C4BQ7IfcErmj /D3tw/E06EqDopXeaXSfYGCxlloSEMrts+rlLqv2dOWLOoWu69vNsL3nfP6VDVK/FFxx oQATbx4LnYtWN3VbYYzNcM31JKrBx9fx9s6rJlyFMGDHljPzmxax20279tLiNvXm85NQ N/RNZgNpgEiamMm1qhvT6clv+z1ChIHSNAgNgB43mSXoWy4odEdyf5pCYzO77YfshUOL c+nw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FIcSIdE76Sh47ymU0PWpfwMRh4dGlwyupaj9ExgQD5g=; b=Hm8VM58a5Uk3wvRmc8T+TBmh7/AyOMpOQdGataNcgiGdf63pTdze2+ERVyZKFXRx79 tlpAM8+M0rvDuufDBPTmhtU2PS+tz6eTfMEN42O680A1Ruy0TRNmI5UIZTDVF8x26uB1 Pbbgb9LXS+jcQC0nadiE6CjhvqMiAPjgjgTo83rSYDmWnPv7vupIrRxsQA7rS2NTN4OT RhZ1T5gF46BrHIV39FcljU4V/R51UiqokznQxEc2QAkc7F0D7vrOlWo9Q8MUO3kqX6wr 3o6pyZHFa+e504kgdF7t6kOWuXiSSMVomvxKTJpvstvFIcf9BMEs1QKEMEOA+DwIGf2V 0Eqg== X-Gm-Message-State: AOUpUlE3clvlzcoX7x8PE+BDjyzRVo0nwYAOZ4sVDU6bF4aNZLIzwmx5 yzCP95TiFRJOzR3eVz9adV6WQw7HK4YFp8/RNclY1w== X-Google-Smtp-Source: AAOMgpfu+tdIq+HXMR0gjUEASD/YELnMUnlfoPOXkO2gVjxEuHoqM7NuofLidzzyKAndADmB7pXlmqIqRepV5Kmd0Nc= X-Received: by 2002:a2e:458b:: with SMTP id s133-v6mr1284778lja.151.1532084770732; Fri, 20 Jul 2018 04:06:10 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 04:05:30 -0700 (PDT) In-Reply-To: <20180720104318.GA27223@LK-Perkele-VII> References: <20180719230009.GD14551@akamai.com> <444e453f-14d7-b0c7-3cb5-18a6d4af9cd1@openssl.org> <20180720104318.GA27223@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 20 Jul 2018 04:05:30 -0700 Message-ID: To: Ilari Liusvaara Cc: Matt Caswell , "" Content-Type: multipart/alternative; boundary="00000000000086901d05716c48a1" Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 11:06:15 -0000 --00000000000086901d05716c48a1 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 20, 2018 at 3:43 AM, Ilari Liusvaara wrote: > On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote: > > > > > > On 20/07/18 10:38, Eric Rescorla wrote: > > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > > > different KDFs, which we don't have any analysis for and which the TLS > > > 1.3 document prohibits. > > > > Can you supply the reference for that prohibition? > > > > Section 'Pre-Shared Key Extension'. In practicular, the paragraph > starting "Each PSK is associated with a single Hash algorithm." That > one prohibits using PSK associated with a hash with another hash. > However, I did not find prohibition of using PSKs from prior versions > of TLS using SHA-256 as the associated hash (as that is the default). > Right. There's no such text. However, the TLS 1.2 SHA-256 KDF isn't HKDF (and of course the TLS 1.0 KDF isn't even SHA-256), so we're kind of in an unclear area. -Ekr > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000086901d05716c48a1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 20, 2018 at 3:43 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Fri, Jul 20, 2018 at 10:43:48AM +0100, Matt Caswell wrote:
>
>
> On 20/07/18 10:38, Eric Rescorla wrote:
> > The issue is not cross-protocol attacks; it's the reuse of PS= Ks with
> > different KDFs, which we don't have any analysis for and whic= h the TLS
> > 1.3 document prohibits.
>
> Can you supply the reference for that prohibition?
>

Section 'Pre-Shared Key Extension'. In practicular, the para= graph
starting "Each PSK is associated with a single Hash algorithm." T= hat
one prohibits using PSK associated with a hash with another hash.
However, I did not find prohibition of using PSKs from prior versions
of TLS using SHA-256 as the associated hash (as that is the default).

Right. There's no such text. However, th= e TLS 1.2 SHA-256 KDF isn't HKDF (and of course the TLS 1.0 KDF isn'= ;t even SHA-256), so we're kind of in an unclear area.
-Ekr



-Ilari

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

--00000000000086901d05716c48a1-- From nobody Fri Jul 20 04:39:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9F9130EB1 for ; Fri, 20 Jul 2018 04:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LxJq4Knx5hOU for ; Fri, 20 Jul 2018 04:39:44 -0700 (PDT) Received: from mail-wr1-f51.google.com (mail-wr1-f51.google.com [209.85.221.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B93130DE7 for ; Fri, 20 Jul 2018 04:39:43 -0700 (PDT) Received: by mail-wr1-f51.google.com with SMTP id s11-v6so10996007wra.13 for ; Fri, 20 Jul 2018 04:39:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=z3QPAKvWmudSsY0KwBndmtIvsBMVgTZMGhSL9ApjsJY=; b=NIGLoErOdOXRQHKlJgbobIaPwI5IQR4wfZqmEYGTuYK1sjByQ3EOe3GgOmfT789C55 5lzLWhWcaZ4q+jOYxVPdlBaLSGWMkLfY4RAgU4IwcA3LmKxetp7H/k/VUd5+xyk6OPhb HzqyYn+N+JCNXQKFrk6NIzlUt45GRa0GIgKH/adW1TZmfgov8bke2CfbNptfPVwfBbMm MxMaXHX2QIXFCbOPZW1sujCV1+/vpckUq3714PQz1uvh1+HuAOGanA4u3/ZKPV0nt7RN yad03GjYcVbj9IXQrHbcXFR3Y94zJfGtkSqcWlVP+fxOu341sGoupm2PyXdZWvlctEaV 03nA== X-Gm-Message-State: AOUpUlGi0iKlfro0v0Z8G/wtQHcWhrZykwDljcpanmFD8HPFNGeE69yd NMjjdcHCYe8Qy7N3EqI/9wK4oA== X-Google-Smtp-Source: AAOMgpfO917grIw5Zz1Pp2kScRffnMIHzPrluGS55Gm3J4sNn5r+R2JRlojHGt3SYU/5/WbSYP3mMg== X-Received: by 2002:adf:a401:: with SMTP id d1-v6mr1222997wra.121.1532086782251; Fri, 20 Jul 2018 04:39:42 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id 73-v6sm1831278wmu.37.2018.07.20.04.39.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 20 Jul 2018 04:39:41 -0700 (PDT) Message-ID: <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Cc: Benjamin Kaduk , "" Date: Fri, 20 Jul 2018 13:39:40 +0200 In-Reply-To: References: <20180719230009.GD14551@akamai.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.3 (3.28.3-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 11:39:47 -0000 On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote: > > > > > This is somewhat timely, as if we do want to introduce a > > restriction, > > > it > > > would ideally be in the form of some text in the TLS 1.3 > > > specification, > > > which is very nearly done. > > > > > > It would be good to hear more opinions on this question, > > particularly > > > from those who have worked on the formal verification directly. > > > > > > If I can attempt to summarize some discussion that occurred in > > the > > > mic > > > line today, Hannes was surprised that we would care, likening > > this > > > case > > > to the regular version negotiation, where we are happy to use the > > > same > > > certificate to sign messages for both TLS 1.2 and 1.3. David > > > Benjamin > > > points out that we explicitly go to the trouble of putting 64 > > bytes > > > of > > > 0x20 padding at the front of the content that gets signed for > > > CertificateVerify, to enforce separation between the TLS > > versions. > > > > > > My own personal opinion is that we should enforce a domain > > separation > > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's > > "Universal > > > PSKs" > > > proposal seems like a potential mechanism by which to do so > > without > > > doubling the provisioning needs. > > > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA > > keys. > > There is no inherent difference between the two keys types. I could > > have deployed TLS with PKI or TLS with PSK. I should be able to > > upgrade > > protocols the same way. > > > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so > > should > > PSK keys. The current document specifically allows that re-use, and > > if > > you fear that the current document did not take cross-protocol > > attacks > > in mind during design, then let's fix that instead. > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > different KDFs, which we don't have any analysis for I understand, but as I have already mentioned that argument also applies for RSA keys which can be used e.g., for RSA encryption under TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used with multiple hashes under TLS1.2 while only one under TLS1.3. TLS 1.3 did not enforce protocol separation for that ugly scenario, so I wouldn't expect the treatment of PSKs differently. Said that, I want to clarify that I wouldn't necessarily object to an improvement the situation for externally established PSKs. The issue I see is that TLS1.3 already gives a "good enough" solution with re-using the key, and I'm afraid we're going to have interoperation issues if some implementations move to universal psks and some do not, defeating the purpose of a standard. regards, Nikos From nobody Fri Jul 20 05:09:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8853B127AC2 for ; Fri, 20 Jul 2018 05:09:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BglVO4xsNiFS for ; Fri, 20 Jul 2018 05:09:31 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::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 E7452124D68 for ; Fri, 20 Jul 2018 05:09:30 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id l15-v6so10953767lji.6 for ; Fri, 20 Jul 2018 05:09:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ol0ZiKy6O8XweWAJM2WViYXxZPO0TRcGol29MipldUE=; b=HC5bpf+NUvLwpwVgnqTL2l2A4OO0Spzo9UhesZcpwh3SZoRonjlySVi9li3g5sIQMy JpQ6tRSSMzt25OnLbggVmnt62pE2BDtblWku0eMC7LLanhf+698gt6J+WNmk5sFvn14I A0fmVSoPD3rzNVJZLXu0fWyyfkilRjOy+BRomLX3rKh7isLOYhi0QGxqGJbxUhWKbgaR mTcB5wiFGuhkSZzIG5t35DzY2rxorZCYuuJYvFima7ljqrnqvOID6yKYjHtNuDjVqh4+ sJn+3WQ2TPzKmKJzqkPIKvCFZrduRDq3zIarDxPUCNaT5vHU+SuMQgSFv1modVwUK/Ob /E9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ol0ZiKy6O8XweWAJM2WViYXxZPO0TRcGol29MipldUE=; b=ROFPkHH1OeVUNRrXtLGc3U/2TfzOF4sqMO8gPzg2Mu99MWcOjPodxw28/8lz+7hzmD IsJb6ljssCRRwqwkuQ4wlCSHBoSCaFJC7Xy2ObkPZZnaRMtfoGeToOrWn+zi4zCO29aZ LsacQ7AXZxSYVH5uoZDblkNzqbL0+D4fDkqD248Uo2TR/k2hY1hEC6bvbHfVESCNyf54 oTvRaqxYorRe6tsSocho5S8Ast97aD3bY6VGgjbU5PMrt61ZIyqUFk4lcbM2KXdgcyMM 5liMG4il1LpMlveMxIJm5X35ywwRVvuwVx3UFXhRTdMZmCLQyKOT4wNr1bT303FDQxEj V9Bg== X-Gm-Message-State: AOUpUlGjWOwJPgiZdLxeiBnipUW7hTha9ekLB24bw7E9bL/m55OVtLvT OTI0IooZxUHqRHB7OPEQk7F0dRLtoLuREP+KISeyOA== X-Google-Smtp-Source: AAOMgpdnZNuLiaj8uNNnk/ZrkZrwLbrb4uSaYBBx6PcfRpu/npmTFCK7lCyuWBz0CkiNrTb0RpMzLaB5PF1LK5+Ofb0= X-Received: by 2002:a2e:9c4d:: with SMTP id t13-v6mr1442831ljj.153.1532088569154; Fri, 20 Jul 2018 05:09:29 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 05:08:48 -0700 (PDT) In-Reply-To: <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> References: <20180719230009.GD14551@akamai.com> <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> From: Eric Rescorla Date: Fri, 20 Jul 2018 05:08:48 -0700 Message-ID: To: Nikos Mavrogiannopoulos Cc: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary="000000000000edde5e05716d2a78" Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 12:09:35 -0000 --000000000000edde5e05716d2a78 Content-Type: text/plain; charset="UTF-8" On Fri, Jul 20, 2018 at 4:39 AM, Nikos Mavrogiannopoulos wrote: > On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote: > > > > > > > This is somewhat timely, as if we do want to introduce a > > > restriction, > > > > it > > > > would ideally be in the form of some text in the TLS 1.3 > > > > specification, > > > > which is very nearly done. > > > > > > > > It would be good to hear more opinions on this question, > > > particularly > > > > from those who have worked on the formal verification directly. > > > > > > > > If I can attempt to summarize some discussion that occurred in > > > the > > > > mic > > > > line today, Hannes was surprised that we would care, likening > > > this > > > > case > > > > to the regular version negotiation, where we are happy to use the > > > > same > > > > certificate to sign messages for both TLS 1.2 and 1.3. David > > > > Benjamin > > > > points out that we explicitly go to the trouble of putting 64 > > > bytes > > > > of > > > > 0x20 padding at the front of the content that gets signed for > > > > CertificateVerify, to enforce separation between the TLS > > > versions. > > > > > > > > My own personal opinion is that we should enforce a domain > > > separation > > > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's > > > "Universal > > > > PSKs" > > > > proposal seems like a potential mechanism by which to do so > > > without > > > > doubling the provisioning needs. > > > > > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA > > > keys. > > > There is no inherent difference between the two keys types. I could > > > have deployed TLS with PKI or TLS with PSK. I should be able to > > > upgrade > > > protocols the same way. > > > > > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so > > > should > > > PSK keys. The current document specifically allows that re-use, and > > > if > > > you fear that the current document did not take cross-protocol > > > attacks > > > in mind during design, then let's fix that instead. > > > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > > different KDFs, which we don't have any analysis for > > I understand, but as I have already mentioned that argument also > applies for RSA keys which can be used e.g., for RSA encryption under > TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used > with multiple hashes under TLS1.2 while only one under TLS1.3. > TLS 1.3 did not enforce protocol separation for that ugly scenario, so > I wouldn't expect the treatment of PSKs differently. > I will let Karthik speak for himself, but I believe we do in fact have analysis for these cases. -Ekr > Said that, I want to clarify that I wouldn't necessarily object to an > improvement the situation for externally established PSKs. The issue I > see is that TLS1.3 already gives a "good enough" solution with re-using > the key, and I'm afraid we're going to have interoperation issues if > some implementations move to universal psks and some do not, defeating > the purpose of a standard. > > regards, > Nikos > > --000000000000edde5e05716d2a78 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jul 20, 2018 at 4:39 AM, Nikos Mavrogiannopoulos <nmav@redhat.co= m> wrote:
On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wro= te:
> >
> > > This is somewhat timely, as if we do want to introduce a
> > restriction,
> > > it
> > > would ideally be in the form of some text in the TLS 1.3
> > > specification,
> > > which is very nearly done.
> > >
> > > It would be good to hear more opinions on this question,
> > particularly
> > > from those who have worked on the formal verification direct= ly.
> > >
> > > If I can attempt to summarize some discussion that occurred = in
> > the
> > > mic
> > > line today, Hannes was surprised that we would care, likenin= g
> > this
> > > case
> > > to the regular version negotiation, where we are happy to us= e the
> > > same
> > > certificate to sign messages for both TLS 1.2 and 1.3.=C2=A0= David
> > > Benjamin
> > > points out that we explicitly go to the trouble of putting 6= 4
> > bytes
> > > of
> > > 0x20 padding at the front of the content that gets signed fo= r
> > > CertificateVerify, to enforce separation between the TLS
> > versions.
> > >
> > > My own personal opinion is that we should enforce a domain > > separation
> > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's<= br> > > "Universal
> > > PSKs"
> > > proposal seems like a potential mechanism by which to do so<= br> > > without
> > > doubling the provisioning needs.
> >
> > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA > > keys.
> > There is no inherent difference between the two keys types. I cou= ld
> > have deployed TLS with PKI or TLS with PSK. I should be able to > > upgrade
> > protocols the same way.
> >
> > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so
> > should
> > PSK keys. The current document specifically allows that re-use, a= nd
> > if
> > you fear that the current document did not take cross-protocol > > attacks
> > in mind during design, then let's fix that instead.
>
> The issue is not cross-protocol attacks; it's the reuse of PSKs wi= th
> different KDFs, which we don't have any analysis for

I understand, but as I have already mentioned that argument als= o
applies for RSA keys which can be used e.g., for RSA encryption under
TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used
with multiple hashes under TLS1.2 while only one under TLS1.3.
TLS 1.3 did not enforce protocol separation for that ugly scenario, so
I wouldn't expect the treatment of PSKs differently.

I will let Karthik speak for himself, but I believe we do= in fact have analysis
for these cases.

= -Ekr


Said that, I want to clarify that I wouldn't necessarily object to an improvement the situation for externally established PSKs. The issue I
see is that TLS1.3 already gives a "good enough" solution with re= -using
the key, and I'm afraid we're going to have interoperation issues i= f
some implementations move to universal psks and some do not, defeating
the purpose of a standard.

regards,
Nikos


--000000000000edde5e05716d2a78-- From nobody Fri Jul 20 05:43:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64EF4130E1A for ; Fri, 20 Jul 2018 05:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jq1rQNrcL1JY for ; Fri, 20 Jul 2018 05:43:01 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A3E612426A for ; Fri, 20 Jul 2018 05:43:01 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id z8-v6so10078994qto.9 for ; Fri, 20 Jul 2018 05:43:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TwZvfwWahZA1IVa9b4cbkguskprCXey1a3nKE9OFrRY=; b=DXWySGOCUHtXrFh+SihWZBcWo7wqfYHpCHabG8gbhRmHt/YREZ7Nz9Z3tMEW2kzQrf GT7x0C2qQorNOB4YvWKIREW2bYeJ0fbwKJn25BpElSnjO58n9TOkMKKRIWp1ODH34Uk1 rSXc0dPJK1ihpkdbVVLQseu0nGWs603alwj/I= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TwZvfwWahZA1IVa9b4cbkguskprCXey1a3nKE9OFrRY=; b=RNWaEXE4hfPGnYbrWePVUnxBue0+6qj5QOPp2BJzcQgVRPrwt++EfXXYrUXYZ84dHp pjPNa8GiEloABBUbTY4RAMLdNkZajDO0BvxSsppV92fqseP1um+dLhk2qHgpuCuI7v1U sXmQZEtq0u3hiBSJszgSDVfUm7KkKqPtGkxtarznxVI3gsDMouYvczasYP6ofKkEhZXt 2gL/iLAArJ1Ls4BRwdy+N6DbOYYVXMfZN7KHA2kuSB1jZ8D4zDr+xwLCIDotHitM7fg0 QRuwWEDc4Vewt7dXXPdgOD/m3eSTzanV3eUuY75j9HXsrhLe/TpSlc5QiXPJhn7Ygd6R CgAg== X-Gm-Message-State: AOUpUlHluRXdcfx0IhRzqcmLGesqxKT0pQ6DQ/xa1PlwT0YM7ErLFszi mQ+ygURF7y+JTMb45H6vHNqjfJUXsYf5rvXQp305 X-Google-Smtp-Source: AAOMgpfK+b57b24MayIdfsqPqeqdA2GpSECdxBeEtV9GL0dINy7wKsZ1STTmd7tPJthFQMKIJJ6Gk3oseDjLKlIyjKU= X-Received: by 2002:ac8:2d3a:: with SMTP id n55-v6mr1702473qta.220.1532090580258; Fri, 20 Jul 2018 05:43:00 -0700 (PDT) MIME-Version: 1.0 References: <20180719230009.GD14551@akamai.com> <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> In-Reply-To: <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> From: David Benjamin Date: Fri, 20 Jul 2018 08:42:47 -0400 Message-ID: To: Nikos Mavrogiannopoulos Cc: Eric Rescorla , "" , Benjamin Kaduk Content-Type: multipart/alternative; boundary="000000000000cd5e9705716da2cb" Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 12:43:04 -0000 --000000000000cd5e9705716da2cb Content-Type: text/plain; charset="UTF-8" On Fri, Jul 20, 2018 at 7:39 AM Nikos Mavrogiannopoulos wrote: > On Fri, 2018-07-20 at 02:38 -0700, Eric Rescorla wrote: > > > > > > > This is somewhat timely, as if we do want to introduce a > > > restriction, > > > > it > > > > would ideally be in the form of some text in the TLS 1.3 > > > > specification, > > > > which is very nearly done. > > > > > > > > It would be good to hear more opinions on this question, > > > particularly > > > > from those who have worked on the formal verification directly. > > > > > > > > If I can attempt to summarize some discussion that occurred in > > > the > > > > mic > > > > line today, Hannes was surprised that we would care, likening > > > this > > > > case > > > > to the regular version negotiation, where we are happy to use the > > > > same > > > > certificate to sign messages for both TLS 1.2 and 1.3. David > > > > Benjamin > > > > points out that we explicitly go to the trouble of putting 64 > > > bytes > > > > of > > > > 0x20 padding at the front of the content that gets signed for > > > > CertificateVerify, to enforce separation between the TLS > > > versions. > > > > > > > > My own personal opinion is that we should enforce a domain > > > separation > > > > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's > > > "Universal > > > > PSKs" > > > > proposal seems like a potential mechanism by which to do so > > > without > > > > doubling the provisioning needs. > > > > > > I think the same rules should apply for PSK and RSA/ECDSA/EdDSA > > > keys. > > > There is no inherent difference between the two keys types. I could > > > have deployed TLS with PKI or TLS with PSK. I should be able to > > > upgrade > > > protocols the same way. > > > > > > If RSA keys can be re-used between TLS1.2 and TLS1.3, then so > > > should > > > PSK keys. The current document specifically allows that re-use, and > > > if > > > you fear that the current document did not take cross-protocol > > > attacks > > > in mind during design, then let's fix that instead. > > > > The issue is not cross-protocol attacks; it's the reuse of PSKs with > > different KDFs, which we don't have any analysis for > > I understand, but as I have already mentioned that argument also > applies for RSA keys which can be used e.g., for RSA encryption under > TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be used > with multiple hashes under TLS1.2 while only one under TLS1.3. > TLS 1.3 did not enforce protocol separation for that ugly scenario, so > I wouldn't expect the treatment of PSKs differently. > PSKs are much easier to fix this with than signing algorithms, given that we don't want to reprovision either to deploy TLS 1.3. ECDSA in TLS didn't get worse with TLS 1.3. We didn't add a new hash to mixup, just restricted the set from TLS 1.2. If we left it alone, we'd still have the same effect. For RSA, you're right that we introduced an extra pair of algorithms to worry about. The options there are: (1) Add PSS, forbid PKCS1, and forbid PSS with id-rsaEncryption. Cost: TLS 1.3 requires reprovisioning RSA keys. (2) Add PSS, forbid PKCS1, but allow PSS with id-rsaEncryption. Cost: We have two algorithms with one key. (3) Don't forbid PKCS1. Cost: We don't get rid of PKCS#1. (1)'s cost is clearly fatal, given 1.3's goals. I'm personally fine with either (2) or (3), but the WG chose (2). With PSKs, I think we can get both. If we consider 1.2 PSKs to be paired with the 1.2 PRF, we can allocate a new label, and derive a separate thing to stick in 1.3, and not require reprovisioning. It's basically free, so I think it makes sense to do it. (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't think we actually believe SHA256 and SHA384 give related output. It's just nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA256 actually a chance of misbehavior. Perhaps it's worth doing that analysis?) Of course, I don't actually know what I'm talking about. Opinions from the formal analysis folks would be great. :-) > Said that, I want to clarify that I wouldn't necessarily object to an > improvement the situation for externally established PSKs. The issue I > see is that TLS1.3 already gives a "good enough" solution with re-using > the key, and I'm afraid we're going to have interoperation issues if > some implementations move to universal psks and some do not, defeating > the purpose of a standard. > I think that's the point of deciding this immediate question now, so we can get some text in the specification. If we decide to fix this, we'd instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs are configured and then, once the fixup document is published, implement it and remove the version logic. This is interoperable at all combinations as version negotiation runs first. Personally, I actually don't care much about 1.2 PSKs as I don't work with anything that uses them. I do care about allowing new protocols to use 1.3 external PSKs cleanly---new protocols can just mandate 1.3 and avoid 1.2, but the hash rule makes the whole thing unusable and it is unclear whether 1.3 PSKs will be usable in a future 1.4. I figured it'd be easy to patch the 1.2 issue while I was at it, thus the construction in my draft. But the exact derivation can be worked out separately, my draft or not. The immediate question is whether we think 1.2 PSKs should be reusable in 1.3 as-is or whether we should stick a derivation step to separate them. (Thanks, Ben, for making this thread. I failed to call out the immediate question in mine and then didn't had time to catch up on it.) David --000000000000cd5e9705716da2cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Jul 20= , 2018 at 7:39 AM Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
Said that, I want to clarify that I wouldn't necessarily object to an improvement the situation for externally established PSKs. The issue I
see is that TLS1.3 already gives a "good enough" solution with re= -using
the key, and I'm afraid we're going to have interoperation issues i= f
some implementations move to universal psks and some do not, defeating
the purpose of a standard.

I think that= 's the point of deciding this immediate question now, so we can get som= e text in the specification. If we decide to fix this, we'd instruct im= plementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs are configured a= nd then, once the fixup document is published, implement it and remove the = version logic. This is interoperable at all combinations as version negotia= tion runs first.

Personally, I actually don't = care much about 1.2 PSKs as I don't work with anything that uses them. = I do care about allowing new protocols to use 1.3 external PSKs cleanly---n= ew protocols can just mandate 1.3 and avoid 1.2, but the hash rule makes th= e whole thing unusable and it is unclear whether 1.3 PSKs will be usable in= a future 1.4. I figured it'd be easy=C2=A0to patch the 1.2 issue while= I was at it, thus the construction in my draft.

B= ut the exact derivation can be worked out separately, my draft or not. The = immediate question is whether we think 1.2 PSKs should be reusable in 1.3 a= s-is or whether we should stick a derivation step to separate them. (Thanks= , Ben, for making this thread. I failed to call out the immediate question = in mine and then didn't had time to catch up on it.)=C2=A0
David
--000000000000cd5e9705716da2cb-- From nobody Fri Jul 20 07:21:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FF9126BED for ; Fri, 20 Jul 2018 07:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX_rUCFTjCJp for ; Fri, 20 Jul 2018 07:21:12 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B223130E15 for ; Fri, 20 Jul 2018 07:21:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 1FDEE33792; Fri, 20 Jul 2018 17:21:10 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 6I44OR5_lWri; Fri, 20 Jul 2018 17:21:09 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 294D22308; Fri, 20 Jul 2018 17:21:04 +0300 (EEST) Date: Fri, 20 Jul 2018 17:21:04 +0300 From: Ilari Liusvaara To: David Benjamin Cc: Nikos Mavrogiannopoulos , "" , Benjamin Kaduk Message-ID: <20180720142104.GA27715@LK-Perkele-VII> References: <20180719230009.GD14551@akamai.com> <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 14:21:22 -0000 On Fri, Jul 20, 2018 at 08:42:47AM -0400, David Benjamin wrote: > > (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is > probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't > think we actually believe SHA256 and SHA384 give related output. It's just > nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA256 > actually a chance of misbehavior. Perhaps it's worth doing that analysis?) TLS 1.3 does this with PSK: HMAC(, PSK) And TLS 1.2 does: HMAC(, ) (where actually depends on ). Now, it is possible that there is second similar block in there, but that uses the same . However, noteworthy point is that there is only two ways to end up in situation where the effective key in TLS 1.2 is all zeroes: 1) is longer than hash block and is preimage of 0. Finding such thing is supposed to be infeasible. 2) The PSK is empty. However, the on TLS 1.2 side is not empty in this case (it starts with gunk from HMAC that involves at least both randoms). Also, empty PSK is not secure. The definition of HMAC is: H(C(key) XOR opad | H(C(key) XOR ipad, data)) Which preserves collision resistance on C(key) and data. Now, C(key) is not collision resistant. However, the only possible cases where C(key) can collide are the two above. So it seems to me that TLS 1.2 and TLS 1.3 compute independent things from PSK values, in all practical cases. -Ilari From nobody Fri Jul 20 07:54:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE95F1310BD for ; Fri, 20 Jul 2018 07:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=wizmail.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RqbTePXMc2Vg for ; Fri, 20 Jul 2018 07:54:52 -0700 (PDT) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C03131027 for ; Fri, 20 Jul 2018 07:54:51 -0700 (PDT) ARC-Seal: i=1; cv=none; a=rsa-sha256; d=wizmail.org; s=r201803; t=1532098491; b=L7NNQY0YiGXQOFiI5Lh+FzSROFYvQF+Rx47iIPe9D75vpKiaKN0h2xka86/rbz3ryum5dmLgsV kwCF4vOel3FoRM2AktQJuLuS6nOTW/eZg/DmxPOUX3fPXjNPNVWrBEIcza6ezFDpaPU7g08GP8 6hY2KZWKEBjmJrSnu4SVBMk=; ARC-Authentication-Results: i=1; wizmail.org; iprev=fail smtp.client-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=wizmail.org; s=r201803; t=1532098491; bh=TMadTVp2VKGK6qDbHRvgpCKDmaA7GUvTiozMQcZxLHQ=; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:DKIM-Signature; b=H8S3yP5T8oelSoJXvab7yGLKODOxPnNWRLoTPzakzPP9M0PxaEnUoOOnZVMLLNXcAJOh1HG5CI SzNTpaZ45yYNypnJr4IuwPYPDsQuZ9VFyldPbshjhlDk/0oPylgikQtYo4yv1jyNolBMBRzZiQ a8+w3OpGvMa1SMSW+snsXBw=; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=wizmail.org ; s=r201803; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:From:Sender:Reply-To: Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To: References:List-Id:List-Help:List-Unsubscribe:List-Subscribe:List-Post: List-Owner:List-Archive; bh=SEsKrNJZuKiIEckLc/l90+Xr/Lu2Uhju2r1tbW01etU=; b=A UNl7IJ1ERwrsP+Qn0uMV1pdY+eAwUIsP38mxJAyoUQ2bAz8FwP8IjxVr2hCpMyDmmU6sC7RNXI5ht yqKKzUhAbUsnJ6jPN3Bkdf1a8cyJfQb+iyj4Jt1244efwxaOlMRLJwH4lOhQq6RqDXA0cp2isYMI0 K8u4X23SpWfcWezA=; Authentication-Results: wizmail.org; iprev=fail smtp.client-ip=46.33.133.68; auth=pass (PLAIN) smtp.auth=jgh@wizmail.org Received: from [46.33.133.68] (helo=lap.dom.ain) from_AS 51561 by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91.105) id 1fgWnx-0007rj-Fd for tls@ietf.org (return-path ); Fri, 20 Jul 2018 14:54:49 +0000 To: tls@ietf.org References: <152934875755.3094.4484881874912460528.idtracker@ietfa.amsl.com> From: Jeremy Harris Openpgp: preference=signencrypt Autocrypt: addr=jgh@wizmail.org; prefer-encrypt=mutual; keydata= xsBNBFWABsQBCADTFfb9EHGGiDel/iFzU0ag1RuoHfL/09z1y7iQlLynOAQTRRNwCWezmqpD p6zDFOf1Ldp0EdEQtUXva5g2lm3o56o+mnXrEQr11uZIcsfGIck7yV/y/17I7ApgXMPg/mcj ifOTM9C7+Ptghf3jUhj4ErYMFQLelBGEZZifnnAoHLOEAH70DENCI08PfYRRG6lZDB09nPW7 vVG8RbRUWjQyxQUWwXuq4gQohSFDqF4NE8zDHE/DgPJ/yFy+wFr2ab90DsE7vOYb42y95keK tTBp98/Y7/2xbzi8EYrXC+291dwZELMHnYLF5sO/fDcrDdwrde2cbZ+wtpJwtSYPNvVxABEB AAHNJkplcmVteSBIYXJyaXMgKG5vbmUpIDxqZ2hAd2l6bWFpbC5vcmc+wsB7BBMBAgAlAhsD BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAUCVYAYBAIZAQAKCRC85YyM5B8y34iFB/9wozIY RogNdY1aejFFixb6++y4b1riyjMvWEULeEzDlQ0lMT6Z3PxXhZILD4y4aP7Kzx0ozXa5qaKy 41EAPKQoPipnRAH04QytJbIERvz8Tot/LeCVKUc0G9DVxOPBD03czTgqgz4EjV2qvnLF+rTU 0YBevrNCluKosGSd+3RvLWVu0hBhn9pELKfXJNSQXZb+TpHDhSDZ/gCrglBEOhA6YWbDb/4g z+5TFKdk+B++iAQZSHv7zISabjN+BPYgI47A+MU4JycoXaAUnMc0l5ba6fGNaIrzruE4aAZr lP5o+7mlU9Mm0QJqdqYxYPAiplJGrZv+YXH1fp5ueEK3l+NGzsBNBFWABsQBCADphLHaKToR uR/E7THerBiCjDatwCaETOKOTY2zRBQpaQ32p/F2XIGLS8Cc27+grZSKQ6ZX0ZN47O+AFyFH F8DH90IXZFpJR3Rb8zgXT8jnLX08DM31eECZHnRzFhGlOmq6WAUlqB3GKCPUCY2c4eTRXyoX LteTxrXCYoj45y/YmvlZrlonBNjPBAyHiO/LNz+V7fZtNsN7N/XGrnLbcdNfNd+SD1ENmbLJ 8RvyymxguTyB/ka9JdjHHIoQEJ6L166B3hhfCHpt8iC0GPZkti9IMl0NoJ029jJm3Jq1qEce EBn5H5QMGn6Fq64iXwTsO1TMNUwpWx8pjvV7wVIxjI8ZABEBAAHCwF8EGAECAAkFAlWABsQC GwwACgkQvOWMjOQfMt9N6Af8CS2CTrMQFdhkGEtBXmL4ifD8UHFkBRBGmM8ZL2fWUBTZXT8m rdRMOK6tcPnKWaCvWvKr0knt970j/DyAgFmH8hgOi3yctigFecVDjjilAeCJMq38s1tYKYiL DbBdHWtdkA9uHZwq3lfd3QxcEEO3QamQF+dO7h8gAOXlG+po87Hm+E0wz4swIB8+S37Jzrx9 uu0LSFDfJCTK+TIKGa5Un8LxPxyq9WnnNDh72zK7BiRidk/s40KcNod83NM4Hn/sbGfyLa8s S0F3ME0S+ocSMOiu/ZHHOiwpLYNbwTJ7stZxGsrguWeT9P+amxbA/YlK95LedstwvN+WcHZ7 d++Arg== Message-ID: Date: Fri, 20 Jul 2018 15:54:47 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [46.33.133.68] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-moriarty-tls-oldversions-diediedie-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 14:54:54 -0000 On 07/09/2018 05:40 PM, Kathleen Moriarty wrote: > Stephen and I posted the draft below to see if the TLS working group > is ready to take steps to deprecate TLSv1.0 and TLSv1.1. There has > been a recent drop off in usage for web applications due to the PCI > Council recommendation to move off TLSv1.0, with a recommendation to > go to TLSv1.2 by June 30th. NIST has also been recommending TLSv1.2 > as a baseline. Applications other than those using HTTP may not have > had the same reduction in usage. If you are responsible for services > where you have a reasonable vantage point to gather and share > statistics to assess usage further, that could be helpful for the > discussion. I have access to stats from a small UK-based ESP. Of the inbound: SMTP connections in plaintext: 15% Of TLS: SMTP using TLS version prior to 1.2 : 20% SMTP using TLSv1.1 : 0.03% I note specifically that Facebook notification mails use TLSv1.0 -- Cheers, Jeremy From nobody Fri Jul 20 08:42:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B144130EB0 for ; Fri, 20 Jul 2018 08:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=superlogica.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhfm-4teFYEh for ; Fri, 20 Jul 2018 08:42:00 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3404130E02 for ; Fri, 20 Jul 2018 08:42:00 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id b66-v6so6454103qkj.1 for ; Fri, 20 Jul 2018 08:42:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=superlogica.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=gCS48hsjVBJfQdlLnyMkzZlyFOS9isCnB+fQvdqo+jo=; b=iR0/Tt9jfZgW/l7riVMBUJX0zlNVY6sdGRdmSpqHkt95K//pQamHSKd1Pp5Ce4sMq4 jSNKxLeBvCgBHB1WZEzQP7DV1cBduVI9lTUHlmIOWMNnuDR9KYR3EqEJqgd48OFjAqiZ oMJsAuqIB5LEkxS/hSrbuMvm4JuTbcvGqlOGE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=gCS48hsjVBJfQdlLnyMkzZlyFOS9isCnB+fQvdqo+jo=; b=Im/PNUjkVsPUBppXkg9ni5VGEAK0GOfEjvQAlN848ZdemOMA+FYteYb3pbkC6Xvz48 5IqPGyWq+1pwVHTBPsouTMcNmogJhxKSZSb3mAvdoYiyFDGpThbIq1IWY4sKsSXgDGE5 BRGI4ywn9deS0f6RI5xV7JqvmwpUqlKq+W5Kl2kI69ynRpkNg1zpvE9u0o3U+XQaB93g me0MEKwhQkT4NNqe0M42G9ibb0jCGjKpfud1FAvNj6CebXyaMA9rc7vAhEVVhG7svEmz DRdetDQUhPmaRnaLU0f2lKOvKrFgBB5/BLDky0LMT6p4sYldcN5+YKd418EP5UJj0xjo X0Cg== X-Gm-Message-State: AOUpUlFpne2Nc25UYgk8ddRjU3aUs7mB4I+OiG3m64zzBz6uK4lNrwGL WW/x6vBhPjT9iv9Gk/yO6McdQn0UkxqDwmqji+kfht0l7Vk= X-Google-Smtp-Source: AAOMgpc/UQjdg7K35xjBK4JoPyqCWzRVxazIHEw6wEW+Uc9PAnUAacKVy2nPuyMymkFyT14dd5KFlKmnH7EZ7YUv560= X-Received: by 2002:a37:8103:: with SMTP id c3-v6mr2284727qkd.246.1532101319378; Fri, 20 Jul 2018 08:41:59 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Walter Neto Date: Fri, 20 Jul 2018 12:41:23 -0300 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Doubts about a solution or new service/protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 15:42:04 -0000 Hi guys, after I saw I did not express myself clearly I decided to write this message trying to do that. The actors: A - The business company that needs to emitt the invoice; B - The Brazilian Internal Revenue Service, who requires "A" to emit invoices using "B" webservices; C - The software company that emits the invoice for company "A" through "B" webservices. The current Brazilian common model: "A" pass to "C" his certificate who uses it to sign and communicate it through "C" webservices. For me here we have a serious security problem, once this private keys is shared between "B" employees. My proposal: To exist a service that TLS Client implementations consume to make the tasks who only the certificate private key detainer can do. Does this proposal make sense? Regards, On Mon, Jul 16, 2018 at 3:30 PM Walter Neto wrote: > > Sorry Ted, I think I was not so clear. > > We use https (http over tls) to transmit this invoice files and I think it will > be great if we have the option on the tls protocol to ask another service to > encrypt things to it, without having the certificate (with private key). > > On Mon, Jul 16, 2018 at 1:50 PM Ted Lemon wrote: > > > > Why do you need to extend tls to do this? Why not just use it for encapsulation? What you are describing sounds more like pgp than tls. > > > > On Mon, Jul 16, 2018 at 12:15 PM Walter Neto wrote: > >> > >> Hi IETF tls list, > >> > >> I have some problem to solve I believe it is good to make my questions and > >> proposals here. > >> > >> I'm from Brazil, here we need to use X.509 certificates to sign electronic > >> invoices XMLs and to communicate this XMLs through https. > >> > >> The problem is that the most of emitters pass their certificates (with private > >> and public keys) to the software companies that communicate this invoices, what > >> in my point of view it is so insecure, the other problem is that generate a > >> certificate to the software company authorized to emmit the invoice is so > >> bureaucratic. > >> > >> My proposal is to create a service that generates tokens to third applications > >> use this service to sign, and encrypt data without the certificate, and > >> introduce an option in the tls protocol to pass the token and the service > >> address to use it when don't have local cert files. > >> > >> Does it make sense? > >> > >> -- > >> Walter Neto > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls -- -- Walter Neto From nobody Fri Jul 20 08:51:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3E2131170 for ; Fri, 20 Jul 2018 08:51:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Qn9PZyOvafB for ; Fri, 20 Jul 2018 08:51:34 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419911310E8 for ; Fri, 20 Jul 2018 08:51:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 0E0EC4751E; Fri, 20 Jul 2018 18:51:32 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id fbtlk324YeV7; Fri, 20 Jul 2018 18:51:31 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 548C873; Fri, 20 Jul 2018 18:51:28 +0300 (EEST) Date: Fri, 20 Jul 2018 18:51:27 +0300 From: Ilari Liusvaara To: "Patton,Christopher J" Cc: Santosh Chokhani , "tls@ietf.org" Message-ID: <20180720155127.GA28236@LK-Perkele-VII> References: <20180718065616.GA18428@LK-Perkele-VII> <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> <20180719193938.GA24141@LK-Perkele-VII> <20180719201846.GA24678@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.0 (2018-05-17) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 15:51:37 -0000 On Thu, Jul 19, 2018 at 08:39:11PM +0000, Patton,Christopher J wrote: > > Now let's check the converse. Suppose that the crit=true. Is it valid > for strict to be false? Yes, because the extension being critical > only means that the client has to understand DC in order to accept > the certificate. But this doesn't mean they must negotiate a DC. It might have well-defined technical meanining, but I consider it nonsensical. Because it means that if client does not understand DC, it must reject the certificate, but if client understands DC, it can accept it even in non-DC contexts. The other mismatch case also has well-defined technical meaning, it means that client that does not understand DC can use the certificate, but client that understands DC can only use it in DC context. I do not consider either of these two cases sensible. -Ilari From nobody Fri Jul 20 08:53:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17594131001 for ; Fri, 20 Jul 2018 08:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stCVokbHd5Lm for ; Fri, 20 Jul 2018 08:53:53 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id 5687212F1A2 for ; Fri, 20 Jul 2018 08:53:53 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id w6KFroYL021682; Fri, 20 Jul 2018 11:53:52 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Walter Neto CC: "tls@ietf.org" Thread-Topic: [TLS] Doubts about a solution or new service/protocol Thread-Index: AQHUHSBH85BMLt7RPkKLhEl36ytWK6SSUv+AgAAcEwCABhn0gIAAA3eA Date: Fri, 20 Jul 2018 15:53:49 +0000 Message-ID: <70F32E16-B52E-4F13-A7CA-FEE83D95267C@ll.mit.edu> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-3265D0B7-600C-4B65-846E-2DCD4DF800E6"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-20_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807200177 Archived-At: Subject: Re: [TLS] Doubts about a solution or new service/protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 15:53:56 -0000 --Apple-Mail-3265D0B7-600C-4B65-846E-2DCD4DF800E6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable IMHO no it doesn't. TLS is just a way to provide secure pipes between the co= mmunicating entities. Making long-term signatures that persist after the con= nection is dropped had never been on the site of TLS. Regards, Uri Sent from my iPhone > On Jul 20, 2018, at 11:42, Walter Neto wrote= : >=20 > Hi guys, after I saw I did not express myself clearly I decided to write t= his > message trying to do that. >=20 > The actors: > A - The business company that needs to emitt the invoice; > B - The Brazilian Internal Revenue Service, who requires "A" to emit invoi= ces > using "B" webservices; > C - The software company that emits the invoice for company "A" through "B= " > webservices. >=20 > The current Brazilian common model: >=20 > "A" pass to "C" his certificate who uses it to sign and communicate it thr= ough > "C" webservices. >=20 > For me here we have a serious security problem, once this private keys is s= hared > between "B" employees. >=20 > My proposal: >=20 > To exist a service that TLS Client implementations consume to make the tas= ks who > only the certificate private key detainer can do. >=20 > Does this proposal make sense? >=20 > Regards, >> On Mon, Jul 16, 2018 at 3:30 PM Walter Neto = wrote: >>=20 >> Sorry Ted, I think I was not so clear. >>=20 >> We use https (http over tls) to transmit this invoice files and I think i= t will >> be great if we have the option on the tls protocol to ask another service= to >> encrypt things to it, without having the certificate (with private key). >>=20 >>> On Mon, Jul 16, 2018 at 1:50 PM Ted Lemon wrote: >>>=20 >>> Why do you need to extend tls to do this? Why not just use it for encap= sulation? What you are describing sounds more like pgp than tls. >>>=20 >>>> On Mon, Jul 16, 2018 at 12:15 PM Walter Neto wrote: >>>>=20 >>>> Hi IETF tls list, >>>>=20 >>>> I have some problem to solve I believe it is good to make my questions a= nd >>>> proposals here. >>>>=20 >>>> I'm from Brazil, here we need to use X.509 certificates to sign electro= nic >>>> invoices XMLs and to communicate this XMLs through https. >>>>=20 >>>> The problem is that the most of emitters pass their certificates (with p= rivate >>>> and public keys) to the software companies that communicate this invoic= es, what >>>> in my point of view it is so insecure, the other problem is that genera= te a >>>> certificate to the software company authorized to emmit the invoice is s= o >>>> bureaucratic. >>>>=20 >>>> My proposal is to create a service that generates tokens to third appli= cations >>>> use this service to sign, and encrypt data without the certificate, and= >>>> introduce an option in the tls protocol to pass the token and the servi= ce >>>> address to use it when don't have local cert files. >>>>=20 >>>> Does it make sense? >>>>=20 >>>> -- >>>> Walter Neto >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 > --=20 > -- > Walter Neto >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-3265D0B7-600C-4B65-846E-2DCD4DF800E6 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITojCCBLww ggOkoAMCAQICASkwDQYJKoZIhvcNAQEFBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0xMzEyMTcwMDAwMDBaFw0yMDEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaMFJ1bXy25bW03EbqHwHSSpyQVlAAC2gc KS9SlQRfqMW8F3yZAjncbIthG4CjgdYml7v+LMVc59IkOzpQzmi+8I59eDZsmANiUEL0kNwsEUif Semk671G+mNZKLG0LnpyvAnlSzlA923G0p16TksleXagrDfDyWKFSLF49vFZp3WbtkwopqC+b3NP Js/oW6YpHF5gmNKkHb5wBiOgYYRtJUfLHy7MebrECgEwfFrxvL7IPPwnOTqw/2KKWA/eJdIagICa HIHO+VBDlA01Y/4Saj2PP+6QqFhUH9XB3G2iq48CqfiJ8MAhoz121vTlzLWBcAVI/dn+JSTHIFll Q5F/AgMBAAGjggGaMIIBljASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBTXYGYOe0mNdUwN /c9G3sjHEofKvzAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDAzBgNVHR8E LDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYow gYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcS AgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZI hvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQEFBQADggEBACx/0cGfvapTtROCTFqu MBzuLKeFwMSBbB7Ngq139IsZJDQOG3MhX8tMLGpQuM534f4dOowlcHz6cefOHKpDjdGycZk4VPlF /M+H3h1v9kneqXbjgPCUkjvJcEDYORlwQSA5YL1sdysSXNTo2eKBqFJbmh1UmuGYf9eFABwxLvsT kfrbLLErVY8+BwGKkZWe7XFIdtOId7sOp9ZDa1UwtR/bddiEi5r3iQmxB3iNKHvU1UPR7sXiycCi pAwj3wzMNh4s6SOXMpGzvuv9oyw8ArHqcxo69EvsLLQ+OnnWLaoWRsaZfyh+eHaR6uNNO9En+Dba vUxXxFHU+S2Myw06w98wggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNV BAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMw EQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18 tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5o vvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8li hUixePbxWad1m7ZMKKagvm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+ yDz8Jzk6sP9iilgP3iXSGoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9 dtb05cy1gXAFSP3Z/iUkxyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHQ4EFgQU12BmDntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3y EMND7SkwDgYDVR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDov L2NybC5sbC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5t aXQuZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqG SIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0G CyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUA A4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqM JXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6Nni gahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua 94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2q FkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPfMIIE7TCCA9WgAwIBAgIKMziUjwAAAABu ljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDExNDE3MzAz OVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExh Ym9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1 ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDjFDaGib07mHBdNaVMNpj9+4iJa+K9 AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C8XyG43suSfpNp/owLOUElFagAnPqHAvAUIws l5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg+P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK 1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjHYFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpK SFq80SEh6cMDLdTe1ZAjWxsnbyKC64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGe kpQVubK9AgMBAAGjggG1MIIBsTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0P AQH/BAQDAgUgMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0G CCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGG G2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVy aUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBTAFcwDQYJ KoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rVScRPHe2SMUaF H5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqgMd121bqzR3WY84Lc osfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pLd5zPvywRNhTgoVe1aN4i vIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp+4V/XhMZRhxQJ3DjVTjh9Q/p HKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mLMLqGNX3azAkwggUtMIIEFaADAgEC AgoadMQgAAAAAK0DMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMwHhcN MTcwMzAxMTgyNTA2WhcNMjAxMjMxMjM1OTU5WjBsMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVvcGxlMSswKQYDVQQDEyJCbHVtZW50aGFs LlVyaS41MDAxMDU4NCAoTW9iaWxpdHkpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA g+8bBB+jySfGyqx/fL9a596qTeq9fGfYXI2yJEZqLzJazzV1u6oLToMnJQ6phCIkQGplPsM+9Ppz Icw5nN8GahHPU6FXXT3BSr6/bny4hftGu05y/n/DWWlPkos6PhSNAB8WG3L+6a3mHcp9yYumPkdt M20+08oiU9S6OhFr6BoFFoeFjKEcFhvvovm9GcRzQ3g1cXHore5p6umBCLGxZi0cGhBI/7ZyJmJU Uo50bAPKdpURqYSsgU7p6GxCgpIcZBUlTxCSliPO/0TqiBMZ857MF4OcehpG7LuxufD0p+g02uX7 Z0aIfYnGHlkm3Y7NgvF6lW2WxCPklqKakb2fuwIDAQABo4IB6jCCAeYwHQYDVR0OBBYEFPbiFDP7 1vJBmRLhxtKU/CWESr+tMA4GA1UdDwEB/wQEAwIGwDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G 3sjHEofKvzAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xM Q0EzMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dl dHRvL0xMQ0EzMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYB BAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhYHgQIbXxk0CAWQCAQkw LAYDVR0lAQH/BCIwIAYIKwYBBQUHAwQGCisGAQQBgjcKAwwGCCsGAQUFBwMCMBgGA1UdIAQRMA8w DQYLKoZIhvcSAgEDAQgwQQYDVR0RBDowOIEOdXJpQGxsLm1pdC5lZHWgJgYKKwYBBAGCNxQCA6AY DBZVUjIwOTgwQG1pdGxsLmFkLmxvY2FsMC0GCSsGAQQBgjcUAgQgHh4ATABMAE0AbwBiAGkAbABl AFMAaQBnAEEAdQB0AGgwDQYJKoZIhvcNAQELBQADggEBADbiZo1DkfqhBA4LYklB+i49k6dh7L+n DEg3WdeZ/CRZAon9G3hPsUWd5YIsufRpoYUVJABcVos87kXZmkF1RjH8vLNFOEV8ZVcNxbWC5DiA 6dTswIEhXMSHFuyp3tERvu2z6+f9FC4jvZttYyLyirBJC4KwP/AOLm42Gn4lLeNrY4Ex8nq2Ah3x jB+QqvpxD2k1aaoR0fWaDxv2ZrdaFR43x2MTkiee+wR1diZ7GA7G/HyJg9MUukKq23qm6Ys0VJQc JsKU1Q2/TLL99FRRa18ourBvFwJzcllLhTcqnvbawWt6cYEvGIJ9Dszxz7LQECXI0KrPpM7x32Su lMJjt1YxggLJMIICxQIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBM YWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCChp0xCAAAAAArQMw CQYFKw4DAhoFAKCCAT8wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTgwNzIwMTU1MzQ3WjAjBgkqhkiG9w0BCQQxFgQUcOv1RjilYw6KhOSy6qyrfwLmwEAwbgYJKwYB BAGCNxAEMWEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMHAGCyqGSIb3 DQEJEAILMWGgXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgozOJSPAAAAAG6WMA0GCSqGSIb3 DQEBAQUABIIBAEj74/dqvJGK3pdL9+mxrXSvWcLn49kaTM6mSw5gBYRs3AJQ20PLLfTvHCqjzkMX pSDFZWF56D8hbe46MnyQ/jBK630+M9OoslXH0YOIOnt3981dsQ+OMcmR1yvpehoHyCTczE3KNTx1 qmjX1KsQs6/nc6Wy+iWMtWcingbNV2kEC7ChUbb0/nCjvf03VM69rh9Kzp6hHQTftMMp+fvmUYd3 03OP7T9OVkoFmdj2uDY2aEImVetAt+SIzf0X3rtGbKX/iZes2SYn5LXHLSFOfOn31v/XWM4jDhN0 FkB3i8lLsocD3Y5R02axRAHXUwslhlXZz3VCRHnmsBp9ymAjRicAAAAAAAA= --Apple-Mail-3265D0B7-600C-4B65-846E-2DCD4DF800E6-- From nobody Fri Jul 20 10:30:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C38130F74 for ; Fri, 20 Jul 2018 10:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MA6bq02sVi1t for ; Fri, 20 Jul 2018 10:30:30 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66F00130F90 for ; Fri, 20 Jul 2018 10:30:30 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A2EC04075622; Fri, 20 Jul 2018 17:30:29 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-200-46.brq.redhat.com [10.40.200.46]) by smtp.corp.redhat.com (Postfix) with ESMTP id CAD647C2B; Fri, 20 Jul 2018 17:30:27 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Fri, 20 Jul 2018 19:30:19 +0200 Message-ID: <2794700.6u4tZpJgc5@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5398721.VofQCH7KDB"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 20 Jul 2018 17:30:29 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Fri, 20 Jul 2018 17:30:29 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Doubts about a solution or new service/protocol X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 17:30:33 -0000 --nextPart5398721.VofQCH7KDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 20 July 2018 17:41:23 CEST Walter Neto wrote: > Hi guys, after I saw I did not express myself clearly I decided to write > this message trying to do that. >=20 > The actors: > A - The business company that needs to emitt the invoice; > B - The Brazilian Internal Revenue Service, who requires "A" to emit > invoices using "B" webservices; > C - The software company that emits the invoice for company "A" through "= B" > webservices. >=20 > The current Brazilian common model: >=20 > "A" pass to "C" his certificate who uses it to sign and communicate it > through "C" webservices. >=20 > For me here we have a serious security problem, once this private keys is > shared between "B" employees. yes it is > My proposal: >=20 > To exist a service that TLS Client implementations consume to make the ta= sks > who only the certificate private key detainer can do. TLS client certificates sign just the handshake, they don't sign the conten= ts=20 of the exchanged messages, both the client and the server have keys that ca= n=20 be used to create messages looking as if they were created by either side o= f=20 connection, so you can't say if the messages were created by an "evil" serv= er,=20 or are genuine worse still, as the exchanged data is authenticated either with HMAC or som= e=20 form of AEAD tag (so symmetric crypto), when you are able to verify the=20 messages as genuine, you also are able to forge them so no, TLS itself is not the technology that can be used to solve this =20 > Regards, >=20 > On Mon, Jul 16, 2018 at 3:30 PM Walter Neto = =20 wrote: > > Sorry Ted, I think I was not so clear. > >=20 > > We use https (http over tls) to transmit this invoice files and I think= it > > will be great if we have the option on the tls protocol to ask another > > service to encrypt things to it, without having the certificate (with > > private key).>=20 > > On Mon, Jul 16, 2018 at 1:50 PM Ted Lemon wrote: > > > Why do you need to extend tls to do this? Why not just use it for > > > encapsulation? What you are describing sounds more like pgp than tls= =2E>=20 >=20 > > > On Mon, Jul 16, 2018 at 12:15 PM Walter Neto=20 wrote: > > >> Hi IETF tls list, > > >>=20 > > >> I have some problem to solve I believe it is good to make my questio= ns > > >> and > > >> proposals here. > > >>=20 > > >> I'm from Brazil, here we need to use X.509 certificates to sign > > >> electronic > > >> invoices XMLs and to communicate this XMLs through https. > > >>=20 > > >> The problem is that the most of emitters pass their certificates (wi= th > > >> private and public keys) to the software companies that communicate > > >> this invoices, what in my point of view it is so insecure, the other > > >> problem is that generate a certificate to the software company > > >> authorized to emmit the invoice is so bureaucratic. > > >>=20 > > >> My proposal is to create a service that generates tokens to third > > >> applications use this service to sign, and encrypt data without the > > >> certificate, and introduce an option in the tls protocol to pass the > > >> token and the service address to use it when don't have local cert > > >> files. > > >>=20 > > >> Does it make sense? > > >>=20 > > >> -- > > >> Walter Neto > > >>=20 > > >> _______________________________________________ > > >> TLS mailing list > > >> TLS@ietf.org > > >> https://www.ietf.org/mailman/listinfo/tls =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart5398721.VofQCH7KDB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltSHCsACgkQkqjRuAHS 9fWpBA/+LsUPohBMpfY8nfeqKn+0os7pnmi/B6eFiihiOiBnjV+imdVfBwc8UGW9 SUlYuEY2qx70Q9ZwrkCo/Sn5WBDUbN5a/inVX7gBmTWf5jSn+DDq9h8xFl/Q+UEM reqXg/LbGjfJxusTTXJb3S5V84yxoTCaNMRT44aCsSsGrXMVK36RFfELiv4ZKNv7 g2F/oCchAB9Rn7tADdoO7O6AILGbq4LyoNYW3isQWncIaceAeAJAjqCrioJDFlez LGY1zrSxWOAZL+GKr4ScCOy8MhurJ+GMnAM0nKIg349A1hEbZhAgccFUMfWQH/do GzhebkSNFKyOLeNYzlYYBgbxyrFQFspSlwsBRsBgTIDYW1rcCJIVC+NWCugzErb6 b+M3k5CCdVe8CsBMAFcOIjZo6tvGeozenu2JxyJJbPla4dZGkP5Gchnwbn38RegL mkXvof/PapO8Rf9jaR9AVfzcSFoO6/Ist+V553b5NAkBrLijzaG3J3XozDMYBdu/ 2Nzm/bQI2ooHPWEO0h2ChFDnFZlspfr+Aqx/bnSRopeUwyInMV1N9ktTMRB/CWsN 0NLl5TU3ZwtiMhHGTVem6BgMu50UxQuFotSrrItViHQ9Z0Pi2zJf2tIUTfbL5UH5 ofUBVNC5ZR4SqjhnluAYrc+dICQLhQiL8gxWrBWbhET7tM9Ttb4= =cQhK -----END PGP SIGNATURE----- --nextPart5398721.VofQCH7KDB-- From nobody Fri Jul 20 11:41:27 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54CE130DCE for ; Fri, 20 Jul 2018 11:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJ5V17hoa7Oj for ; Fri, 20 Jul 2018 11:41:22 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod05.osg.ufl.edu [128.227.74.125]) (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 D69BB130DF1 for ; Fri, 20 Jul 2018 11:41:20 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.35 Received: from exmbxprd04.ad.ufl.edu ([10.36.133.35]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w6KIfHfM013626 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Fri, 20 Jul 2018 14:41:17 -0400 Received: from exmbxprd21.ad.ufl.edu (128.227.145.166) by exmbxprd04.ad.ufl.edu (10.36.133.35) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 20 Jul 2018 14:41:16 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd21.ad.ufl.edu (128.227.145.166) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Fri, 20 Jul 2018 14:41:17 -0400 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (216.32.181.24) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Fri, 20 Jul 2018 14:41:16 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHSPR00MB239.namprd22.prod.outlook.com (10.172.56.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Fri, 20 Jul 2018 18:41:14 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f%2]) with mapi id 15.20.0973.018; Fri, 20 Jul 2018 18:41:14 +0000 From: "Patton,Christopher J" To: Ilari Liusvaara CC: Santosh Chokhani , "tls@ietf.org" Thread-Topic: [TLS] Proposed changes to draft-ietf-tls-subcerts Thread-Index: AQHUHjQqsE1M6CF49EGVkJJk0Fkh4aSUjG8AgACw7A+AAEu7AIABYHq/gAAKfACAAAOdc4AAB1IAgAABKuKAAUZ7gIAAJjiB Date: Fri, 20 Jul 2018 18:41:14 +0000 Message-ID: References: <20180718065616.GA18428@LK-Perkele-VII> <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> <20180719193938.GA24141@LK-Perkele-VII> <20180719201846.GA24678@LK-Perkele-VII> , <20180720155127.GA28236@LK-Perkele-VII> In-Reply-To: <20180720155127.GA28236@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8210:ece5:7036:b6dd:4745] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHSPR00MB239; 6:7COJoyEiHehAoczuAkt9klEzteat+dvQh9PUzHVa+Li4yOanjGJzYyzFyVUfgDGYogS61HKxxBDDTo9+CHZbiUKu+8MsVUdUJMf6IoQPRzrJ87nSL4uKuSWa6pvDSrHC+dR4uyzzf4MwkzK65GGicKobMqiZ6ZhfIs5mpfmn+dJXUhQBEK2MsyRoYg9Epu8H0YgkcIu07X++4xWIN3U63dc96K8T/68OpweEE33UbIU+okMPVOF9gBAmTowPW4tGnKd+6ITHcv16DLuoWC04Y1H7DM3hh22dw/alRztW6TdvBm14y8Rg395/Xf+QvS3A58tzqGZ2Sh9aORrGvQL5R8laO3IK6D386L0XEwzVQ/EyRIyuE6E0qii0sInLKCKCqyQHQJGu4AGgmdUlqKdTs8XO8dSXtXQQ13X1q5Ps88uMfGrlxh8/O02qYDBVOBj8XYfrHdh7t1zNAfo+kH4JcQ==; 5:/dGW83OUhnhfoa+ZT4R/9qd7QcRSCVcNNB+rm5+cyebz80kSpVxVtgrEGvSafX/2+LB/ykxDQskI+yHzrEjKHfT6mOC6xi+YhQb74bBwNt/C21XsrSiqhgKHxQu70lp2thTf/E5L5H7rRMDmTnMp1l2dBuQg8YhmSnEGeJ3WL/M=; 7:glDAJnR6EhOahhKP96jbYa0y1xPPmaHxHj5HK3l4T24up5h60fschP9mM/rckWd/62ETV7le0uYN0SUqpGSYSjMPsphncHUQptfEeTsp/XA0Y5fFWFMBqQr3skH8jB5ZI7SF9xo+9Y9Swk0tF8NjT8hv8z9UsrBgl+azQWmYXPRbf7n4dkwLkYjrSKEW5vdeLY4SD0u7sb6vwomG04dJSqY9ipt/qJ5+3CNZOQM/5ebGPm8C9bQ8NAPL35+uJNBG x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: aa42dfdf-5d47-420f-0b9b-08d5ee705f56 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600067)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHSPR00MB239; x-ms-traffictypediagnostic: MWHSPR00MB239: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MWHSPR00MB239; BCL:0; PCL:0; RULEID:; SRVR:MWHSPR00MB239; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(396003)(136003)(39860400002)(189003)(199004)(81156014)(25786009)(81166006)(88552002)(476003)(33656002)(478600001)(486006)(14454004)(4326008)(53936002)(8676002)(6246003)(97736004)(39060400002)(105586002)(2906002)(11346002)(19627405001)(5250100002)(446003)(99286004)(76176011)(8936002)(106356001)(2900100001)(68736007)(9686003)(7696005)(55016002)(316002)(786003)(54906003)(6436002)(54896002)(93886005)(5660300001)(74316002)(186003)(14444005)(6116002)(229853002)(256004)(6916009)(102836004)(6606003)(75432002)(6506007)(7736002)(46003)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHSPR00MB239; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: jhfFmk3nxhQbyCWYP9l0P2PUQVpPCxVVP0wvYlHC/NjRlyJr7Vd5yW4/2pg/0zRJyqrtkvRxZ7lh+mr3rgnjA5Fj9s73KoQWTpnFIwZa4P1U+efPQ9FdlUn763XqIimeTYmuRdlOBC1oT3rITfDYEtYy5zLvtIz3015Yd1WwZT8e18gTtMR39Uhb+QiAVM+2lDk0QqMFmJxUFX3xnvYDqx2MA6GfQOfZWmkVcebQX1IcZfs7BqXz9ACI+klzahPxjujoOv6DBE/uXhJpUpjkPSesb1vBJQ4fFIEG0YCabK7iVO37JUH1OmiEjskqdGlbYQkLNx03swhpEYn0QTqVLvffQ/HCuO/g4Zsfc7oHJfc= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB046126F4302517E7A8871E2DC6510MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aa42dfdf-5d47-420f-0b9b-08d5ee705f56 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 18:41:14.1481 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHSPR00MB239 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-20_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=728 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807200206 X-UFL-Spam-Level: * Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 18:41:26 -0000 --_000_MWHPR22MB046126F4302517E7A8871E2DC6510MWHPR22MB0461namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Because it means that if the client does not understand DC, then it must = reject the certificate, ... This is the desired behavior, as far as I understand. > ... but if client understands DC, it can accept it even in non-DC context= s. I don't see why this is nonsensical. One way to understand this is that the= server is presenting a certificate that it only wants to use with DC-capab= le clients. Perhaps noone would want to actually use this configuration, bu= t I don't see why it should be deemed invalid. > The other mismatch case also has well-defined technical meaning, it > means that client that does not understand DC can use the certificate, > but client that understands DC can only use it in DC context. I don't quite understand. The issue I believe you pointed out is that when = the extension is non-critical, but the strict flag is set, the server will = be compelled to serve a DC even if the client doesn't support it. The relev= ant text (you'll have to look at the source on GitHub) is: "The extension M= AY be marked crititcal. (See Section 4.2 of [RFC5280].) If the strict boole= an is set to true, then the server MUST use delegated credential in the han= dshake; if no delegated credential is offered, then the client MUST abort t= he handshake with an =93illegal_parameter=94 alert." A client who doesn't s= peak DC will either abort with an "unexpected_message" alert, or if it igno= res the extension, then verification of the handshake will fail, since it's= using the end-entity certificate public key, and not the DC public key. Thus, I believe the only valid configurations are: * strict=3Dtrue, crit=3Dtrue; * strict=3Dfalse, crit=3Dtrue; and * strict=3Dfalse, crit=3Dfalse. The revised text should be: "If the strict boolean is set to true, then the extension MUST be marked cr= itical; otherwise it MAY be marked non-crititcal. If the strict boolean is = set to true, then the server MUST use delegated credential in the handshake= ; if no delegated credential is offered, then the client MUST abort the han= dshake with an =93illegal_parameter=94 alert. -Chris --_000_MWHPR22MB046126F4302517E7A8871E2DC6510MWHPR22MB0461namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

> Because it means that if the cli= ent does not understand DC, then it must reject the certificate, ...=

This is the desired behavior, as far as I = understand.

> ... but if client = understands DC, it can accept it even in non-DC contexts.
I= don't see why this is nonsensical. One way to understand this is that = ;the server is presenting a certificate that it only wants to use with DC-c= apable clients. Perhaps noone would want to actually use this configuration, but I don't see why it should be deemed i= nvalid.

> The other mismatch case also has well-defined technical meaning, = it
> means that client that does not understand DC can use the certifi= cate,
> but client that understands DC can only use it in DC context.
I don't quite understand. The issue I believe you pointed out is that when = the extension is non-critical, but the strict flag is set, the server = will be compelled to serve a DC even if the client doesn't support it. The = relevant text (you'll have to look at the source on GitHub) is: "The extension MAY be marked crititcal. (See Section 4.2 of [RFC5280]= .) If the strict boolean is set to true, then the server MUST use delegated= credential in the handshake; if no delegated credential is offered, then the client MUST abort the handshake with an =93illegal_pa= rameter=94 alert." A client who doesn't speak DC will either ab= ort with an "unexpected_message" alert, or if it ignores the exte= nsion, then verification of the handshake will fail, since it's using the end-entity certificate public key, and not the DC pub= lic key.

Thus, I believe the only valid configurati= ons are:
  • strict=3Dtrue, crit=3Dtrue;
  • strict=3Dfalse, crit=3Dtrue; and
  • strict=3Dfalse, crit=3Dfalse.

T= he revised text should be:
<= span>"If the strict boolean is set to true, then the extension MUST be= marked critical; otherwise it MAY be marked non-crititcal. If th= e strict boolean is set to true, then the server MUST use delegated credential in the handshake; if no delegated credential is o= ffered, then the client MUST abort the handshake with an =93illegal_paramet= er=94 alert.
<= span>
<= span>-Chris
<= br>
--_000_MWHPR22MB046126F4302517E7A8871E2DC6510MWHPR22MB0461namp_-- From nobody Fri Jul 20 12:52:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA23130EE6 for ; Fri, 20 Jul 2018 12:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=dXSQxlBP; dkim=pass (1024-bit key) header.d=ericsson.com header.b=LCZDtgoF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kjya4K8PEhmV for ; Fri, 20 Jul 2018 12:52:25 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DD7130E8A for ; Fri, 20 Jul 2018 12:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1532116342; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=l/OI8Fsb0HsHFun0mGAg4P4ug/6f1YNmdQdw85WNHz4=; b=dXSQxlBPRvq6PxAjhAn2WylFNs7p2kXrAxz08dWLLkp5c4hmNGX9wwVwAxfvEuK5 JYRRba1LermSXsLbcMsLIZLcnoOCdk1YKI18F4GSLFDvw1z2uyDQEYLhztj1FqSS qiSzgNga1vzfxgR2Q4nCJZ2RgNZzxaJQdo6WHTUczI8=; X-AuditID: c1b4fb2d-5ecb19c0000055ff-c7-5b523d76ff71 Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0F.E0.22015.67D325B5; Fri, 20 Jul 2018 21:52:22 +0200 (CEST) Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Fri, 20 Jul 2018 21:52:01 +0200 Received: from EUR02-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Fri, 20 Jul 2018 21:52:01 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=l/OI8Fsb0HsHFun0mGAg4P4ug/6f1YNmdQdw85WNHz4=; b=LCZDtgoF+urgm8/otGvjn7n/GSgOpjV3v6/Yt+tHsuPFh3wqII8fMkPPwtT1qPyH5ZShkQv1IdSia/YMJc6nbj65miSiuwxjcsHmKcVcq9ldLQZuJREWEebkvTtP2dMkF+Futw1Ypx82E5OUqwAddOMo5+0Csn/XnEv7U50wZtc= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB3131.eurprd07.prod.outlook.com (10.170.245.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.14; Fri, 20 Jul 2018 19:52:00 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::1dcb:c44d:b7f5:6c20]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::1dcb:c44d:b7f5:6c20%5]) with mapi id 15.20.0973.018; Fri, 20 Jul 2018 19:52:00 +0000 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: Some comments on draft-rescorla-tls-esni-00 Thread-Index: AQHUIGMfC9xWmUZX1kuZ7bjM4QETjQ== Date: Fri, 20 Jul 2018 19:52:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [70.83.160.89] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3131; 6:fgoLSOLu+tSQJGYDQTX1OrwW3oxQZOkPN3f4nsQspXvK4cfUlQXu9/VzZpFBA6/By7hAC3iSuiZP0AlwPgZmCYOwKSwPat6il3mSK+GP/+16Gm3jyD2K5DDP4Gjx1JJpt30+D3s4Uwcz96JLGNgICvhqNFDV2moU0yE1bvmNSVhb6SqrilXaCTJahZYK58dhaLW8H/XOsh89XiE9U7zEa8Nt0F7eIuQNZkovuUqUlvdOK1zUXbWSj+ZRysWj8wchi0M88JA0mFSlc+qwZXrClrJTh8yVSQ+Eie43A6ROIzHtIR0UV4v+GXOuIwbFUqL6B4fBE3/+J0Mc5+8kicsk2l4FB/S4I3XisELePD68lxk9sCvnmKm5Uc+zmnTw7AC3o7cTbPSqrOlSNLjXybnDvTvRVWPkmLLvr2XkCrDpi/4Ag6ORcfIg8dBBiAN3e4zwEoAs4SkgPznGBHR5QlOGHw==; 5:yPcuTJquhGdYVCX8cj9Z2pcoPNm5d58t7PWMMcb7FSSpQOWj0clhhlLBRwJgK4Nrzm/PTuwZvfklCkO89gInn18093O8c6ayXccsxVsPCtb+QZ0qQAEUu9mpVGfxqopISU4age8u79Ev8lHTbyyawO004KcPkk4A995k++qiTuw=; 7:neScTW9WpyZa9+iRGpzHdhVbDoL8/12c1zZ2I/8Syl/+XGYayKlvo2DWame4GO5hls7K/K5E+v00EbqcSbatqOqXzDnq7utcGbDjwaMJttM3Ew/tkHUiMjIBmZE3WI706d4w5TzaR4voCLkiM2j4cjaGaYQHI/ysBfKZySjIkJEVe3ZZC4SGteo2YqOD2hlWd/Fj0hH59Df+VRYUgwXOpPKLUQ6D+UWmrgj47ZAP7yVmZz2ewFUy/0cIfBtQbUqK x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 641f910a-1f76-42f0-bd2f-08d5ee7a4223 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600053)(711020)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB3131; x-ms-traffictypediagnostic: HE1PR07MB3131: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:HE1PR07MB3131; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3131; x-forefront-prvs: 073966E86B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(136003)(366004)(396003)(376002)(199004)(189003)(5660300001)(83716003)(44832011)(486006)(305945005)(476003)(3846002)(8676002)(6116002)(8936002)(2616005)(86362001)(14444005)(36756003)(58126008)(33656002)(256004)(99286004)(5250100002)(26005)(186003)(2501003)(6506007)(102836004)(81156014)(316002)(81166006)(7736002)(478600001)(2351001)(2900100001)(53936002)(82746002)(6916009)(53376002)(68736007)(25786009)(105586002)(97736004)(966005)(2906002)(66066001)(14454004)(6512007)(6306002)(106356001)(6486002)(5640700003)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3131; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: RbQ93jHCxt6yM9FnKBcM0jndsxKb3HvpKObcC8vjjaB4fQu0dMymohpCUx/3RSMrbqfxHzTHcglIqJ6lqrEf/xJEWF0PIoiviiRGXqVdLkEKl+7aRcFRhMbMrf7n6AspgKL6Es9V8VfQD3xuuqvER5zRzhO8Q7CKyrN/gbnk7MDTYYUDVIpMyBa28WTPfTXtZSqp40NA5DIT9NdSinlKt4/YqW6aEVNglQBvQm2wPDP1dRYQUFI6stm3bRv9GivcukfV0jvrKO4Ev6/N0YiyqAlEC/f+WXIypwkdPTtRATL5Le6DPOrV5R9v0cJqc3Y1iOQmgjPEE2/Ju9s5TlOjkOdyTb6ZfBxsFZsm8a/rKLY= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <5205C89D4A118E40BD1CFEBDB96EAC5F@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 641f910a-1f76-42f0-bd2f-08d5ee7a4223 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Jul 2018 19:52:00.5462 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3131 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmleLIzCtJLcpLzFFi42KZGbG9TLfMNijaYMZadYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0bWph7FgFn/F2+uT2RsYX/B1MXJySAiYSHyfeocFxBYSOMoo 8eJzaBcjF5D9jVHi9KvdzBDOEiaJuc8/sII4LAITmCWOPzrOBtEyiUni73MeCPsRo8TjTkkQ m03AQGLungagGg4OEQFFiU+fs0HCwkDbpk++ywpiiwhYSnx++5UJwtaT+POyiR3EZhFQldjw YCkziM0rYC/Rc6yHEcRmFBCT+H5qDVg9s4C4xK0n85kgPhCQWLLnPDOELSrx8vE/sPmiQDOn zn7EBNEbK9HaOp0VokZB4tjfJqh6WYlL87sZQf6SENjHLjG5+zAjREJX4sPUqVBFvhLn/k9j hii6wChxrGU/G0RCS2LWzKMsEHa2xPWbj6Hi1hIvz+2G2iYnsar3IQvUBmaJqX1X2UGhIiEg I/GslW0Co8EsJA/NAsowC2hKrN+lD2F6SEyZ7w1RoSgxpfsh+yxwsAhKnJz5hGUBI+sqRtHi 1OLi3HQjY73Uoszk4uL8PL281JJNjMCkcXDLb90djKtfOx5iFOBgVOLhrTcJihZiTSwrrsw9 xCjBwawkwjvhbUC0EG9KYmVValF+fFFpTmrxIUZpDhYlcV69VXuihATSE0tSs1NTC1KLYLJM HJxSDYy6sSt3/q3WMz3+ruLiycWPucMr9XnKmt5XPVgt5n1L2/jJinPzP2481mfC4NFU08Gy SeP8/dpmIX2tvE+XLrSpTJt0+4xP65Fjll8Xf7jdt/ShI29/6r4FZUcq7EuMCtu21G3+Ir7Y Q/XT/XkfraZt2ONztN1F/lCQ10U5wz3+Eo6/PyucsilVYinOSDTUYi4qTgQAAirs2xYDAAA= Archived-At: Subject: [TLS] Some comments on draft-rescorla-tls-esni-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 19:52:32 -0000 SGksDQoNCkkgbG9va2VkIHRocm91Z2ggdGhlIGRyYWZ0LCBtYWlubHkgZm9jdXNpbmcgb24gdGhl IGNyeXB0byBwYXJ0cy4gVGhpcyBpcyBtb3JlIG9yIGxlc3MgRUNJRVMsIGJ1dCB3aXRoIGEgbW9y ZSBtb2Rlcm4gc3R5bGUgb2Yga2V5IGRlcml2YXRpb24gdGhhdCBtb3N0IGV4aXN0aW5nIHN0YW5k YXJkcy4gVGhpcyBzb2x1dGlvbiBpcyB2ZXJ5IHNpbWlsYXIgdG8gdGhlIHN0YW5kYXJkaXplZCAz R1BQIGlkZW50aXR5IGVuY3J5cHRpb24gKFNVQ0kpIHdpdGggdGhlIGRpZmZlcmVuY2UgdGhhdCB0 aGUgc3RhdGljIHB1YmxpYyBrZXlzIGFyZSBkaXN0cmlidXRlZCB0aHJvdWdoIEROUyBpbnN0ZWFk IG9mIFVJQ0NzIChha2EgU0lNIGNhcmRzKS4NCg0KVGhlIGN1cnJlbnQgY29uc3RydWN0aW9uIGxv b2tzIHZlcnkgZ29vZC4NCg0KLSBPbmUgdGhpbmcgdGhhdCBjb3VsZCBiZSBkaXNjdXNzZWQgaXMg aW50ZWdyaXR5IHByb3RlY3Rpb24gb2YgdGhlIGNsaWVudOKAmXMgZXBoZW1lcmFsIHB1YmxpYyBr ZXkuIFRoZSBjdXJyZW50IGNvbnN0cnVjdGlvbiANCg0KZW5jcnlwdGVkX3NuaSA9IEFFQUQtRW5j cnlwdChrZXksIGl2LCAiIiwgUGFkZGVkU2VydmVyTmFtZUxpc3QpDQoNCmRvZXMgbm90IGFjaGll dmUgSU5ELUNDQSBzZWN1cml0eSAoYnV0IG9ubHkgc3VmZmVycyBmcm9tIGJlbmlnbiBtYWxsZWFi aWxpdHkgWzFdWzJdKS4gQW4gYWRkaXRpb24gb2YgdGhlIGNsaWVudOKAmXMga2V5IHNoYXJlIHdv dWxkIG1ha2UgdGhlIFNOSSBlbmNyeXB0aW9uIElORC1DQ0Egc2VjdXJlOg0KDQplbmNyeXB0ZWRf c25pID0gQUVBRC1FbmNyeXB0KGtleSwgaXYsIEtleVNoYXJlQ2xpZW50SGVsbG8sIFBhZGRlZFNl cnZlck5hbWVMaXN0KQ0KDQpVbmxlc3MgaXQgY2F1c2VzIHByb2JsZW1zIG9mIHNvbWUga2luZCwg SSB3b3VsZCByZWNvbW1lbmQgZG9pbmcgdGhhdC4NCg0KLSBUaGUgaGFzaCBhbGdvcml0aG0gdXNl ZCBpbiDigJxIYXNoKENsaWVudEhlbGxvLlJhbmRvbSnigJ0gZG9lcyBub3Qgc2VlbSB0byBiZSBz dGF0ZWQuIEkgYXNzdW1lIHRoYXQgaXQgaXMgdGhlIGhhc2ggZnVuY3Rpb24gYXNzb2NpYXRlZCB3 aXRoICJzdWl0ZSIuIEFsc28sIGlzIGhhc2hpbmcgdGhlIHJhbmRvbSB2YWx1ZSBuZWVkZWQ/DQoN Ci0gQSBtaXN0YWtlIEVDSUVTIGltcGxlbWVudGF0aW9ucyBoYXMgZG9uZSBpbiB0aGUgcGFzdCBp cyB0byBsZXQgdGhlIGludGVncml0eSBrZXkgZGVwZW5kIG9uIHRoZSBwbGFpbnRleHQgd2hpY2gg YnJlYWtzIHRoZSBzZWN1cml0eSBwcm9vZiBvZiBFQ0lFUywgYnV0IHRoaXMgaXMgbm90IHRoZSBj YXNlIGhlcmUuDQoNCkNoZWVycywNCkpvaG4NCg0KWzFdIGh0dHA6Ly93d3cuc2VjZy5vcmcvc2Vj MS12Mi5wZGYNClsyXSBodHRwOi8vc2hvdXAubmV0L3BhcGVycy9pc28tMl8xLnBkZg0KDQo= From nobody Fri Jul 20 13:03:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C05130E6D for ; Fri, 20 Jul 2018 13:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fr1tEEQZ5D4u for ; Fri, 20 Jul 2018 13:03:02 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD0C130E04 for ; Fri, 20 Jul 2018 13:03:01 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id u202-v6so2566996lff.9 for ; Fri, 20 Jul 2018 13:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=z2qmlcgmEaexcwNX3Y/tW1BHYbQrvmDS67P8c8SpwbA=; b=uLamPNgTU3AlCk8KnhGnoH/vMa9P/WBdYyhCRf1w71ctJfg2dBgQkpehSKLhWAFh+0 1WKBp7X8wiYfQddmCMhnlMFgchsTmsdOcGON0hykwb9Fe5L/UzPkcvi1BJ7QpObmKh1z ME4qiaO9wBMLQnaO4UkCP056/qd37D/QE46lQzNkNUCkXb0bdMC/7VDFd/qxe9ritrXy M0pwdSPKZOQ0YFuKZeLLEhE1yprfAz5qscl58jXI6PtG3QQks99+9v6d3dPv6cUvqebb 6x1inOZUun4tX03q6SQR7RAuWR9aRs8hIV4Jxzu+VLf2HSPVJDjDSTEWzPeUWUmDxQ33 pGww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=z2qmlcgmEaexcwNX3Y/tW1BHYbQrvmDS67P8c8SpwbA=; b=JlviwZ+phSerM0/34qT1ughloSMWIDXJ5Q/UsGTI3fSyWacFqgnd+qXUdWsPrl8bvr c+2AZbMTO9AIhfAKcCTcEuYbjn5kKg91Xrwz+f3//LYF/A+Si+wwwm70BtHevQmnmV5z c4tVAOa5eC+K5c2TMAvOsiI6nT38TwWQai7sxlu/gcEgI2W7BshnTTNGNQZDY49ZY33z Km5Tki9ChfvcJCTQP39agixlHy2pGwNQbTTf9vFwnf2qZKHT4E/etaDE6YaTTsgBU2Nq ZGJHINh7GTq5l/Oz8rg+u31lv2tycD7QdoFp7lVj5mEuEh3qgjFchQv03Bowtp8wI7Ic xgWg== X-Gm-Message-State: AOUpUlHnlt8BeKUqyW0RBa4dCuGIpiE6idB97ztbtOUwz5kbdibgmFZz fDmId8XPh9MrRobI8bzgwnWBEAMNzFLXUCRHuFIHuQ== X-Google-Smtp-Source: AAOMgpe0D5poxZriSdOLBdhpCohvx10r4+cySbWpoUdqnvx6+gLFmyXvWP4cF7VZnJdDlSdd9rcUMGzEIZW3rOUZ3CY= X-Received: by 2002:a19:6308:: with SMTP id x8-v6mr2237202lfb.104.1532116980192; Fri, 20 Jul 2018 13:03:00 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 20 Jul 2018 13:02:19 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 20 Jul 2018 13:02:19 -0700 Message-ID: To: John Mattsson Cc: "TLS@ietf.org" Content-Type: multipart/alternative; boundary="0000000000005bfd30057173c817" Archived-At: Subject: Re: [TLS] Some comments on draft-rescorla-tls-esni-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 20 Jul 2018 20:03:06 -0000 --0000000000005bfd30057173c817 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable John, Thanks for your comments. It's good to know that someone has already done this! On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson wrote: > Hi, > > I looked through the draft, mainly focusing on the crypto parts. This is > more or less ECIES, but with a more modern style of key derivation that > most existing standards. This solution is very similar to the standardize= d > 3GPP identity encryption (SUCI) with the difference that the static publi= c > keys are distributed through DNS instead of UICCs (aka SIM cards). > > The current construction looks very good. > > - One thing that could be discussed is integrity protection of the > client=E2=80=99s ephemeral public key. The current construction > > encrypted_sni =3D AEAD-Encrypt(key, iv, "", PaddedServerNameList) > > does not achieve IND-CCA security (but only suffers from benign > malleability [1][2]). An addition of the client=E2=80=99s key share would= make the > SNI encryption IND-CCA secure: > > encrypted_sni =3D AEAD-Encrypt(key, iv, KeyShareClientHello, > PaddedServerNameList) > > Unless it causes problems of some kind, I would recommend doing that. > Thanks. This seems like a good plan. Would an acceptable alternative be to hash the KeyShare into the key? > - The hash algorithm used in =E2=80=9CHash(ClientHello.Random)=E2=80=9D d= oes not seem to > be stated. I assume that it is the hash function associated with "suite". Yes. > Also, is hashing the random value needed? > No, it's just a result of the slightly goofy HKDF-Expand-Label interface. -Ekr - A mistake ECIES implementations has done in the past is to let the > integrity key depend on the plaintext which breaks the security proof of > ECIES, but this is not the case here. > > Cheers, > John > > [1] http://www.secg.org/sec1-v2.pdf > [2] http://shoup.net/papers/iso-2_1.pdf > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000005bfd30057173c817 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
John,

Thanks for your commen= ts. It's good to know that someone has already done this!



On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson <jo= hn.mattsson@ericsson.com> wrote:
Hi,

I looked through the draft, mainly focusing on the crypto parts. This is mo= re or less ECIES, but with a more modern style of key derivation that most = existing standards. This solution is very similar to the standardized 3GPP = identity encryption (SUCI) with the difference that the static public keys = are distributed through DNS instead of UICCs (aka SIM cards).

The current construction looks very good.

- One thing that could be discussed is integrity protection of the client= =E2=80=99s ephemeral public key. The current construction

encrypted_sni =3D AEAD-Encrypt(key, iv, "", PaddedServerNameList)=

does not achieve IND-CCA security (but only suffers from benign malleabilit= y [1][2]). An addition of the client=E2=80=99s key share would make the SNI= encryption IND-CCA secure:

encrypted_sni =3D AEAD-Encrypt(key, iv, KeyShareClientHello, PaddedServerNa= meList)

Unless it causes problems of some kind, I would recommend doing that.

Thanks. This seems like a good plan. Would a= n acceptable alternative be to hash the KeyShare into the key?

=C2=A0
- The hash algorithm used in =E2=80=9CHash(ClientHello.Random)=E2=80=9D doe= s not seem to be stated. I assume that it is the hash function associated w= ith "suite".

Yes.

=
=C2=A0
Also, is hashing the = random value needed?

No, it's just = a result of the slightly goofy HKDF-Expand-Label interface.

=
-Ekr

- A mistake ECIES implementations has done in the past is to let the integr= ity key depend on the plaintext which breaks the security proof of ECIES, b= ut this is not the case here.



Cheers,
John

[1] http://www.secg.org/sec1-v2.pdf
[2] http://shoup.net/papers/iso-2_1.pdf

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

--0000000000005bfd30057173c817-- From nobody Mon Jul 23 05:02:55 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84BCB130E17 for ; Mon, 23 Jul 2018 05:02:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pOdYOl7BF8q for ; Mon, 23 Jul 2018 05:02:51 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2297130DD4 for ; Mon, 23 Jul 2018 05:02:50 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id x24-v6so216886ual.10 for ; Mon, 23 Jul 2018 05:02:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qd7y5kjmlzj5OtJpHNYW86LbZEGA52tEElV6YOjtWBc=; b=ijjitg1wVf6t0QnBJQ9+MSsosCkVd6okWW/T2X72wSjP+cRHMUrBTlcbGcZ3wTYarq ZrqcVm31chtJaCSB1A22+S2tNBjjUrMAvfcG0Y2k4lr7XBh1MMc887xNAXJBmbmxdwZK ejEnTyojzBd894aIwKU74Eb/jk6pUyEwnYMBfBObLgQVmyK1uiO16FO4h8DDfJYEOY8Z TEyLJhNCFHnMFjyIJyjcRaEGoeMseXFAyQJcbXx8U4NpcynkJ/s3Vblt7yO1ww6ge082 LH1Hp8otwyZdqE2d5VNvJVDvKBNS0IUcFizM5SPUPQa0vMm6MkeqnM+0cQ4ZzcWF+083 Hjyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qd7y5kjmlzj5OtJpHNYW86LbZEGA52tEElV6YOjtWBc=; b=JIEx+Sn6oG3qlvfUvQp0ijXf71KrULaQ8b59mJheGbJdQ9QTMjhFYioMq2dGYH4Paw 57AEbOk3jre7tXYHGuvRq+B09y4bEvbK2g3yMOZTQB7udvDAlCmpaDNJGvoESpirsDet 20dV1IwiD/nziWdS1DHPFFCGpqQ/5gb/FbKKtmcdUlYpBSY/NC5aYkax6/V9PHC79Ezd gNjcqaXyBoWqNTIx0wuwReqaUZ0+vYaCwyDfU1yEbnOV4HKZfRNMmCtCdmoJex8P2bmG Bkx1tbg2ZJ7bMf3bXScWz2pXnHjAy4DqR01usO0HlOWrIW12mnEn8sXYZ60IUP3ysMOp MDKA== X-Gm-Message-State: AOUpUlGCFsxTYaDdhaf80iOqByLGxKWHABq+IP61wKkv29siaxh77UY4 UvcYZ8tEz6o+CADx/nm6dTxfe3dEVoeTMnj3iXw= X-Google-Smtp-Source: AAOMgpcD+oVTdqV+r1krjVuELGM8niMgIGgg1d9JOkZibwyCJsG0I7tfpHct+kU0YGYonJFMv2Pl/sK+WR27YbCf0ag= X-Received: by 2002:ab0:622:: with SMTP id f31-v6mr8901149uaf.189.1532347369842; Mon, 23 Jul 2018 05:02:49 -0700 (PDT) MIME-Version: 1.0 References: <20180719230009.GD14551@akamai.com> <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> <20180720142104.GA27715@LK-Perkele-VII> In-Reply-To: <20180720142104.GA27715@LK-Perkele-VII> From: Jonathan Hoyland Date: Mon, 23 Jul 2018 14:02:38 +0200 Message-ID: To: Ilari Liusvaara Cc: David Benjamin , "" Content-Type: multipart/alternative; boundary="000000000000a6eb6e0571a96c28" Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2018 12:02:54 -0000 --000000000000a6eb6e0571a96c28 Content-Type: text/plain; charset="UTF-8" Hi all, Couldn't make it to the second TLS session, but I did suggest on the mailing list a tweak to the universal PSK draft that achieves compatibility, unambiguity, and is straight-forward to prove secure formally. (By which I mean prove independent of the security of TLS 1.2, and thus any hash function it uses, even a pathalogical one.) https://www.ietf.org/mail-archive/web/tls/current/msg26419.html In brief I suggest that you transform both the PSK ID and the PSK itself in such a way that a server that accepts them tacitly acknowledges the upgrade of the PSK from 1.2 to 1.3. You can achieve compatibility with a server that doesn't support this by offering the untransformed PSK ID also, at the cost of a more complex formal analysis / potentially weaker security. Regards, Jonathan On Fri, 20 Jul 2018 at 15:22 Ilari Liusvaara wrote: > On Fri, Jul 20, 2018 at 08:42:47AM -0400, David Benjamin wrote: > > > > (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 is > > probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don't > > think we actually believe SHA256 and SHA384 give related output. It's > just > > nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA256 > > actually a chance of misbehavior. Perhaps it's worth doing that > analysis?) > > TLS 1.3 does this with PSK: > > HMAC(, PSK) > > And TLS 1.2 does: > > HMAC(, ) > > (where actually depends on ). Now, it is > possible that there is second similar block in there, but that uses > the same . > > > However, noteworthy point is that there is only two ways to end up in > situation where the effective key in TLS 1.2 is all zeroes: > > 1) is longer than hash block and is preimage of 0. > Finding such thing is supposed to be infeasible. > 2) The PSK is empty. However, the on TLS 1.2 side is > not empty in this case (it starts with gunk from HMAC that > involves at least both randoms). Also, empty PSK is not secure. > > > The definition of HMAC is: > > H(C(key) XOR opad | H(C(key) XOR ipad, data)) > > Which preserves collision resistance on C(key) and data. Now, C(key) > is not collision resistant. However, the only possible cases where > C(key) can collide are the two above. > > > So it seems to me that TLS 1.2 and TLS 1.3 compute independent > things from PSK values, in all practical cases. > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000a6eb6e0571a96c28 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,=C2=A0

Couldn't make it to t= he second TLS session, but I did suggest on the mailing list a tweak to the= universal PSK draft that achieves compatibility, unambiguity, and is strai= ght-forward to prove secure=C2=A0formally.<= /span>=C2=A0(By which I mean prove independ= ent of the security of TLS 1.2, and thus any hash function it uses, even a = pathalogical one.)=C2=A0https://www.ietf.= org/mail-archive/web/tls/current/msg26419.html
In brief I sug= gest that you transform both the PSK ID and the PSK itself in such a way th= at a server that accepts them tacitly acknowledges the upgrade of the PSK f= rom 1.2 to 1.3.=C2=A0
You can achieve compatibility with a server= that doesn't support this by offering the untransformed PSK ID also, a= t the cost of a more complex formal analysis / potentially weaker security.= =C2=A0

Regards,

Jonathan<= /div>

On Fri, 20 Jul 2= 018 at 15:22 Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Fri, Jul 20, 2018 at 08:42:47AM -0400, David Benjamin wrote:
>
> (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 i= s
> probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I don&#= 39;t
> think we actually believe SHA256 and SHA384 give related output. It= 9;s just
> nice to avoid the assumption. Whereas TLS1.2-PRF-SHA256 and HKDF-SHA25= 6
> actually a chance of misbehavior. Perhaps it's worth doing that an= alysis?)

TLS 1.3 does this with PSK:

HMAC(<zeroes>, PSK)

And TLS 1.2 does:

HMAC(<expanded PSK>, <some data>)

(where <some data> actually depends on <expanded psk>). Now, it= is
possible that there is second similar block in there, but that uses
the same <expanded PSK>.


However, noteworthy point is that there is only two ways to end up in
situation where the effective key in TLS 1.2 is all zeroes:

1) <expanded psk> is longer than hash block and is preimage of 0.
=C2=A0 =C2=A0Finding such thing is supposed to be infeasible.
2) The PSK is empty. However, the <some data> on TLS 1.2 side is
=C2=A0 =C2=A0not empty in this case (it starts with gunk from HMAC that
=C2=A0 =C2=A0involves at least both randoms). Also, empty PSK is not secure= .


The definition of HMAC is:

H(C(key) XOR opad | H(C(key) XOR ipad, data))

Which preserves collision resistance on C(key) and data. Now, C(key)
is not collision resistant. However, the only possible cases where
C(key) can collide are the two above.


So it seems to me that TLS 1.2 and TLS 1.3 compute independent
things from PSK values, in all practical cases.



-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000a6eb6e0571a96c28-- From nobody Mon Jul 23 05:56:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF4DF130E74 for ; Mon, 23 Jul 2018 05:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qADxuubaRcUb for ; Mon, 23 Jul 2018 05:56:21 -0700 (PDT) Received: from mta.openssl.org (mta.openssl.org [194.97.150.230]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 074C0130E78 for ; Mon, 23 Jul 2018 05:56:21 -0700 (PDT) Received: from [10.38.10.6] (ip-25-84-52-196.southampton.uk.amsterdamresidential.com [196.52.84.25]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mta.openssl.org (Postfix) with ESMTPSA id 92488EAABD for ; Mon, 23 Jul 2018 12:56:18 +0000 (UTC) To: tls@ietf.org References: <20180719230009.GD14551@akamai.com> <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> From: Matt Caswell Openpgp: preference=signencrypt Autocrypt: addr=matt@openssl.org; prefer-encrypt=mutual; keydata= xsBNBFGALsIBCADBkh6zfxbewW2KJjaMaishSrpxuiVaUyvWgpe6Moae7JNCW8ayhJbwAtsQ 69SGA4gUkyrR6PBvDMVYEiYqZwXB/3IErStESjcu+gkbmsa0XcwHpkE3iN7I8aU66yMt710n GEmcrR5E4u4NuNoHtnOBKEh+RCLGp5mo6hwbUYUzG3eUI/zi2hLApPpaATXnD3ZkhgtHV3ln 3Z16nUWQAdIVToxYhvVno2EQsqe8Q3ifl2Uf0YpaN19BDBrxM3WPOAKbJk0Ab1bjgEadavrF BCOl9CrbThewRGmkOdxJWaVkERXMShlzUzjJvKOUEUGOxJCmnfQimPQoCdQyVFLgHfRFABEB AAHNH01hdHQgQ2Fzd2VsbCA8bWF0dEBvcGVuc3NsLm9yZz7CwHgEEwECACIFAlPevrwCGwMG CwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJENnE0m0OYESRoD0H/1lEJXfr66rdvskyOi0z U0ARvUXHjbmmYkZ7ETkdXh7Va/Tjn81T3pwmr3F4IcLGNLDz4Eg67xbq/T8rrsEPOx5nV/mR nUT97UmsQuLnR2wLGbRBu24FKM7oX3KQvgIdJWdxHHJsjpGCViE1mIFARAzlN+6p3tPbnQzA NjRy7i/PYU/niGdqVcMhcnZCX5F7YH6w6t0ZmYH3m1QeREnWqfxu7eyHsIvebMgKTI/bMG8Z 7KlLZha9HwrFXQAPIST6sfc1blKJ9INUDM9iK6DR/ulkw7e0hmHLqjWqYs5PzyXeoNnsPXJt 69wiADYqj4KNDIdNp1RoF9qfb1nE+DM6rgbOwE0EUYAuwgEIAM9nUJAEpsVBYwK92PP9Mlo1 /etXp6JgBI68sOCJxTwzBrbTzIlevVQXqW9zdODD6ObKcgGNuG+G6Nwn54P6McRpd2dxor9Y A+yaI0yT6CVnhxsXjwc/vuQ4tBAL6tfuMAXRVIeEVk22cKk4HJB68ImXCCRdyRi9HIE5iTrZ HsHC4sjAsirhlc0o8hU3gqkKh2Ehwa6+U8lzNx06hoFEZxIVRteoz1jzCHImF7EXztEcDIam O8uckVKAuKbJgFGkU3bkvNgWlc8Pgx4tRUNJGC1LE4nYqaSEwee1SpA/VewiDObj97PozCTF zRCUBCnSvaAlTnpA90TnODH7ar+L5aEAEQEAAcLAXwQYAQIACQUCUYAuwgIbDAAKCRDZxNJt DmBEkQs2B/96XB9hyFpX/bhu41YNr7nSA65dDi9d+PkMqvLppickG3VR4xXWywzEJTw6W2DN MyFO6mOtdXWgNdgDF7HKZYvHBr6pyttLAMP7BfWBvU7YY59uKmUSc5vl0NzsaSbx5PDSQEkS ICLI+/hIwuEXOb6Z7gOrX7F1uy83TmHFOOjD2mLl5isUzFhaLVk0fZSY+mCgg3/inbwb8g31 91Ybk2LfXmndaEsdEzMLrT0g6wIgmybz6UdVuVPfSPGly0VWVAG1sNPOCpAuJpNV6+VxrdVi Ax3vQPbx3XzqDFS1ISlnd0qS/7RXwMuFDpVH/BDvzQcoikWnpRY/loPGkSg4TB7a Message-ID: Date: Mon, 23 Jul 2018 13:56:17 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2018 12:56:24 -0000 On 20/07/18 13:42, David Benjamin wrote: > I think that's the point of deciding this immediate question now, so we > can get some text in the specification. If we decide to fix this, we'd > instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 PSKs > are configured and then, once the fixup document is published, implement > it and remove the version logic. This is interoperable at all > combinations as version negotiation runs first. So, to be clear about this interim proposal: 1) If a client is configured with a 1.2 PSK but not a 1.3 PSK, it should not provide supported versions, and only negotiate TLSv1.2 or lower. If it has both then it should supply supported versions and advertise support for TLSv1.3. 2) If a server is configured with a 1.2 PSK and not a 1.3 PSK it should only select TLSv1.2 or lower. 3) If a server has separate 1.2 PSKs and 1.3 PSKs should it allow 1.3 to be negotiated? Presumably "yes" to allow a phased roll out of TLSv1.3 to clients. Consider the case after Universal PSKs have been introduced. A client that has not been explicitly configured for 1.3 PSKs can suddenly start offering them and will issue a ClientHello containing supported versions with TLSv1.3 in it. But if it then attempts to connect to a server which does not support universal PSKs and has been explicitly configured with separate 1.2 and 1.3 PSKs the server will select TLSv1.3, but then the connection will fail because the explicit 1.3 PSK configured on the server is not compatible with the Universal PSK offered by the client. Or did I misunderstand something somewhere? Matt From nobody Mon Jul 23 06:45:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86F29130E89 for ; Mon, 23 Jul 2018 06:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_hCZR1MkcBu for ; Mon, 23 Jul 2018 06:45:21 -0700 (PDT) Received: from mail-wr1-f49.google.com (mail-wr1-f49.google.com [209.85.221.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1B87130DC7 for ; Mon, 23 Jul 2018 06:45:20 -0700 (PDT) Received: by mail-wr1-f49.google.com with SMTP id b15-v6so762266wrv.10 for ; Mon, 23 Jul 2018 06:45:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=TQ1Wzt7T7gJoIP41iSkbAxtV45tIDAwXUmMoKt0CwzU=; b=OtHffM8dmRCRvssSaxTblrJWjP9hut6ZnnT3pd7NMsAUHhtln/njmxjbj4MpVuT+Wr SoifixC6tj0DYeAO/VjIZ1fz4WVar8CdbNeoBA8KK4gzZN5vYEPjjKR4Qt//Ie9Cu9YJ wKTh35LdoC3kI7mZHXQu9/SZOWMKlkPGsjpPQ3mPSWsgdOwLQgabxZPJfoodmSL9i4t/ 9hmgZmqgzMei+VmWZDAhxLkgxgjNqvCLK73fYjWK2kW1tXd7LeiL8w5K6LWiDdGryj4l cMs5OjEIPZiGJgj3mto5zSNlfVJlVGQJEu0G30oKTij6RSx9sgHxud0ZEUCVGoSZh+Gn kJuA== X-Gm-Message-State: AOUpUlGb9InCOGwEGVhZ+yARz4yQ8fSDvQ9ZfLhXVsAmfI5Nub4rjA6o t4K+vnqFcsuPnj+ITEVHxMuAbA== X-Google-Smtp-Source: AAOMgpcWtnMcy+oCGw4BqdZRuk/mLgs9FTU7vMDJl/2O2BmIIWt3bDClBALm7L9jGHvMEkaerr6HZg== X-Received: by 2002:a5d:5043:: with SMTP id h3-v6mr8239335wrt.186.1532353519309; Mon, 23 Jul 2018 06:45:19 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id i205-v6sm12697055wmf.30.2018.07.23.06.45.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 23 Jul 2018 06:45:18 -0700 (PDT) Message-ID: <9c4ba8a53fd365993e996f31d355297ae77c3fdc.camel@redhat.com> From: Nikos Mavrogiannopoulos To: David Benjamin Cc: Eric Rescorla , "" , Benjamin Kaduk Date: Mon, 23 Jul 2018 15:45:17 +0200 In-Reply-To: References: <20180719230009.GD14551@akamai.com> <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.4 (3.28.4-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 23 Jul 2018 13:45:24 -0000 On Fri, 2018-07-20 at 08:42 -0400, David Benjamin wrote: > > > I understand, but as I have already mentioned that argument also > > applies for RSA keys which can be used e.g., for RSA encryption > > under > > TLS1.2 and for RSA-PSS signatures under TLS1.3. ECDSA keys can be > > used > > with multiple hashes under TLS1.2 while only one under TLS1.3. > > TLS 1.3 did not enforce protocol separation for that ugly scenario, > > so > > I wouldn't expect the treatment of PSKs differently. > > PSKs are much easier to fix this with than signing algorithms, given > that we don't want to reprovision either to deploy TLS 1.3. > > ECDSA in TLS didn't get worse with TLS 1.3. We didn't add a new hash > to mixup, just restricted the set from TLS 1.2. If we left it alone, > we'd still have the same effect. For RSA, you're right that we > introduced an extra pair of algorithms to worry about. The options > there are: > > (1) Add PSS, forbid PKCS1, and forbid PSS with id-rsaEncryption. > Cost: TLS 1.3 requires reprovisioning RSA keys. > (2) Add PSS, forbid PKCS1, but allow PSS with id-rsaEncryption. Cost: > We have two algorithms with one key. > (3) Don't forbid PKCS1. Cost: We don't get rid of PKCS#1. > > (1)'s cost is clearly fatal, given 1.3's goals. I'm personally fine > with either (2) or (3), but the WG chose (2). > > With PSKs, I think we can get both. If we consider 1.2 PSKs to be > paired with the 1.2 PRF, we can allocate a new label, and derive a > separate thing to stick in 1.3, and not require reprovisioning. It's > basically free, so I think it makes sense to do it. > (I suspect using the same key with TLS1.2-PRF-SHA256 and HKDF-SHA256 > is probably *more* risky than mixing HKDF-SHA256 and HKDF-SHA384. I > don't think we actually believe SHA256 and SHA384 give related > output. It's just nice to avoid the assumption. Whereas TLS1.2-PRF- > SHA256 and HKDF-SHA256 actually a chance of misbehavior. Perhaps it's > worth doing that analysis?) > Of course, I don't actually know what I'm talking about. Opinions > from the formal analysis folks would be great. :-) I wouldn't expect much from formal analysis here, though in the past I've been positively surprised. I'd expect "don't mix algorithms", as with RSA and RSA-PSS. > > Said that, I want to clarify that I wouldn't necessarily object to > > an > > improvement the situation for externally established PSKs. The > > issue I > > see is that TLS1.3 already gives a "good enough" solution with re- > > using > > the key, and I'm afraid we're going to have interoperation issues > > if > > some implementations move to universal psks and some do not, > > defeating > > the purpose of a standard. > > I think that's the point of deciding this immediate question now, so > we can get some text in the specification. If we decide to fix this, > we'd instruct implementations to (temporary!) turn off TLS 1.3 if 1.2 > PSKs are configured and then, once the fixup document is published, > implement it and remove the version logic. This is interoperable at > all combinations as version negotiation runs first. > Personally, I actually don't care much about 1.2 PSKs as I don't work > with anything that uses them. I do care about allowing new protocols > to use 1.3 external PSKs cleanly---new protocols can just mandate 1.3 > and avoid 1.2, but the hash rule makes the whole thing unusable and > it is unclear whether 1.3 PSKs will be usable in a future 1.4. I > figured it'd be easy to patch the 1.2 issue while I was at it, thus > the construction in my draft. > > But the exact derivation can be worked out separately, my draft or > not. The immediate question is whether we think 1.2 PSKs should be > reusable in 1.3 as-is or whether we should stick a derivation step to > separate them. The derivation makes sense to be part of the draft. It makes sense to me the whole draft to be part or referred from TLS1.3. regards, Nikos From nobody Tue Jul 24 08:01:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C993131110 for ; Tue, 24 Jul 2018 08:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8R-hQbjD0AX for ; Tue, 24 Jul 2018 08:00:59 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE5B130E96 for ; Tue, 24 Jul 2018 08:00:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 6172F33C67; Tue, 24 Jul 2018 18:00:56 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id itfu1UKXoj28; Tue, 24 Jul 2018 18:00:55 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 8E8BF72; Tue, 24 Jul 2018 18:00:53 +0300 (EEST) Date: Tue, 24 Jul 2018 18:00:53 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "TLS@ietf.org" Message-ID: <20180724150053.GA27089@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Some comments on draft-rescorla-tls-esni-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2018 15:01:03 -0000 On Fri, Jul 20, 2018 at 01:02:19PM -0700, Eric Rescorla wrote: > On Fri, Jul 20, 2018 at 12:52 PM, John Mattsson > wrote: > > > encrypted_sni = AEAD-Encrypt(key, iv, KeyShareClientHello, > > PaddedServerNameList) > > > > Unless it causes problems of some kind, I would recommend doing that. > > > > Thanks. This seems like a good plan. Would an acceptable alternative be to > hash the KeyShare into the key? Might also consider hashing in the server side public key and group identification. Also, one might consider post-quantum already. Even if the algorithms are not known, the characteristics of the algorithms are: The client key share is not useful to derive the shared secret (because client key share is client's public key), and furthermore none of the algorithms client key shares use might be useful, because they all might only be secure for one use, where SNI encryption needs security with many uses (whereas key exchange only needs to be secure for one use[2]). That one can reuse the key shares for both purposes only works with Diffie-Hellman type schemes. The ones similar enough that are known for PQC are of quite uncertain security and very slow. Also, the document says: "Note that the length of this structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits [RFC1035]." Actually, you get trouble before that point: - 48,960 byte ESNI keys structure would blow the DNS RDLENGTH field due to BASE64 and TXT overheads (binary data in TXT record is a bad idea, even if in theory it would work). - About 48750 byte or thereabouts total ESNI keyset could blow DNS maximum message size, which just breaks DNS, with no recovery possible[1]. No sharp limit can be given due to precise limit depending on the domain. Also, searching if there is some pre-emptive answer in the document as to why it uses TXT as opposed to new RRTYPE, I found the following: "Clients SHOULD not fall back to cleartext SNI," I presume "SHOULD not" should be "SHOULD NOT". [1] Many DNS implementations probably treat exceeding maximum DNS message size as Undefined Behavior: They assume it never happens, and if it happens, the consequences can be anything. And these implementations can internally add stuff, and assume this added stuff will fit. [2] The one-use schemes tend to be much more efficient even with key generation for each connection included. And one can not eliminate that many key generations even for use-multiple algorithms, because reusing a key across SNI values is insecure. -Ilari From nobody Tue Jul 24 10:16:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1500813117D for ; Tue, 24 Jul 2018 10:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rIwW6gFslnUO for ; Tue, 24 Jul 2018 10:16:35 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2547131176 for ; Tue, 24 Jul 2018 10:16:34 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id A512948421; Tue, 24 Jul 2018 20:16:32 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id BpN_QzujzWh3; Tue, 24 Jul 2018 20:16:32 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 2A6D9283; Tue, 24 Jul 2018 20:16:29 +0300 (EEST) Date: Tue, 24 Jul 2018 20:16:29 +0300 From: Ilari Liusvaara To: "Patton,Christopher J" Cc: "tls@ietf.org" Message-ID: <20180724171629.GA27830@LK-Perkele-VII> References: <20180718065616.GA18428@LK-Perkele-VII> <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> <20180719193938.GA24141@LK-Perkele-VII> <20180719201846.GA24678@LK-Perkele-VII> <20180720155127.GA28236@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2018 17:16:37 -0000 On Fri, Jul 20, 2018 at 06:41:14PM +0000, Patton,Christopher J wrote: > > Thus, I believe the only valid configurations are: Sanity check: If DC is not used, then either all clients accept, or all clients reject. > * strict=true, crit=true; Both reject. Satistifes the check. > * strict=false, crit=true; and Clients that support DC accept, clients that do not support DC reject. This fails the check above. > * strict=false, crit=false. Both accept. Satisfies the check. (The fourth, strict=true, crit=false, would also fail the check). Actually, what usecase do strict certificates serve anyway? I can not figure out any usecase that would make much sense to me. Dealing with server endpoints that are capable of LURK but not proof-of-possession nor is the keyserver capable of format-checking? The usecase for the X.509 extension to signal support is to signal the service the needed infrastructure for delegating subcertificates (including having LURK as standby). -Ilari From nobody Tue Jul 24 11:04:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73DD1130E2F for ; Tue, 24 Jul 2018 11:04:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-G_dGZ0829w for ; Tue, 24 Jul 2018 11:04:33 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod06.osg.ufl.edu [128.227.74.254]) (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 26A9E130E22 for ; Tue, 24 Jul 2018 11:04:32 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.38 Received: from exmbxprd12.ad.ufl.edu ([10.36.133.38]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w6OI4TiV003714 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 24 Jul 2018 14:04:30 -0400 Received: from exmbxprd21.ad.ufl.edu (128.227.145.166) by exmbxprd12.ad.ufl.edu (10.36.133.38) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 24 Jul 2018 14:04:29 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd21.ad.ufl.edu (128.227.145.166) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 24 Jul 2018 14:04:29 -0400 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (216.32.180.87) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Tue, 24 Jul 2018 14:04:29 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHPR22MB0079.namprd22.prod.outlook.com (10.168.249.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Tue, 24 Jul 2018 18:04:28 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f%2]) with mapi id 15.20.0973.022; Tue, 24 Jul 2018 18:04:27 +0000 From: "Patton,Christopher J" To: Ilari Liusvaara CC: "tls@ietf.org" Thread-Topic: [TLS] Proposed changes to draft-ietf-tls-subcerts Thread-Index: AQHUHjQqsE1M6CF49EGVkJJk0Fkh4aSUjG8AgACw7A+AAEu7AIABYHq/gAAKfACAAAOdc4AAB1IAgAABKuKAAUZ7gIAAJjiBgAY63oCAAAqVOA== Date: Tue, 24 Jul 2018 18:04:27 +0000 Message-ID: References: <20180718065616.GA18428@LK-Perkele-VII> <18b301d41ee2$bff8e8f0$3feabad0$@gmail.com> <20180719193938.GA24141@LK-Perkele-VII> <20180719201846.GA24678@LK-Perkele-VII> <20180720155127.GA28236@LK-Perkele-VII> , <20180724171629.GA27830@LK-Perkele-VII> In-Reply-To: <20180724171629.GA27830@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8210:e59c:725d:ec6e:3ce1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB0079; 6:dkDFsFV528IeRl3KqokxQJQUqkCxs8YjNe1FIQOyHiOT6t6Q/ZQV6uZkWR7TgOh3+xjGVZrn3LTSCGi3dnnAdX+iblo1hovJ5e2GrlY/083GEdS6nxs6zNTFtfYI5LeX5tEPdDweKMRJ8g4Vi0TwVhYwfHmX2gx4DB13DONp4ug81O1vRCHFt9uNdjqgMMLiu1G/7H5JFUFoOv0GDh9JxFhUotBS64RAs+ZFITyevs+XuK4SO0tZxWTUJMEt+A7Tt+YmM7aKvj+on/BvneWqIG4NL1ou2OmMZaa0fKORL+tr1h3pPnhQ4a8H32TKWeUXMJ3Qhh8PFa7VQ3bIMcRecufKwnY3HcFEtbqYmL3dwjA9nIXOv0Wqq4zNFeMIgnWSGtYQKKCLtkVWPpTTDH/uMHofsvVc8fnAJJLRYUCBsQaHafmSqWUlQRNPNBHfMZL05JYExjQpI3frDryP/RxRjQ==; 5:zD7zqAS/MT54mWddSkjdqOSkW5xx4kejhxrAMhem7S6IMVt9qaGQ7iXuA5q2O1b8/1niYuEnhWdTPKE8hANVk09yZZkEzGkGfTXnSHmUXOVt5KRNqPhI3MQ73BpGvv9SN3LxwD14cSS9dl52oXhYQIhNBoxPf5/FOsRbzXXpkLo=; 7:YHDdO3sgA39VoTqMkObn1dXTTMxrbpOm23wo6gNJFeQHYU3v8DFcINfWXM4lOIyRyi0EBTVem9SYhIxkHCzUlLvrPrihcE8yKyzomH0ee3x1YHo7iV13ekivJJsXe6gJVHklxV/JbIMN2RcW88/c43uxlb7j3lNn8XkNv7ugCxP6rL7xScEvTbbNjiph8ThsWtHgwxYv5NMbsI8fGrzwhX5h1UUJ5QzNzrUtA1bDKByTl+6RQJYnmNztyMaGwgCd x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ad262727-f0af-4cd6-bfb9-08d5f18fe58a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0079; x-ms-traffictypediagnostic: MWHPR22MB0079: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011)(7699016); SRVR:MWHPR22MB0079; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0079; x-forefront-prvs: 0743E8D0A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(39860400002)(136003)(366004)(346002)(199004)(189003)(75432002)(102836004)(478600001)(486006)(81156014)(81166006)(6606003)(46003)(6116002)(186003)(476003)(8936002)(2906002)(55016002)(9686003)(54896002)(68736007)(97736004)(6436002)(86362001)(6246003)(93886005)(2900100001)(229853002)(99286004)(33656002)(316002)(4326008)(105586002)(74316002)(786003)(256004)(11346002)(19627405001)(25786009)(6916009)(7696005)(8676002)(6506007)(14454004)(76176011)(446003)(5250100002)(5660300001)(88552002)(106356001)(53936002)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0079; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: Y/O2a9IUplfE0CAJnaI+lo9h8ybko/WP7ivgPO7/hBQASSECQs5BjWXWUL515CflRUEGfQsG/uYMeBE89Rzfltwl7CNrOJqEreWtpQ6r60TFeLA3Ktt+SdoUEjpCbCWY6pA5NfcP92gFBNnx3w/YlZ5+DUy1ZblUJy+1EmucVhE6LUFwn+mD8HkvR9RmpjmmO+FxAKTMKgI2ljui2dzG/zLy7qol9ttlib+qMnB7gkF3oeqfgKgZoR7CrKzAJwhmqL9IbdQRDFeWxAY1B8mFWKAWvqvY5GOwtbGJI0XvpMt/Ff1/WZT1YZDk9dQT/LdAHAwwx9PILHy1pH58GXXhWgdm5rNcjnDdhTW2AA61zZU= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB0461C41A5D7D67FDBE2427BAC6550MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ad262727-f0af-4cd6-bfb9-08d5f18fe58a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2018 18:04:27.2562 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0079 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-24_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=767 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807240191 X-UFL-Spam-Level: * Archived-At: Subject: Re: [TLS] Proposed changes to draft-ietf-tls-subcerts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2018 18:04:37 -0000 --_000_MWHPR22MB0461C41A5D7D67FDBE2427BAC6550MWHPR22MB0461namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Aww, I see your point. You're right, it should be that crit=3Dtrue if and o= nly if crit=3Dtrue. > Actually, what usecase do strict certificates serve anyway? I can not > figure out any usecase that would make much sense to me. Dealing with > server endpoints that are capable of LURK but not proof-of-possession > nor is the keyserver capable of format-checking? The point was to enforce that, if a delegation certificate is offered in a = handshake, then a DC must be negotiated in that handshake. I wasn't actuall= y there, but I'm told that this feature was brought up at IETF. It doesn't = seem like there's a clean way to do this, and I'm not sure this feature is = worth the added complexity. I'm going to propose we drop the strict flag and let the critical bit be op= tional for the extension. What do you think? -Chris --_000_MWHPR22MB0461C41A5D7D67FDBE2427BAC6550MWHPR22MB0461namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Aww, I see your point. You're rig= ht, it should be that crit=3Dtrue if and only if crit=3Dtrue.


> Actually, what usecase = do strict certificates serve anyway? I can not

> figure out any usecase that w= ould make much sense to me. Dealing with
> server endpoints that are capable of LURK but not proof-of-posses= sion
> nor is the keyserver capable of format-checking?

The point was to enforce that, if a del= egation certificate is offered in a handshake, then a DC must be negotiated= in that handshake. I wasn't actually there, but I'm told that this feature= was brought up at IETF. It doesn't seem like there's a clean way to do this, and I'm not sure this feature is=  worth the added complexity.

I'm going to propose we drop the strict= flag and let the critical bit be optional for the extension. What do = you think?

-Chris
--_000_MWHPR22MB0461C41A5D7D67FDBE2427BAC6550MWHPR22MB0461namp_-- From nobody Tue Jul 24 12:24:18 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79826131161 for ; Tue, 24 Jul 2018 12:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eYrbnTHqwWsT for ; Tue, 24 Jul 2018 12:24:13 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod05.osg.ufl.edu [128.227.74.125]) (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 AE157130E0A for ; Tue, 24 Jul 2018 12:24:13 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.41 Received: from exmbxprd15.ad.ufl.edu ([10.36.133.41]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w6OJOCmj001540 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT) for ; Tue, 24 Jul 2018 15:24:12 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd15.ad.ufl.edu (10.36.133.41) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 24 Jul 2018 15:24:12 -0400 Received: from exmbxprd23.ad.ufl.edu (2002:80e3:91a7::80e3:91a7) by exmbxprd23.ad.ufl.edu (2002:80e3:91a7::80e3:91a7) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 24 Jul 2018 15:24:12 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (207.46.163.47) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Tue, 24 Jul 2018 15:24:12 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHPR22MB0493.namprd22.prod.outlook.com (10.173.55.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Tue, 24 Jul 2018 19:24:09 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::d523:1716:f973:221f%2]) with mapi id 15.20.0973.022; Tue, 24 Jul 2018 19:24:09 +0000 From: "Patton,Christopher J" To: "tls@ietf.org" Thread-Topic: Proposals for draft-ietf-tls-subcerts-02 Thread-Index: AQHUI4J2izOpwygh4UiboxDIYgPCqQ== Date: Tue, 24 Jul 2018 19:24:09 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8210:e59c:725d:ec6e:3ce1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB0493; 6:D9g2GrBWKsBhBPHjtUmxctZZAsIXUqwzDnQLSmRvG80nWaQc1URgb/o7qKy4wgjv22voDIABBbjNpIVza8lMOauqLN5Ap9goIVvhy04MkF3s33SyXLY029ZnjuqTQqXp8CGrgAe1zqtwnelhoXCNgl476fYw+Vaxzy90xggPseY9ohWsG0GlBjKM29Z7lODvVqNc3IAFybyV9bio+naK5deYipizAli6Sqs5AO68YrCw9yyIMbAoiVl0j99y6h+pH/ZFHZL3VJccfLlYBBK2sR1jOR8BGTp9Jy30XokUyDb7wugr7RRZ5g1sObYi7Dagn1clpH1gLP6MDIcYTV6m2BIxK6mWzZfIyUrjt5CQigIjejk3yhlupo7a0X0i1RMU+tJ0AO+fOMGDEj5CXp3pSEe0Pjy+qtUeKbogs3vGPjc9NZzEytm40ilc6+DUX/+7QmYVX4b1ZnACU7B8mqugZg==; 5:BpQntUJ+05CimS7GHlS/m0y6wvScF6h01hrYvDcloPh1hFsNg5iv6R1yrtST+FJrc0DC94OFi/CMzZCXwZ+pNnBhZCtDFYE7IhcIc4oSX82ttm4mf8k8FfXyah83Zm5Cg0L7+VQrHAvY1sDh1pR62Jl90psYmXtJSmSgckmsvao=; 7:6p3CprBfnbXEdn5b1zfe8mYhXpvfMxMWEKonj1NYDfNZsqX1gwJDuH7ZvwDVcU/lxzcyDuaaiBTMgwddZsAfgjY3v250hMCP88khD3HbPCXwWITfRTtFmH4z97RbZQHZC7cPvfAkchWMAFjPpL3Cy7YF5JxvDo6/ElYL2HPa7CCZTsnfNi0Qt9m3TxAA9UxgDZQEbTQ2GF1/siGzGay2/tkYiyYeznHTDbyPzdJSko2F0Zq3A5wflqNkpJswLK9G x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7f261bea-7dfc-4d45-65d5-08d5f19b07a3 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(5600073)(711020)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0493; x-ms-traffictypediagnostic: MWHPR22MB0493: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231311)(944501410)(52105095)(93006095)(93001095)(3002001)(10201501046)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MWHPR22MB0493; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0493; x-forefront-prvs: 0743E8D0A6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(396003)(366004)(199004)(189003)(53754006)(6606003)(256004)(88552002)(2900100001)(5660300001)(105586002)(6116002)(2351001)(606006)(106356001)(5640700003)(6306002)(53936002)(55016002)(74316002)(9686003)(54896002)(25786009)(6916009)(97736004)(6436002)(75432002)(53336002)(236005)(68736007)(46003)(478600001)(19627405001)(8936002)(33656002)(6506007)(81166006)(81156014)(14454004)(1730700003)(7736002)(2906002)(7696005)(8676002)(186003)(966005)(86362001)(102836004)(99286004)(5250100002)(316002)(476003)(2501003)(486006)(786003); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0493; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: JHIQjMdPucKpImw+kNbW3ah4iFVNyI72AROco6BpPl7K7aUd3r5rkCEOt8p26e+XR3xSZYEu1rw/pY8QSS4yvTXM+iNylZeX0R6tKzyRojHRX1E7LEDvXv8GvlS9fVEHOFviFS43o+8jnF1wMfu44DXNU+2FdqfPh3toDoY5QYAv+My409Mr8OTv4wWvvB6OVswe3yjNMoq55SfCqFfOUMNkWFIuxZ4Fus31rw9QfsOWM1fh4WW7lh5kELO1wZwgto96OFGSeVQAObW3951KuJNpgS5mprvsejcTGzX5QURXF2Y5koBB9rhEubS7iqYAS5+fUeI4N4wPvtCD5w88FWC61zokGLLHR/k48lb3J6Q= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB046162AC2C43A3A56FB1A8C4C6550MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7f261bea-7dfc-4d45-65d5-08d5f19b07a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2018 19:24:09.0454 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0493 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=508 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807240204 X-UFL-Spam-Level: * Archived-At: Subject: [TLS] Proposals for draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2018 19:24:17 -0000 --_000_MWHPR22MB046162AC2C43A3A56FB1A8C4C6550MWHPR22MB0461namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I've taken the liberty of addressing the changes to the delegated credentia= ls extension that were requested at IETF: https://github.com/tlswg/tls-subcerts/pull/13 The changes that would be adopted in draft-02 are as follows: * Drop support for TLS 1.2. * Allow the critical bit of the X.509 extension to be set. * Add the protocol version and credential signature algorithm to the Cr= edential structure. * Make the KeyUsage of the delegation certificate stricter. * Specify undefined behavior in a few cases. It was suggested that we add optional "must-use-DC" semantics to the certif= icate. The solution we came up with was to add a "strict" flag to the exten= sion that is set if (and only if) the extension is marked critical. The ide= a is that if the "strict" flag is set and the server doesn't offer a DC, th= en client must abort the handshake, In my opinion, the complexity this adds= to the protocol outweighs the potential benefits. Comments on the PR are welcome. Thanks, Chris Patton --_000_MWHPR22MB046162AC2C43A3A56FB1A8C4C6550MWHPR22MB0461namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,


I've taken the liberty of address= ing the changes to the delegated credentials extension that were requested = at IETF:

https://github.com/tlswg/tls-subcerts/pull/13

The changes that would be adopted=  in draft-02 are as follows:

  • Allow the critical bit of the X.509 extension to be set.
  • Add the protocol version and credential signature algorithm to the C= redential structure.
  • Make the KeyUsage of the delegation certificate stricter.
  • Specify undefined behavior in = a few cases.

It was suggested that we add optional "must-use-DC" semantics to = the certificate. The solution we came up with was to add a "strict&quo= t; flag to the extension that is set if (and only if) the extension is mark= ed critical. The idea is that if the "strict" flag is set and the server doesn't offer a DC, then client must abort the handshak= e, In my opinion, the complexity this adds to the protocol outweighs t= he potential benefits. 

Comments on the PR are welcome.

Thanks,
Chris Patton

--_000_MWHPR22MB046162AC2C43A3A56FB1A8C4C6550MWHPR22MB0461namp_-- From nobody Tue Jul 24 13:24:35 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32076130EC7 for ; Tue, 24 Jul 2018 13:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkDFTRuaMq-0 for ; Tue, 24 Jul 2018 13:24:31 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC52130DE4 for ; Tue, 24 Jul 2018 13:24:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id E5F9254CDD; Tue, 24 Jul 2018 23:24:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id Lt7byc9yGMfv; Tue, 24 Jul 2018 23:24:26 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 3290F286; Tue, 24 Jul 2018 23:24:24 +0300 (EEST) Date: Tue, 24 Jul 2018 23:24:23 +0300 From: Ilari Liusvaara To: "Patton,Christopher J" Cc: "tls@ietf.org" Message-ID: <20180724202423.GA28235@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Proposals for draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2018 20:24:34 -0000 On Tue, Jul 24, 2018 at 07:24:09PM +0000, Patton,Christopher J wrote: > Hi all, > > > I've taken the liberty of addressing the changes to the delegated credentials extension that were requested at IETF: > > https://github.com/tlswg/tls-subcerts/pull/13 > > > The changes that would be adopted in draft-02 are as follows: > > * Drop support for TLS 1.2. > * Allow the critical bit of the X.509 extension to be set. > * Add the protocol version and credential signature algorithm > to the Credential structure. > * Make the KeyUsage of the delegation certificate stricter. > * Specify undefined behavior in a few cases. > > It was suggested that we add optional "must-use-DC" semantics to the > certificate. The solution we came up with was to add a "strict" flag > to the extension that is set if (and only if) the extension is marked > critical. The idea is that if the "strict" flag is set and the server > doesn't offer a DC, then client must abort the handshake, In my opinion, > the complexity this adds to the protocol outweighs the potential benefits. > > Comments on the PR are welcome. This has the signifcant critical flag issue. It should at minimum be explicitly called out, as I do not know any precendent for this kind of behavior (check that some extension is critical yes, but not changing meaning of extension depending on critical flag). I watched the presentation and the resulting Q&A again. Short summary of relevant stuff: - The motivation in the slides is to reduce exposure of private keys to memory disclosure vulernabilities, without reducing performance. - The orignal proposal was to add a TLS Feature extension value. No discussion. - The drawback of "strict mode" would be causing issues with servers that can not effectively switch between certificates. - There is question about fallback. Paraphrased answer: LURK. TLS Feature extensions have some really unwnated properties here. They are never critical on client side, and they have OR-inheritance. You definitely do not want OR-inheritance here. Well, after this, the best usecase I can come up with strict flag is still dealing with LURK endpoints that can not do proof-of-possession or format checking[1]. [1] TLS 1.2 and 1.3 servers should only ask for signatures and only over the following kinds of data: - <64 bytes> 03 00 17 41 04 <64 bytes> - <64 bytes> 03 00 18 61 04 <96 bytes> - <64 bytes> 03 00 19 85 04 <132 bytes> (rare, P-521) - <64 bytes> 03 00 1A 41 04 <64 bytes> (rare, brainpool) - <64 bytes> 03 00 1B 61 04 <96 bytes> (rare, brainpool) - <64 bytes> 03 00 1C 81 04 <128 bytes> (rare, brainpool) - <64 bytes> 03 00 1D 20 <32 bytes> - <64 bytes> 03 00 1E 38 <56 bytes> (rare, X448) - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <32 bytes> - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <48 bytes> None of these covers delegated credential signatures, which would cause any attempt to ask for DC signature to fail if the format is checked.. -Ilari From nobody Tue Jul 24 13:40:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E9D130E1D for ; Tue, 24 Jul 2018 13:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4hNhne3hgAhm for ; Tue, 24 Jul 2018 13:40:11 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id B9E6B1311C6 for ; Tue, 24 Jul 2018 13:40:11 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w6OKeAt4003364; Tue, 24 Jul 2018 16:40:10 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Ilari Liusvaara , "Patton,Christopher J" CC: "tls@ietf.org" Thread-Topic: [TLS] Proposals for draft-ietf-tls-subcerts-02 Thread-Index: AQHUI4J2izOpwygh4UiboxDIYgPCqaSfFKeA///BXQA= Date: Tue, 24 Jul 2018 20:40:09 +0000 Message-ID: References: <20180724202423.GA28235@LK-Perkele-VII> In-Reply-To: <20180724202423.GA28235@LK-Perkele-VII> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3615295212_1443242779" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-24_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807240217 Archived-At: Subject: Re: [TLS] Proposals for draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 24 Jul 2018 20:40:15 -0000 --B_3615295212_1443242779 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable I object to re-interpreting/overloading the Critical flag. It has one and o= nly one meaning: "If the parser does not understand the given attribute, it = must abort parsing if this attribute is marked as Critical (or ignore this a= ttribute and continue parsing if the Critical flag is not set)".=20 =EF=BB=BFOn 7/24/18, 16:25, "TLS on behalf of Ilari Liusvaara" wrote: On Tue, Jul 24, 2018 at 07:24:09PM +0000, Patton,Christopher J wrote: > Hi all, >=20 >=20 > I've taken the liberty of addressing the changes to the delegated cre= dentials extension that were requested at IETF: >=20 > https://github.com/tlswg/tls-subcerts/pull/13 >=20 >=20 > The changes that would be adopted in draft-02 are as follows: >=20 > * Drop support for TLS 1.2. > * Allow the critical bit of the X.509 extension to be set. > * Add the protocol version and credential signature algorithm > to the Credential structure. > * Make the KeyUsage of the delegation certificate stricter. > * Specify undefined behavior in a few cases. >=20 > It was suggested that we add optional "must-use-DC" semantics to the > certificate. The solution we came up with was to add a "strict" flag > to the extension that is set if (and only if) the extension is marked > critical. The idea is that if the "strict" flag is set and the server > doesn't offer a DC, then client must abort the handshake, In my opini= on, > the complexity this adds to the protocol outweighs the potential bene= fits. >=20 > Comments on the PR are welcome. =20 This has the signifcant critical flag issue. It should at minimum be explicitly called out, as I do not know any precendent for this kind of behavior (check that some extension is critical yes, but not changing meaning of extension depending on critical flag). =20 =20 I watched the presentation and the resulting Q&A again. Short summary o= f relevant stuff: =20 - The motivation in the slides is to reduce exposure of private keys to memory disclosure vulernabilities, without reducing performance. - The orignal proposal was to add a TLS Feature extension value. No discussion. - The drawback of "strict mode" would be causing issues with servers that can not effectively switch between certificates. - There is question about fallback. Paraphrased answer: LURK. =20 =20 TLS Feature extensions have some really unwnated properties here. They are never critical on client side, and they have OR-inheritance. You definitely do not want OR-inheritance here. =20 Well, after this, the best usecase I can come up with strict flag is still dealing with LURK endpoints that can not do proof-of-possession or format checking[1]. =20 =20 [1] TLS 1.2 and 1.3 servers should only ask for signatures and only over the following kinds of data: =20 - <64 bytes> 03 00 17 41 04 <64 bytes> - <64 bytes> 03 00 18 61 04 <96 bytes> - <64 bytes> 03 00 19 85 04 <132 bytes> (rare, P-521) - <64 bytes> 03 00 1A 41 04 <64 bytes> (rare, brainpool) - <64 bytes> 03 00 1B 61 04 <96 bytes> (rare, brainpool) - <64 bytes> 03 00 1C 81 04 <128 bytes> (rare, brainpool) - <64 bytes> 03 00 1D 20 <32 bytes> - <64 bytes> 03 00 1E 38 <56 bytes> (rare, X448) - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <32 bytes> - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <48 bytes> =20 None of these covers delegated credential signatures, which would cause any attempt to ask for DC signature to fail if the format is checked.. =20 =20 =20 -Ilari =20 =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 --B_3615295212_1443242779 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUVwYJKoZIhvcNAQcCoIIUSDCCFEQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghImMIIE6jCCA9KgAwIBAgIKf1wD4wAAAABy/jANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE2MDIwODE2NDIxNVoXDTE5MDIwNzE2NDIxNVow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCptkku3FBE/JUsv30SQmvScGwgm2avDBSHt2TRtRWU WjiUZSdqf1t9vj+yy6JMT4w8rFYPpa4ZH53BhitZGrl8bgxT+pSqgNzI8WBHQpFl0hhEDRHO DIUNV3wzmGFGc0r3Z1wXWiT7yIy7EC+lRW52DeoM/SnTpE2DhYtxPcZV+bwXy5vXbJisbi+A 97HuUrCRc4TfCnAUrpLVHlMTJTOQ1UO2BgjYGhkQlMNRQL/rOLf8YfJ+E0gquHxK/PtwV5GN YypzhDyVU8olT6FbkXax4wMuv+q6YC0FzJw9kGTz4OUyApjKIV7rP2Sxyk+gQ6etKHx96CHR COo09a8yobi3AgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUHBlcQuNApu75siC8Ez6XNA9uD4Ew DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBjAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAC7EHnueQnXkPHa0yG8x dPNjPixt41bYXpGVvOVM6HjbS7A9YzfFfqOjF1ixSlsDb7kJHn+l3UdH/hP+L9dI8fH+Rd01 c2O/fnW740s5tpqz1uufSxUniDPMrAInxGW91lw/3PJb/zbqZYtgZnAw/wAON3KUnffttgIJ KmP7j/fuLHoqhNOATCGfXX3+xES3IPPSUvWemnGxIOJ37UOjCPzGDJKKRjRR6IzP5but8A+G /F8/anRfx4nVlhSdHt7N7DNbKvTpqsyzhjCoXRnM4Vt0xFNinK1OGiMTsX2/IT6UnHQAF+wL e73u1IM/5IQbYobyOibogjfBAj4vGlGv56owggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIE7TCCA9WgAwIBAgIK MziUjwAAAABuljANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE2MDExNDE3MzAzOVoXDTE5MDExMzE3MzAzOVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQDjFDaGib07mHBdNaVMNpj9+4iJa+K9AcTN3y+iU1ygtvHG4coteDBf77ZN1uwdt+lodW0C 8XyG43suSfpNp/owLOUElFagAnPqHAvAUIwsl5AjzncpJP+78Ui4u34aMNsddP+QZu9HI2Qg +P6eMD25jkjybT9dQMxXZpO2oTBznlWjYIItdZhK1DWZqIR0at7n2YjCSQsZNX0lJ4JwrtjH YFrYPnnZC0f1B2M7V54IS863CEyfu5XotoZx8YuHwYpKSFq80SEh6cMDLdTe1ZAjWxsnbyKC 64rreStyI2PVN9uBWd+OleGoIAjVogpMKKi0pSRHcCuwDwGekpQVubK9AgMBAAGjggG1MIIB sTAdBgNVHQ4EFgQU8U/FiJmibLZl2+KcNbVWE2PZipswDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTMwJwYIKwYBBQUHMAGGG2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Ud h+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIBBTAlBgNVHSUEHjAcBgRVHSUABggrBgEF BQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCB DnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABMAFUAcwBlAHIARQBuAGMALQBT AFcwDQYJKoZIhvcNAQELBQADggEBABbuvs9m0gS5U8JJuVc+qttV2BWQ0jDepXpYfP/xN8rV ScRPHe2SMUaFH5OMRhheGJkdogWVNnMrjHxQfpfc0z8yotlD3xwXENWUY5MoQmpEGB2ksFqg Md121bqzR3WY84Lcosfow0MoplXs8mvO7TnozwM+PtGZs0mpp2PzBkvWdNbs2r/7wXJP6/pL d5zPvywRNhTgoVe1aN4ivIkU8svkKMggv5ZaOsonaW8JS6dUYmvvk0QvDJRIQNRR0zpQpOKp +4V/XhMZRhxQJ3DjVTjh9Q/pHKm7ARFhFr3QAJ6ocCjyzLF5issa1Vshx7ElBIk0cXhep6mL MLqGNX3azAkxggH1MIIB8QIBATBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGlu Y29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMCCn9c A+MAAAAAcv4wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgzPxTWuIaTfjL7GwP +lLcAS7hYZyHTi14h8/3xQSvnQgwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG 9w0BCQUxDxcNMTgwNzI0MjA0MDEyWjANBgkqhkiG9w0BAQEFAASCAQBngdHa4Dbal1isYZEB gQv7mZ9bW6G/JL47lRed+fe9sQYIbbXtCG10y6lkMTIWCgIBKUlHSfyuZnWeeLr9ocj6/9WO s09tbyGfFkvfZCBmpbhBN810V5rybGJd9/nS8mpDeuP+p1irOU/QJh3LjyOMSR59NkszAKTX j70rFG3P6bC1T4K6+lhPFBsOZgh44Htm5nkFKSFQPrpIfuaB+Q3u9pmKww1tLcX5qXoyl3aV 4tn5vtC41x/vzC61/3kFExC/3pC7PEeFcrkIZG+zwqklvSuch3xGveWI6ZWDRc7kIppyZEQ/ BQOgj90wZaU7X4VEp/jLGBzI6X5R0p2V+dYT --B_3615295212_1443242779-- From nobody Tue Jul 24 19:17:09 2018 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 3835413124D; Tue, 24 Jul 2018 19:17:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153248502722.22459.7723646526291266786.idtracker@ietfa.amsl.com> Date: Tue, 24 Jul 2018 19:17:07 -0700 Archived-At: Subject: [TLS] The TLS WG has placed draft-rescorla-tls-esni in state "Call For Adoption By WG Issued" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 List-Id: "This is the mailing list 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, 25 Jul 2018 02:17:07 -0000 The TLS WG has placed draft-rescorla-tls-esni in state Call For Adoption By WG Issued (entered by Joseph Salowey) The document is available at https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ Comment: At the IETF 102 Meeting in Montreal there was strong support for this document so we are calling for adoption on the list. From nobody Tue Jul 24 19:17:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712F5130EF0 for ; Tue, 24 Jul 2018 19:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVLXhloGUWxr for ; Tue, 24 Jul 2018 19:17:11 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B89130E73 for ; Tue, 24 Jul 2018 19:17:10 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id h4-v6so6232028qtj.7 for ; Tue, 24 Jul 2018 19:17:10 -0700 (PDT) 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=k5iD7yE/UF5qFl/H8bHOZvvVpIHJZ4YkEZRhBhmlIXo=; b=uIdcpH4feL+bZSEqrPB7ZCu9m2nNiKUP3v7lCVzahma4aLyJVvLEi7fz79kEQq6jup X4wO8ANA/wS1NaDTlok0MfGaBZPctaCMcMnD0FhFdoy+mbUdtbKIp/rCJzki4SsQl5Ad IIFMhLjOR2SyXdD0fEMd+ooRDWtQw/G1JBcnJfIc6NDGEZiArDss5/o/keDNwFodrQck yT+9jcVqvh5IPh6h3x2of2vs1AeU1pp/wkBU0v0bwgKC+7H8Vm28aIGepmq0vVkTfOwP W/8+q0PPp+ztqEFzueNBJgqbwBlJ45Tim0iaqzWxkRDtcmZp18sGgm/RzFsqHbWC0AeZ daVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=k5iD7yE/UF5qFl/H8bHOZvvVpIHJZ4YkEZRhBhmlIXo=; b=dVqIZWqc+0/tzFeKDk+s4SZIUL3uZQ8Uv+lihvlRO92O3CadDEA7ju8/LjtOqTUkoU zCuwMRZk7s5b04i2P+hQb/9rCrlO0rCuhTMhCZUrJykdE+lt6dMOzCY6XU7bFht81eWg /cTzBqv9+JM1rQkS7dEVIAxo2uuPc79hDTNBmNWPdgv/E3l3xi4s03k3sXe9NPGD0etk 7U2i6xHuOtuomq6ktHVqCfYqmZvdwFsWduC5+WVEgNEW9QVMgNzLg+PlCV3dy6B3upZ7 kJ8FhLzP9En8tkLL7GswMxlvbkYXYdLPxBnfVmXlQYqYmazc4NW27ptDOVzlbkh/+Kim buJQ== X-Gm-Message-State: AOUpUlENQ6ypbSLN58mwXt4tM9gwNqPJyfagbEGC2CNbiC+ae4oQE668 yYsQGbdOZ32PjQGQTFQFnGpgVJx34SDfp/OV2OxMtiSIaiZISA== X-Google-Smtp-Source: AAOMgpcmO7EA3IdIKrNm0fMJl73OJw1lRai9FrrJ6LuJj5QLCQ3PsNPd8uCswBhwOXoVbUo6vG8sqY/js6sZv7KMq74= X-Received: by 2002:a0c:9b83:: with SMTP id o3-v6mr17499454qve.21.1532485029677; Tue, 24 Jul 2018 19:17:09 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:4349:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 19:16:49 -0700 (PDT) From: Joseph Salowey Date: Tue, 24 Jul 2018 19:16:49 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000d1643e0571c979e7" Archived-At: Subject: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 02:17:19 -0000 --000000000000d1643e0571c979e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The sense of the TLS@IETF102 room was the the WG should adopt https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. But, we need to confirm this on list. If you would like for this draft to become a WG document and you are willing to review it as it moves through the process, then please let the list know by 2359UTC 20180807. If you are opposed to this being a WG document, please say so (and say why). Note that the draft has been marked as a "Candidate for WG Adoption=E2=80= =9D in the datatracker. --000000000000d1643e0571c979e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

https://datatracker.ietf.org/doc/draft-rescorla-tls= -esni/=C2=A0as= a WG item.=C2=A0 But, we need to confirm this on list.=C2=A0 If you would = like for this draft to become a WG document and you are willing to review i= t as it moves through the process, then please let the list know by 2359UTC= 20180807.=C2=A0 If you are opposed to this being a WG document, please say= so (and say why).

Note that the draft has been marked as a "Ca= ndidate for WG Adoption=E2=80=9D in the datatracker.


--000000000000d1643e0571c979e7-- From nobody Tue Jul 24 19:19:03 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB3E3130EEB for ; Tue, 24 Jul 2018 19:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iforhQn07HMt for ; Tue, 24 Jul 2018 19:18:59 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (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 B3160130E1C for ; Tue, 24 Jul 2018 19:18:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1532485138; x=2396398738; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=t4Ry2xhgHXDpeqe663ukyhTuMhhPQJhy5eJxMgqggf0=; b=AGIbEVHRUp8aXbf1Z1mBoufSy4RPx5SnpDUypL+qNZpAlwnBilRsm8R2mEWDV8fQ U/UTpNIDlyreUZqmW1JN3F5fGunkOVfeiY39FHEHiw3fg/qKO1ATrqWJiKLRzVyz YxJk2uZFSav4bd8Rf7S/rexMzSe5MdZMm0TRTncEjNDh9ZnlnU7M6dMNLTaOK+Dg fC6ZYhW4l7bnJFjl1j5YWLRd71V5Un76OD8AaEMtQ+BhTWeUiyijIlXHjqCTo9AA hhjLfLzwPjHSfmwPjHD01HpVyqz02c8okKBXUa2hRHkIo90Y/TNeBM8AKjOTabz3 g9T92tPa0nXgDZh535xVrQ==; X-AuditID: 11973e11-4fbff70000005b22-53-5b57de117b92 Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) (using TLS with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 79.6D.23330.21ED75B5; Tue, 24 Jul 2018 19:18:58 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_FXwVOf2xrE0RqQdhXCNttg)" Received: from nwk-mmpp-sz12.apple.com (nwk-mmpp-sz12.apple.com [17.128.115.204]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PCE00DA7H3LH630@ma1-mtap-s01.corp.apple.com>; Tue, 24 Jul 2018 19:18:57 -0700 (PDT) Received: from process_viserion-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCE00B00GLGV800@nwk-mmpp-sz12.apple.com>; Tue, 24 Jul 2018 19:18:57 -0700 (PDT) X-Va-A: X-Va-T-CD: 1301b1c0aa1c6cb76303293bc8826a08 X-Va-E-CD: 12a7eb8f73e6cdf420f8fe806662bf89 X-Va-R-CD: 0b7794c5a077c4330417a6c7cb8d9512 X-Va-CD: 0 X-Va-ID: afb73ec4-4f0a-4a54-9eb5-024752b8b086 X-V-A: X-V-T-CD: 1301b1c0aa1c6cb76303293bc8826a08 X-V-E-CD: 12a7eb8f73e6cdf420f8fe806662bf89 X-V-R-CD: 0b7794c5a077c4330417a6c7cb8d9512 X-V-CD: 0 X-V-ID: c13b27fd-a3b3-4237-bc7a-a40bdb31e489 Received: from process_milters-daemon.nwk-mmpp-sz12.apple.com by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PCE00E00GRH7R00@nwk-mmpp-sz12.apple.com>; Tue, 24 Jul 2018 19:18:56 -0700 (PDT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-07-24_07:,, signatures=0 X-Proofpoint-Scanner-Instance: nwk-grpmailp-qapp15.corp.apple.com-10000_instance1 Received: from [17.234.31.202] by nwk-mmpp-sz12.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PCE009LWH3K9W70@nwk-mmpp-sz12.apple.com>; Tue, 24 Jul 2018 19:18:56 -0700 (PDT) Sender: dschinazi@apple.com From: David Schinazi Message-id: <0480BB90-0C76-4968-A6BC-CFC77F8577CD@apple.com> Date: Tue, 24 Jul 2018 19:18:55 -0700 In-reply-to: Cc: "" To: Joseph Salowey References: X-Mailer: Apple Mail (2.3445.9.1) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFIsWRmVeSWpSXmKPExsUiqOHDqit0LzzaYMttFYttm/azW3w638Xo wOSxZMlPJo/juzawBzBFcdmkpOZklqUW6dslcGV8fLyPqWCuQsW57g+sDYwXZboYOTgkBEwk Hp3062Lk4hAS2McksXbbAsYuRk4OXgFBiR+T77GA2MwCYRIvLl5nhSjayCTRuesgG4TTxSSx vOsYWJWEALvEn187oGxtia/HP7LC2PP/72GC2KYtcWOOCkSYS2LB1tNQJboS+58dYoOw2STW n1jCBGFrSaz70cUIY/dNfcICY3//2cIOYXNKnP8yEcrWkdiw5C0LxG2dTBLHj31ghkhkS1x+ sgRqQbDEn0M9zBBFXxklZi7+CNYtLCAt0XXhLivIoWxAGw6sMYKEhI3E/r/bmCBKbCQ+brkJ Vs4ioCpxumsDmM0JNHPD5WPMkNBSlpjVtRzsMREBFYmGxUfB9goJBEgsbzoO9YCiRP+aQ2wT GBVmIQX2LKTAngV0BbOAusSUKbkQYW2JJ+8usELYahILfy9iQhZfwMi2ilEoNzEzRzczz0gv saAgJ1UvOT93EyMosUy3E9zBeHyV1SFGAQ5GJR5eD8fwaCHWxLLiytxDjNIcLErivBtSwqKF BNITS1KzU1MLUovii0pzUosPMTJxcEo1MJbtetabUaazssMuOTMm7sDhfYdO2p2Iv5urMeNV Zn/m/4q1b7dVnF3yY77onZQz2p07vK9pc60q6PppI/n9c5twoKDJjddn65jf+fzZxycRdOSY YcabSzd3X7P5mhuytXT9+sYPZrs4757g2G3kUvkyaJVXs7uDpPEt5b0JE3U2H3MwKm6d4qDE UpyRaKjFXFScCACJZTrfDQMAAA== Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 02:19:02 -0000 --Boundary_(ID_FXwVOf2xrE0RqQdhXCNttg) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable I support adoption, and I'm happy to review it. David > On Jul 24, 2018, at 19:16, Joseph Salowey wrote: >=20 >=20 > The sense of the TLS@IETF102 room was the the WG should adopt = https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ = as a WG = item. But, we need to confirm this on list. If you would like for this = draft to become a WG document and you are willing to review it as it = moves through the process, then please let the list know by 2359UTC = 20180807. If you are opposed to this being a WG document, please say so = (and say why). >=20 > Note that the draft has been marked as a "Candidate for WG Adoption=E2=80= =9D in the datatracker. >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Boundary_(ID_FXwVOf2xrE0RqQdhXCNttg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable I = support adoption, and I'm happy to review it.

David


On Jul 24, 2018, at 19:16, Joseph Salowey <joe@salowey.net> = wrote:


The sense of the = TLS@IETF102 room was the the WG should adopt https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item.  But, we need to confirm this = on list.  If you would like for this draft to become a WG document = and you are willing to review it as it moves through the process, then = please let the list know by 2359UTC 20180807.  If you are opposed = to this being a WG document, please say so (and say why).

Note that the draft = has been marked as a "Candidate for WG Adoption=E2=80=9D in the = datatracker.


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

= --Boundary_(ID_FXwVOf2xrE0RqQdhXCNttg)-- From nobody Tue Jul 24 20:08:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64934124BE5 for ; Tue, 24 Jul 2018 20:08:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.25 X-Spam-Level: X-Spam-Status: No, score=-9.25 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tXpfLJWN0gsu for ; Tue, 24 Jul 2018 20:08:27 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF582120049 for ; Tue, 24 Jul 2018 20:08:26 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id b15-v6so6296759qtp.11 for ; Tue, 24 Jul 2018 20:08:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dQeZUtlWH13a2j5Z32l9g7/oGVbQ8XvtrNLzL4hg+1U=; b=PKq0nWoE13qGd6FXIYSMhkKr7U/5W11k3H0xv6Z9NXMvakFCgaw4DPZn/x9lQHfUgp 1wBq2kMM47ARN7SmO9rh6IZj423oJFUT4b5S4zDOVrnOtGLPiBAtiFS24Ff41HcslXK7 JfkpbWNsrGuQHGUAaRsgCZoE0tSFg8ynTi7h0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=dQeZUtlWH13a2j5Z32l9g7/oGVbQ8XvtrNLzL4hg+1U=; b=RW+USBlqfwA1iZIJdCUa0LCnrQNYmgB6ovdB/AvdeAT3A4bAVqiUAg8keXtb42Hpm+ YzbvQHCnC7qHtMeFWTw7tIcA+MxhjrPzgzkdlbJN5KtKTCO79K/RwD5aCIK+CpbaQj3z RSODE0l1xHO+DdwBTAp0Mn+RFQNdMdLUD43GoGflcBtBbuFXLSFOwAVs64BlvAXG0aqm 6776wLiezZiw9LHPJcV1DdutjpBUawJetQqXtpV1Hl+hbBpnquHyI5dshO/h8K6TmMtZ jd4jevsJ5qXzBDz4IJ+ILgnzfu5HfjfXteURluAuMwhhTSTZ9mjEfC7UVQhfKak2cmhM AmZw== X-Gm-Message-State: AOUpUlEOPU/8u57WrPM44NHuYsdDaSUcp4CQT8c/2IMq4ZA7TIVRqhS5 x5QtKnTrBc+yWWNYgeJcJXq2aeewwiRosVuBMvLw X-Google-Smtp-Source: AAOMgpe/opuR4MGn5ZTezKxtDCb/6TkQNr5Pyt0Jgyv/QgEVLUCfceaB0PyQK16QakANxz86bB36iBUXtfbWe4Obc9g= X-Received: by 2002:a0c:d1b7:: with SMTP id e52-v6mr17594925qvh.41.1532488105730; Tue, 24 Jul 2018 20:08:25 -0700 (PDT) MIME-Version: 1.0 References: <0480BB90-0C76-4968-A6BC-CFC77F8577CD@apple.com> In-Reply-To: <0480BB90-0C76-4968-A6BC-CFC77F8577CD@apple.com> From: David Benjamin Date: Tue, 24 Jul 2018 23:08:13 -0400 Message-ID: To: David Schinazi Cc: Joseph Salowey , "" Content-Type: multipart/alternative; boundary="0000000000002abc520571ca311b" Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 03:08:30 -0000 --0000000000002abc520571ca311b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I too support adoption and am happy to review it. On Tue, Jul 24, 2018 at 10:19 PM David Schinazi wrote= : > I support adoption, and I'm happy to review it. > > David > > > On Jul 24, 2018, at 19:16, Joseph Salowey wrote: > > > The sense of the TLS@IETF102 room was the the WG should adopt > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. > But, we need to confirm this on list. If you would like for this draft t= o > become a WG document and you are willing to review it as it moves through > the process, then please let the list know by 2359UTC 20180807. If you a= re > opposed to this being a WG document, please say so (and say why). > > Note that the draft has been marked as a "Candidate for WG Adoption=E2=80= =9D in > the datatracker. > > > _______________________________________________ > 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 > --0000000000002abc520571ca311b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I too support adoption and am happy to review it.

<= div class=3D"gmail_quote">
On Tue, Jul 24, 2018 at 10:19 PM= David Schinazi <dschinazi@apple.= com> wrote:
I support adoption, and I&= #39;m happy to review it.

David

<= /div>_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--0000000000002abc520571ca311b-- From nobody Tue Jul 24 20:26:48 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B720A130F9C for ; Tue, 24 Jul 2018 20:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCPLqdrAg0Tc for ; Tue, 24 Jul 2018 20:26:43 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3688D130F79 for ; Tue, 24 Jul 2018 20:26:43 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id u202-v6so4389086lff.9 for ; Tue, 24 Jul 2018 20:26:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ku9Jf8QrIy5SvmZZYHTbYQuPXxtdAdZbkCuNgh7nCBs=; b=Z+rp27VfG61G9d4N0lqBOm6HMib0fYCZpvQ97BnZij9OmzqiikHq5AsgWsFBQgTibX lFBRJsmdB/GPirBO4OlBVyREaj5ABBCkWiM1nnJepXECJPJUyGavNe168Nj8pFa23WT5 RR/4a8kWVe7V13pCuLe1h3owNDU5KDCwwC3OwxnmYOSDE9tvUafcfO0rCVlM5Uq0IaOu c7eZu8winLJRaa5qysh769+yVM8PgPdpGWhNwmw8gztEPsAVF+nBALQ092bR5L+TYKao VWqVJzepnXkFRpdyCOtcDEv79v6QrI/rCyTvvMYIr0Ds2VCd4MO4KcfGwuz/vk/HcnNw voiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ku9Jf8QrIy5SvmZZYHTbYQuPXxtdAdZbkCuNgh7nCBs=; b=SI5g1Gh0ogvTfN+linmOZm1WIk/2t5glGmF10PGKDQ/IGQwf8jYN9Wm8EIqKzsNYhs 7dZogHt3gXRXJem4JhkzOXUSlX/h1xSq9hPhC0Wd7maMdKfSKvO7C/j+mO92P7wTqL9R vTWk79yf4k6AGGr3FBqQFjDFllyYXFMcY67Po3iCI9JtRJYbDPxvj/iWO4klT6chpWeg DuArKLTOZEL4Zl3b8kTPyDP1IsH9vWc1/8WBIgFFb9/Z30eDuARHwJcuntFMiTsWklmv fAckFOlKuIBWdb675hBLiadPRCWirK9rpbdQ2MPin5xq1gnzq0lbPNA5t9N60PlhADyy WlBw== X-Gm-Message-State: AOUpUlG5TJuwyPaOXgEJSnEjXGHxI6JB1kAsZit7zi93AQ1FkPADRYF4 9g8lPJWJgMYihxfvHMadqESl5s5txGJsbEPQfdJung== X-Google-Smtp-Source: AAOMgpcliBSQGkkPDXN9ccsT5T3yORlL7gijXEWDuANaOCB6l3I9Eqmp99Om64evwFHytTyxUKX0ONzzdBPukB+j3Xc= X-Received: by 2002:a19:db44:: with SMTP id s65-v6mr10953535lfg.109.1532489201478; Tue, 24 Jul 2018 20:26:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Tue, 24 Jul 2018 20:26:00 -0700 (PDT) In-Reply-To: References: <0480BB90-0C76-4968-A6BC-CFC77F8577CD@apple.com> From: Eric Rescorla Date: Tue, 24 Jul 2018 20:26:00 -0700 Message-ID: To: David Benjamin Cc: David Schinazi , "" Content-Type: multipart/alternative; boundary="0000000000007a00c10571ca72ad" Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 03:26:46 -0000 --0000000000007a00c10571ca72ad Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Unsurprisingly, I support adoption On Tue, Jul 24, 2018 at 8:08 PM, David Benjamin wrote: > I too support adoption and am happy to review it. > > > On Tue, Jul 24, 2018 at 10:19 PM David Schinazi > wrote: > >> I support adoption, and I'm happy to review it. >> >> David >> >> >> On Jul 24, 2018, at 19:16, Joseph Salowey wrote: >> >> >> The sense of the TLS@IETF102 room was the the WG should adopt >> https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. >> But, we need to confirm this on list. If you would like for this draft = to >> become a WG document and you are willing to review it as it moves throug= h >> the process, then please let the list know by 2359UTC 20180807. If you = are >> opposed to this being a WG document, please say so (and say why). >> >> Note that the draft has been marked as a "Candidate for WG Adoption=E2= =80=9D in >> the datatracker. >> >> >> _______________________________________________ >> 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 > > --0000000000007a00c10571ca72ad Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Unsurprisingly, I support adoption

On Tue, Jul 24, 2018 at 8:08 PM= , David Benjamin <davidben@chromium.org> wrote:
I too support adoption and am ha= ppy to review it.


=
On Tue, Jul 24, 2018 at 10:19 PM David Schinazi <dschinazi@apple.com&= gt; wrote:
I support adoption, and I'm ha= ppy to review it.

David


On Jul 24, 2018, at 19:16, Joseph Salowey <joe@salowey.net> wrote:
=

The sense of the TLS@IETF102 room was the the WG should adopt= =C2=A0https://datatracker.ietf.org/doc/draft-= rescorla-tls-esni/=C2=A0as a WG item.=C2=A0 But, we need to confirm this on list.=C2= =A0 If you would like for this draft to become a WG document and you are wi= lling to review it as it moves through the process, then please let the lis= t know by 2359UTC 20180807.=C2=A0 If you are opposed to this being a WG doc= ument, please say so (and say why).

<= span style=3D"font-size:12.8px;text-decoration-style:initial;text-decoratio= n-color:initial;float:none;display:inline">Note that the draft has been mar= ked as a "Candidate for WG Adoption=E2=80=9D in the datatracker.


_______________________________________________
TLS mailing listTLS@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


--0000000000007a00c10571ca72ad-- From nobody Wed Jul 25 01:27:53 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A359E130E51 for ; Wed, 25 Jul 2018 01:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lMWqnccTyJdE for ; Wed, 25 Jul 2018 01:27:48 -0700 (PDT) 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 9E5FA130DC6 for ; Wed, 25 Jul 2018 01:27:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A1AA8BE47; Wed, 25 Jul 2018 09:27:45 +0100 (IST) 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 f2zYneUs_laK; Wed, 25 Jul 2018 09:27:43 +0100 (IST) Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 87378BE3E; Wed, 25 Jul 2018 09:27:43 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1532507263; bh=h2ujI0BCV5a1Hq/NFNzr2zxSejZooeSNudvnr7wUgdw=; h=Subject:To:References:From:Date:In-Reply-To:From; b=kaR32cMdAe/9f8/E8F04sSe0OjtYFcC1p4GDRxTqYozN9H1UMW+h3efw/nI/fTLsA A0fmGgSCAZXJbDpNVywQRniVUzQTIO9l2azYVuVLIMSxmKgFgUgIeH7KeL/aa8XP15 H9l8umokMS4nqUQ2I7UZwZLxAsknO1F0FadehFTo= To: Joseph Salowey , "" References: From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABzTJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPsLBgAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxM7BTQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAcLBZQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <012e57e4-c748-99ef-1021-4da83589eafe@cs.tcd.ie> Date: Wed, 25 Jul 2018 09:27:42 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GeuCSSjvLwwcyFX9HZKdamsEG92XkDuEb" Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 08:27:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GeuCSSjvLwwcyFX9HZKdamsEG92XkDuEb Content-Type: multipart/mixed; boundary="0SN0KwgRRvnHI4xSVUnAYCpk2LMLzIDFr"; protected-headers="v1" From: Stephen Farrell To: Joseph Salowey , "" Message-ID: <012e57e4-c748-99ef-1021-4da83589eafe@cs.tcd.ie> Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni References: In-Reply-To: --0SN0KwgRRvnHI4xSVUnAYCpk2LMLzIDFr Content-Type: multipart/mixed; boundary="------------A50E75714574619A9D4A8544" Content-Language: en-GB This is a multi-part message in MIME format. --------------A50E75714574619A9D4A8544 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Yeah, adopt it. I'll review. S On 25/07/18 03:16, Joseph Salowey wrote: > The sense of the TLS@IETF102 room was the the WG should adopt > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item.= > But, we need to confirm this on list. If you would like for this draft= to > become a WG document and you are willing to review it as it moves throu= gh > the process, then please let the list know by 2359UTC 20180807. If you= are > opposed to this being a WG document, please say so (and say why). >=20 > Note that the draft has been marked as a "Candidate for WG Adoption=E2=80= =9D in the > datatracker. >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------A50E75714574619A9D4A8544 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1bQyU3RlcGhlbiBGYXJy ZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZT6JAkAEEwEIACoC GwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o3cCGQEACgkQWrL6 8XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKow5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp 0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCr uFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+t AIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k4S+sN2CnYk4tTW7jHjsWarV3FLIS COObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4EIkCXAJUtzJhoFUuGaF /PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZDIJpdzh LiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelce ZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizM XnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+X QeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd8MxYNAbNYgSPtkbhZ8SJARwEEAEI AAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGtw/r1miKNGcopzvzILQ9oB8r KI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZJaf3bJXinDZ 5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u 14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpC XRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB 5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlve2Q6UTrmHxP5U22DlokCPQQTAQgA JwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eLrfbe5d4QRgtq+w6 UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWFetu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM 1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/ lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoO Y5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2DFeo9+S9f2V53Llz1WIspXJg6f+n9 lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yobyy/AUOs5Z3E+njjX1FF/ VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxOjaoP0Nu Q4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPk hnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZb KpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jrQuU3RlcGhl biBGYXJyZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgA JwUCWj1RWgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrx excr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvn crAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtg rlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5c F8R4OvB1n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaP y1/fEgIqhCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5 b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7 b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkpo rMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXR dS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGl Ru78ba0HArxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgA BgUCWj1SoAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89Sq Bd++uG06TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VO dL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD 4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lz nNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8I WOMqN2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBuQINBFo9UDIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4H Jee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOU NuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8 tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE4bGjXdJW5pKphFB2lX3d G4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbTuW/eITbMbI1eV3+fyym 9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yDaWT3NAp vi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDP ck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpny qMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayX XJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtv T51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1gwARAQABiQIlBBgBCAAP BQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6MasqXyrBjwc LmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOx iRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwm h+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNcz mq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqo p+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGsokRina9947fRWxXHh3O6 6ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN2OE0C1chqgDZQxk r+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHTzcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n /9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfj mLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZi nUk+H3pkqOKoHAy/8fST =3DTOQn -----END PGP PUBLIC KEY BLOCK----- --------------A50E75714574619A9D4A8544-- --0SN0KwgRRvnHI4xSVUnAYCpk2LMLzIDFr-- --GeuCSSjvLwwcyFX9HZKdamsEG92XkDuEb Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAltYNH4ACgkQWrL68XsX K+pboQ/+M9ctfJOCUjOov5Fx14flI5E+oonxhPe65wKn2Dpe8V/1RI49xnuacJKK 3jXkRJaPEswyh8ppZYJU19WbvKa3OnoOBDYfrI/0mSzF6R+WSewt4JghWrjikFlx Cx3VZf8Jxw5l/HJDL0Nufs5/06CHVrGsYpTi7BdhVt3w2z+eDf86kamnPvzQozLV 8POLwdiVr7Rj8Eye/PqAsW9mR8Jv4cSHwRYj1Nu0ajyoTlSPz7WhVm78KSov8Fd2 30qYjHDt8IOWx2CP9kzdqvBWTEIGuYZW+u8fJ5hgQ0SCtSOKwf+RFKSiIpRDeZyp hEzdGAxoqGEp1oFlvgIsMgORPhHunNAHKumuZ4pivWdcJJcEIE+pwPrq/mzpfHut cQWB5jqJNamfJjeoyRxWGXNdRW7uLQkjxtqhkg02Lml85wqVqBc4rfKoQwkW256M Rq8auy58WyAs+63WbgaiFq2FMIBj9GqhydV2ckA8BnEUZQbq9grXmfLwNYx8edvb RSN5NAZwnKQmtatrA8rqnYm7YinrhmVHYMYwIcV5SyfHUo9KKzp81zflpjGdMVt7 rusIdS1x44EtbMKbYBAt10/t4gCvroFDxGPX2yUFg9ITLLU1mVCXzY7btRsc6H8H VEoa8Q1lMXbSGPkEeJcrOSSyc2g2b/Yb0gRgcdlVA5fHZq1dF2g= =2s34 -----END PGP SIGNATURE----- --GeuCSSjvLwwcyFX9HZKdamsEG92XkDuEb-- From nobody Wed Jul 25 05:23:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 530B9130E12 for ; Wed, 25 Jul 2018 05:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFRPxUGM07b8 for ; Wed, 25 Jul 2018 05:23:03 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAF512DD85 for ; Wed, 25 Jul 2018 05:23:03 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by linode64.ducksong.com (Postfix) with ESMTPSA id 769593A019 for ; Wed, 25 Jul 2018 08:23:02 -0400 (EDT) Received: by mail-oi0-f45.google.com with SMTP id b15-v6so13476142oib.10 for ; Wed, 25 Jul 2018 05:23:02 -0700 (PDT) X-Gm-Message-State: AOUpUlGZkCgBgjR5ZeUinronXIewhDGgbzg8fV4ElkL3Spdgp/r1QO4S /rXaej6cggZ6TMhk94g2NDjqorfFRvqYXweb7j8= X-Google-Smtp-Source: AAOMgpeNZibVJ+d0rZaDTb8/lq+KsF7OqhKZM4Hxp3DLxOtJFWR8GEDtYv3RGZcC7cFwOW9P7gZNXywWCIXzc9MbJQA= X-Received: by 2002:aca:e30b:: with SMTP id a11-v6mr2957405oih.303.1532521382180; Wed, 25 Jul 2018 05:23:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Wed, 25 Jul 2018 05:23:01 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Wed, 25 Jul 2018 08:23:01 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Joseph Salowey Cc: "" Content-Type: multipart/alternative; boundary="000000000000987cbc0571d1f08e" Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 12:23:06 -0000 --000000000000987cbc0571d1f08e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption of this document and I will review and provide contributions to it as it evolves in the WG - its important work. -Patrick On Tue, Jul 24, 2018 at 10:16 PM, Joseph Salowey wrote: > > The sense of the TLS@IETF102 room was the the WG should adopt > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. > But, we need to confirm this on list. If you would like for this draft t= o > become a WG document and you are willing to review it as it moves through > the process, then please let the list know by 2359UTC 20180807. If you a= re > opposed to this being a WG document, please say so (and say why). > > Note that the draft has been marked as a "Candidate for WG Adoption=E2=80= =9D in > the datatracker. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --000000000000987cbc0571d1f08e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support adoption of this document and I will review= and provide contributions to it as it evolves in the WG - its important wo= rk.

-Patrick


On Tue, Jul 24, 2018 at 10:= 16 PM, Joseph Salowey <joe@salowey.net> wrote:

The sense of the TLS@IETF102 room was the the WG shoul= d adopt=C2=A0https://datatracker.ietf.org/doc= /draft-rescorla-tls-esni/=C2=A0as a WG item.=C2=A0 But, we need to confirm this on l= ist.=C2=A0 If you would like for this draft to become a WG document and you= are willing to review it as it moves through the process, then please let = the list know by 2359UTC 20180807.=C2=A0 If you are opposed to this being a= WG document, please say so (and say why).

Note that the draft has = been marked as a "Candidate for WG Adoption=E2=80=9D in the datatracke= r.



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


--000000000000987cbc0571d1f08e-- From nobody Wed Jul 25 06:37:16 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63085130E5C for ; Wed, 25 Jul 2018 06:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3cPL3gezI0S for ; Wed, 25 Jul 2018 06:37:10 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0113.outbound.protection.outlook.com [104.47.37.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 632BD130DE8 for ; Wed, 25 Jul 2018 06:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IiVAlyVbfDN30XEDPXvhW6yhF3yovtAWg5rU5vV3iBQ=; b=JOxSvqdErY9L7nTabh7ZP6U5GOY8hRDfOCpz2RgL6SlwZmwbAV70mNusC7l5wU/n3QRUI6CHrvG4/bliQC0RW6rSwTTAH4IPohkf7VQ5XJc7y97T1Gd1yIo7g4NuhBZPw4P/ogMpah104Tqd93d5fzbZUmKKumA9COQh9IrxBko= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4261.namprd08.prod.outlook.com (52.135.202.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Wed, 25 Jul 2018 13:37:08 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::694e:1dd9:1406:b83d]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::694e:1dd9:1406:b83d%4]) with mapi id 15.20.0995.014; Wed, 25 Jul 2018 13:37:08 +0000 From: Mike Bishop To: Patrick McManus , Joseph Salowey CC: "" Thread-Topic: [TLS] WG adoption call: draft-rescorla-tls-esni Thread-Index: AQHUI729y+M37BUhf0eXxXCV26DLDKSf3PmAgAAUWzA= Date: Wed, 25 Jul 2018 13:37:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [8.46.76.29] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4261; 6:8YsSYKUFacq9kykLS/ZJJ2CoGyCm+kW8S8LrakaN/fhDTGG9w/FjNoRY6yPh9FowwjuXpjGg390PN3jV4bznEFXDtKxAB2O40+SJ4XGafzpL2aiKFb4+hwAG2CyA+VSGayFnXNzhLzguYkMS2Bom8dXkHWqK+1rFcAPdWFzykTKqx9+zXWGlDZf7pvvl/1veUmAVGd3h9RbjCCom94E4n/ywFvOhWG67jznrzaR1/gnTaX31yO4gXzlYWEVtuWyCMre739xawTq/PE+5yvALk8M2THmw74b7QR9Xj20tqqNCbLIJOVryKgSGUx532V+Gff/Gnhl9y6Vz2I78btfESQ96CL73vnYY/V0YMkA5oi6wx4pN9VMKMiov1HyRTMkemR87fktr+HpBlDlh4FAPQ4r8mDiq5CkuU8DZVhTvGj23DfFUqNSvVBm9WWzTPQThu05ywpUEqup7MVF8ias6hA==; 5:TE8GSWcRHhsHBqoYxb/ltKUNHM3aAa4yQexKFtRDjSDRNolXzVS1YJhSmOuJ4dkkWm4JGuntzWsyrgzMzYpqStCGMnK/15VmaQRyaKjKi/zc+zmpjpnQn1cayiNnne3o0f2coO/jxkYxva77qx5eTyR1dDOgrJjk2jF34XkPsoE=; 7:c4PifWCk1B9YGtTDW99oVmYbdGopLYVe9ErGkknw5MeX8BVwPLMmnyduD0zjMNhkKyMcbOr3oRuyaG9XkTNQ9gEdqOKq0HTJErhSiPrP3gDF+WdTVFYATdijEMJz+x9sa7fob5bO4OxEuzv/terZ0gjgUclg+NnsGELuKtDsBbZOrF9QleSa4wx16W3f+syzgpSk9iYct+xREwmODZT0u83R6L6R6eiYN2ctIZ+v7NrIpEX/BHG+FBvkLpHBgMi4 x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: ae79362c-205f-4f31-3790-08d5f233b7cd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600073)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4261; x-ms-traffictypediagnostic: BYAPR08MB4261: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(120809045254105)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231311)(944501410)(52105095)(149027)(150027)(6041310)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(2016111802025)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB4261; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4261; x-forefront-prvs: 0744CFB5E8 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(136003)(39830400003)(366004)(396003)(189003)(199004)(446003)(186003)(6246003)(97736004)(5250100002)(256004)(4326008)(2900100001)(26005)(14444005)(478600001)(7736002)(74316002)(966005)(66066001)(99286004)(19609705001)(6506007)(11346002)(476003)(6116002)(790700001)(486006)(102836004)(3846002)(53546011)(86362001)(14454004)(25786009)(8936002)(229853002)(606006)(316002)(81166006)(81156014)(68736007)(8676002)(6436002)(55016002)(110136005)(53936002)(7696005)(76176011)(5660300001)(106356001)(2906002)(6306002)(9686003)(54896002)(105586002)(74482002)(236005)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4261; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: gWrzGoCjHq0eb88R79V3IckPc2flhRojAxa54Fjrj2Q+e6GQSRqx5OG111NPP5qjeuMnwl7ahMP6e19oQYpxOI9NA+rvh24lFqJAzuwjMK5HuEOCk5JlO89PR/vcQqhUx2/9QyKXQ//8Fxu9yBo9rg7LtDCVYpVuKM0y6x2dmd/dIH+7lTCMVOwYCuXxW3n8BQ/okWwglFObcrtAoKwIPoksqFAjAn0tFozy4YQ7x381SBZWTEOMkAtl6xl6jp29VaneJ8/5uA5rHr4jtLs3brV8WZwSodYC5sgkw8GL05JF5g/cdWnXKsSfRlSYQGy0DLfFXu3p+askqdSBLNoqkPyOJ1boWcejkSZ0LrBde1E= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB3944F429D5802E2F9EC0980DDA540BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: ae79362c-205f-4f31-3790-08d5f233b7cd X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jul 2018 13:37:07.8292 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4261 Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 13:37:14 -0000 --_000_BYAPR08MB3944F429D5802E2F9EC0980DDA540BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEg4oCTIHRoZXJlIGFyZSBjZXJ0YWlubHkga2lua3MgdG8gd29yayBvdXQsIGJ1dCB0aGlzIGlz IGEgd29ydGh3aGlsZSBkaXJlY3Rpb24uDQoNCkZyb206IFRMUyA8dGxzLWJvdW5jZXNAaWV0Zi5v cmc+IE9uIEJlaGFsZiBPZiBQYXRyaWNrIE1jTWFudXMNClNlbnQ6IFdlZG5lc2RheSwgSnVseSAy NSwgMjAxOCA4OjIzIEFNDQpUbzogSm9zZXBoIFNhbG93ZXkgPGpvZUBzYWxvd2V5Lm5ldD4NCkNj OiA8dGxzQGlldGYub3JnPiA8dGxzQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtUTFNdIFdHIGFk b3B0aW9uIGNhbGw6IGRyYWZ0LXJlc2NvcmxhLXRscy1lc25pDQoNCkkgc3VwcG9ydCBhZG9wdGlv biBvZiB0aGlzIGRvY3VtZW50IGFuZCBJIHdpbGwgcmV2aWV3IGFuZCBwcm92aWRlIGNvbnRyaWJ1 dGlvbnMgdG8gaXQgYXMgaXQgZXZvbHZlcyBpbiB0aGUgV0cgLSBpdHMgaW1wb3J0YW50IHdvcmsu DQoNCi1QYXRyaWNrDQoNCg0KT24gVHVlLCBKdWwgMjQsIDIwMTggYXQgMTA6MTYgUE0sIEpvc2Vw aCBTYWxvd2V5IDxqb2VAc2Fsb3dleS5uZXQ8bWFpbHRvOmpvZUBzYWxvd2V5Lm5ldD4+IHdyb3Rl Og0KDQpUaGUgc2Vuc2Ugb2YgdGhlIFRMU0BJRVRGMTAyIHJvb20gd2FzIHRoZSB0aGUgV0cgc2hv dWxkIGFkb3B0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlc2Nvcmxh LXRscy1lc25pLyBhcyBhIFdHIGl0ZW0uICBCdXQsIHdlIG5lZWQgdG8gY29uZmlybSB0aGlzIG9u IGxpc3QuICBJZiB5b3Ugd291bGQgbGlrZSBmb3IgdGhpcyBkcmFmdCB0byBiZWNvbWUgYSBXRyBk b2N1bWVudCBhbmQgeW91IGFyZSB3aWxsaW5nIHRvIHJldmlldyBpdCBhcyBpdCBtb3ZlcyB0aHJv dWdoIHRoZSBwcm9jZXNzLCB0aGVuIHBsZWFzZSBsZXQgdGhlIGxpc3Qga25vdyBieSAyMzU5VVRD IDIwMTgwODA3LiAgSWYgeW91IGFyZSBvcHBvc2VkIHRvIHRoaXMgYmVpbmcgYSBXRyBkb2N1bWVu dCwgcGxlYXNlIHNheSBzbyAoYW5kIHNheSB3aHkpLg0KDQpOb3RlIHRoYXQgdGhlIGRyYWZ0IGhh cyBiZWVuIG1hcmtlZCBhcyBhICJDYW5kaWRhdGUgZm9yIFdHIEFkb3B0aW9u4oCdIGluIHRoZSBk YXRhdHJhY2tlci4NCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQpUTFMgbWFpbGluZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_BYAPR08MB3944F429D5802E2F9EC0980DDA540BYAPR08MB3944namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m IzQzOzEg4oCTIHRoZXJlIGFyZSBjZXJ0YWlubHkga2lua3MgdG8gd29yayBvdXQsIGJ1dCB0aGlz IGlzIGEgd29ydGh3aGlsZSBkaXJlY3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ RnJvbTo8L2I+IFRMUyAmbHQ7dGxzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBP ZiA8L2I+DQpQYXRyaWNrIE1jTWFudXM8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBKdWx5 IDI1LCAyMDE4IDg6MjMgQU08YnI+DQo8Yj5Ubzo8L2I+IEpvc2VwaCBTYWxvd2V5ICZsdDtqb2VA c2Fsb3dleS5uZXQmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiAmbHQ7dGxzQGlldGYub3JnJmd0OyAmbHQ7 dGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gV0cgYWRvcHRp b24gY2FsbDogZHJhZnQtcmVzY29ybGEtdGxzLWVzbmk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHN1cHBvcnQgYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVudCBhbmQgSSB3 aWxsIHJldmlldyBhbmQgcHJvdmlkZSBjb250cmlidXRpb25zIHRvIGl0IGFzIGl0IGV2b2x2ZXMg aW4gdGhlIFdHIC0gaXRzIGltcG9ydGFudCB3b3JrLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tUGF0cmljazxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgSnVsIDI0LCAyMDE4 IGF0IDEwOjE2IFBNLCBKb3NlcGggU2Fsb3dleSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvZUBzYWxv d2V5Lm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmpvZUBzYWxvd2V5Lm5ldDwvYT4mZ3Q7IHdyb3RlOjxv OnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVm dDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48YnI+DQpUaGUgc2Vuc2Ugb2YgdGhlIFRMU0BJ RVRGMTAyIHJvb20gd2FzIHRoZSB0aGUgV0cgc2hvdWxkIGFkb3B0Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXJlc2NvcmxhLXRscy1l c25pLyIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQ7Y29sb3I6 IzExNTVDQyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtcmVzY29ybGEt dGxzLWVzbmkvPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij4mbmJzcDth cw0KIGEgV0cgaXRlbS4mbmJzcDsgQnV0LCB3ZSBuZWVkIHRvIGNvbmZpcm0gdGhpcyBvbiBsaXN0 LiZuYnNwOyBJZiB5b3Ugd291bGQgbGlrZSBmb3IgdGhpcyBkcmFmdCB0byBiZWNvbWUgYSBXRyBk b2N1bWVudCBhbmQgeW91IGFyZSB3aWxsaW5nIHRvIHJldmlldyBpdCBhcyBpdCBtb3ZlcyB0aHJv dWdoIHRoZSBwcm9jZXNzLCB0aGVuIHBsZWFzZSBsZXQgdGhlIGxpc3Qga25vdyBieSAyMzU5VVRD IDIwMTgwODA3LiZuYnNwOyBJZiB5b3UgYXJlIG9wcG9zZWQgdG8gdGhpcyBiZWluZw0KIGEgV0cg ZG9jdW1lbnQsIHBsZWFzZSBzYXkgc28gKGFuZCBzYXkgd2h5KS48YnI+DQo8YnI+DQpOb3RlIHRo YXQgdGhlIGRyYWZ0IGhhcyBiZWVuIG1hcmtlZCBhcyBhICZxdW90O0NhbmRpZGF0ZSBmb3IgV0cg QWRvcHRpb27igJ0gaW4gdGhlIGRhdGF0cmFja2VyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 YnI+DQpUTFMgbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOlRMU0BpZXRmLm9yZyI+ VExTQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vdGxzIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby90bHM8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BYAPR08MB3944F429D5802E2F9EC0980DDA540BYAPR08MB3944namp_-- From nobody Wed Jul 25 07:31:39 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C500A130E6B for ; Wed, 25 Jul 2018 07:31:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OmqNtAtVotAi for ; Wed, 25 Jul 2018 07:31:35 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 029F1130E60 for ; Wed, 25 Jul 2018 07:31:35 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx114.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1fiKp3-00022G-Vm for tls@ietf.org; Wed, 25 Jul 2018 16:31:32 +0200 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1fiKow-0001It-Gn for tls@ietf.org; Wed, 25 Jul 2018 10:31:22 -0400 Received: (qmail 2378 invoked from network); 25 Jul 2018 14:31:13 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.39.156]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Jul 2018 14:31:12 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-A8E00594-5F18-40BC-9D64-8A302905F347 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15F79) In-Reply-To: Date: Wed, 25 Jul 2018 07:31:10 -0700 Cc: Patrick McManus , Joseph Salowey , "" Content-Transfer-Encoding: 7bit Message-Id: <6420568B-DD8C-4E66-99E2-7B6AA9684105@huitema.net> References: To: Mike Bishop X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.05) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tDh0yuozngyunWyaM61KOF602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO5IcVwV4jjVcAOtIXxgohGFVMZsRZacTbJPGp/MBC6Bx0xBfQcv7HNlB8hb6P2djwUh5 mNm/WjPqhYqCeBiCKwwnRtk/d5gNfEtjtud5V8jpAx8WiOp3k5R0E3oWxTrHKR/TBCf6oYXAWGet lavcAjAiREicRPMV5adYQyNOvKmgizQS7ZJXB6rwDFOa1j0OJR6ijzwzq5HGxV3pRhOdYuobeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80D4WY7xWSn pVjQVprFFOt2hDWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SMPepZn00xVXQbuUt1pns FwEiRQv+PVjjwa+Z5RFCOMQrQ919hdEMji5ZXMQ3eQizQspW6PWtFljIeoG6OsM9IRol1Fs3flgk I+JB4hGXt3pgiNplmw3yp4FFFCuS+k6jh5d4Swn5E67RV+LaU4GmVjH8gYlRWMzXMtJksqe+xLeX oHkzkRzbKyRDRP8j7fY6NV+QBQRtMmDe05Nd2KjhCWh+wlfAS2SbL4bvnSO/22UCZ5GeY9OMwQ5U gLYpRapk6QA7bsUzLO2XdHo3UQoc9JRins15oKFWvUk5C9olBXB1qSIEae5DZ9cZ02JHi6IQw6nI oDr0sXUZ7YZoZ/GZ+gNl/9zCFdWYNKOuzgS95TNz5NQBt6vrTjaii/MA7FoCAhy1/eljfSN5aXns qLZLef9qwM7RXpJS8RjTdyh2j5AWyDZ7BRCxIW6XiPgk5wgNeRXbC69qDBnTAPdQSCnD1TRj9D8H LKHAKpPGP8EPnuDHTXhIrVzYteKGVryF5qVZ X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 14:31:38 -0000 --Apple-Mail-A8E00594-5F18-40BC-9D64-8A302905F347 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. I support adoption and will review. -- Christian Huitema=20 > On Jul 25, 2018, at 6:37 AM, Mike Bishop wrote: >=20 > +1 =E2=80=93 there are certainly kinks to work out, but this is a worthwhi= le direction. > =20 > From: TLS On Behalf Of Patrick McManus > Sent: Wednesday, July 25, 2018 8:23 AM > To: Joseph Salowey > Cc: > Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni > =20 > I support adoption of this document and I will review and provide contribu= tions to it as it evolves in the WG - its important work. > =20 > -Patrick > =20 > =20 > On Tue, Jul 24, 2018 at 10:16 PM, Joseph Salowey wrote: >=20 > The sense of the TLS@IETF102 room was the the WG should adopt https://data= tracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. But, we need to= confirm this on list. If you would like for this draft to become a WG docu= ment and you are willing to review it as it moves through the process, then p= lease let the list know by 2359UTC 20180807. If you are opposed to this bei= ng a WG document, please say so (and say why). >=20 > Note that the draft has been marked as a "Candidate for WG Adoption=E2=80=9D= in the datatracker. > =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-A8E00594-5F18-40BC-9D64-8A302905F347 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1. I support adoption and will review.

-- Christian Huitema 

On Jul 25, 201= 8, at 6:37 AM, Mike Bishop <mbish= op@evequefou.be> wrote:

+1 =E2=80=93 there are certainly kinks to work out, b= ut this is a worthwhile direction.

 

From: TLS <tls-bounces@ietf.org> On Behalf Of Patrick McManus
Sent: Wednesday, July 25, 2018 8:23 AM
To: Joseph Salowey <joe@salowey= .net>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni

 

I support adoption of this document and I will review= and provide contributions to it as it evolves in the WG - its important wor= k.

 

-Patrick

 

 

On Tue, Jul 24, 2018 at 10:16 PM, Joseph Salowey <= joe@salowey.net>= wrote:


The sense of the TLS@IETF102 room was the the WG should adopt https://datatracker.i= etf.org/doc/draft-rescorla-tls-esni/ as a WG item.  But, we need to confirm this on list.  If you would l= ike for this draft to become a WG document and you are willing to review it a= s it moves through the process, then please let the list know by 2359UTC 201= 80807.  If you are opposed to this being a WG document, please say so (and say why).

Note that the draft has been marked as a "Candidate for WG Adoption=E2=80=9D= in the datatracker.

 

 


_______________________________________________
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/lis= tinfo/tls
= --Apple-Mail-A8E00594-5F18-40BC-9D64-8A302905F347-- From nobody Wed Jul 25 07:32:29 2018 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 838B6131067; Wed, 25 Jul 2018 07:32:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: =?utf-8?q?Mirja_K=C3=BChlewind?= To: "The IESG" Cc: draft-ietf-tls-tls13-vectors@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.82.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153252913753.15442.1592178172017620793.idtracker@ietfa.amsl.com> Date: Wed, 25 Jul 2018 07:32:17 -0700 Archived-At: Subject: [TLS] =?utf-8?q?Mirja_K=C3=BChlewind=27s_No_Objection_on_draft-i?= =?utf-8?q?etf-tls-tls13-vectors-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 List-Id: "This is the mailing list 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, 25 Jul 2018 14:32:19 -0000 Mirja Kühlewind has entered the following ballot position for draft-ietf-tls-tls13-vectors-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Why is it really necessary to publish the test vectors in an RFC? From nobody Wed Jul 25 08:08:22 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4943126CC7; Wed, 25 Jul 2018 08:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vfG0JhhPVTPC; Wed, 25 Jul 2018 08:08:10 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F5EC129C6B; Wed, 25 Jul 2018 08:08:10 -0700 (PDT) X-AuditID: 1209190f-ea5ff70000006382-a3-5b58925965af Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id F4.9D.25474.952985B5; Wed, 25 Jul 2018 11:08:09 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id w6PF86Ov008211; Wed, 25 Jul 2018 11:08:07 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6PF81EY029950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jul 2018 11:08:04 -0400 Date: Wed, 25 Jul 2018 10:08:02 -0500 From: Benjamin Kaduk To: Mirja =?iso-8859-1?Q?K=FChlewind?= Cc: The IESG , tls@ietf.org, sean@sn3rd.com, draft-ietf-tls-tls13-vectors@ietf.org, tls-chairs@ietf.org Message-ID: <20180725150802.GS92448@kduck.kaduk.org> References: <153252913753.15442.1592178172017620793.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <153252913753.15442.1592178172017620793.idtracker@ietfa.amsl.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBKsWRmVeSWpSXmKPExsUixG6nohs5KSLaoPuigMW8HfPZLWb8mchs 8eL6R2aLK6samS3mnLjBYvHpfBejA5vHkiU/mTxaPi5k9Th4kDGAOYrLJiU1J7MstUjfLoEr 43f3VMaCXv6Ki7fOszUwbufpYuTkkBAwkXh79CNjFyMXh5DAYiaJuUuuQDkbGSVety1ggXCu MknMP/aAEaSFRUBV4sSZ22wgNpuAikRD92VmEFtEwEbi7sm7rCA2s0C9xM/1LWDNwgIzGSWe ft0HluAF2tdwbD87iC0k4CtxfNYMJoi4oMTJmU9YIJp1JHZuvQO0gAPIlpZY/o8DIiwv0bx1 NtguTgE/iaNf2sFsUQFlib19h9gnMArOQjJpFpJJsxAmzUIyaQEjyypG2ZTcKt3cxMyc4tRk 3eLkxLy81CJdE73czBK91JTSTYygSOCU5N/BOKfB+xCjAAejEg/vB7vwaCHWxLLiytxDjJIc TEqivEGeEdFCfEn5KZUZicUZ8UWlOanFhxglOJiVRHhdDgOV86YkVlalFuXDpKQ5WJTEee/V AKUE0hNLUrNTUwtSi2CyMhwcShK8zhOBhgoWpaanVqRl5pQgpJk4OEGG8wANLwCp4S0uSMwt zkyHyJ9i1OX4837qJGYhlrz8vFQpcd5QkCIBkKKM0jy4OaAEJpG9v+YVozjQW8K8ZycAVfEA kx/cpFdAS5iAlogmh4IsKUlESEk1MFabtXwLMpnXsabPpUig6smDr0bzTHc9PJC/Rp9v1Wou x5kLxTPXlF5SjX4Rv+SlePbBjVcX/BCacuR6tvQBy9gZ88pybveG2Bz6Hj6n+fXjC8JyHO7b s4q5d3H5e59S4n5jebxKqKXCZlF5+6cOnx8KIt6lj3yTPpfvfvT+rcWuj1tLo+alKCuxFGck GmoxFxUnAgDiJzfzOwMAAA== Archived-At: Subject: Re: [TLS] =?iso-8859-1?q?Mirja_K=FChlewind=27s_No_Objection_on_draft?= =?iso-8859-1?q?-ietf-tls-tls13-vectors-06=3A_=28with_COMMENT=29?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 15:08:13 -0000 On Wed, Jul 25, 2018 at 07:32:17AM -0700, Mirja Khlewind wrote: > Mirja Khlewind has entered the following ballot position for > draft-ietf-tls-tls13-vectors-06: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Why is it really necessary to publish the test vectors in an RFC? Well, hopefully we can avoid being caught in a catch-22. That is, a lot of the time when processing-heavy (especially crypto-heavy) documents come through, we ask for test vectors at IESG review if they are not already present. So in the case when the base document is already long, it seemed pretty natural to keep the test vectors in an adjacent place and the same format, just as a separate document to keep the individual document sizes down. So, I'm generally of the opinion that it's better to have test vectors than to not; it provides concrete guidance in the case when the wording of the spec is potentially unclear and it helps new implementations develop interoperability during development instead of being presented with a vague "it doesn't work" once all the pieces are implemented. We could certainly debate what the best place for documenting the test vectors is, but I think there is both precedent and a reasonable set of advantages to including them in the RFC series. -Benjamin From nobody Wed Jul 25 08:43:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3EA12D7F8 for ; Wed, 25 Jul 2018 08:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.71 X-Spam-Level: X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Ga8bwG0z6WA for ; Wed, 25 Jul 2018 08:43:31 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD7F1271FF for ; Wed, 25 Jul 2018 08:43:31 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6PFfoVv008664; Wed, 25 Jul 2018 16:43:30 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=ZxF0BDsFn8Kbi2GxFNWe6zBjDrY6Asxd9eSctDDPZS4=; b=dXnXDp6iQ67brWuHYz/OZl9rMJPQykYdMVWYYE0N/NNfbf+d+sf7mKn0ElT4FCjpeM7O iDu24bkmUdvpXY/r1odm61p4lfh5EcrwvL7xFZ5Bw8HG3FszyNeS09WMi9zONbG4lFS7 R5ssxcV8mmSNAod8GalqoRrcGkyJfjjUatSysH+T9tQjmu7i+pHuofS+7x61g0SE+1ui WAlK0SXPHpoEYnHmXUHgI5kYz1hGcwFnW8QfzHR/hZiTveJYhh45SFRVfKks/s1y6a6F cXNC809emDvAjim1g2hu1J+35xZZyWkEj5DyHRz5kpVsNqVWb1pZfKG8IAyZ4RPHtzAu pw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050102.ppops.net-00190b01. with ESMTP id 2ketng0hky-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Jul 2018 16:43:30 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6PFZ1Xh025540; Wed, 25 Jul 2018 11:43:29 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2kc05uqxx9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Jul 2018 11:43:29 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 25 Jul 2018 11:43:29 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 25 Jul 2018 11:43:28 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Wed, 25 Jul 2018 11:43:28 -0400 From: "Salz, Rich" To: Joseph Salowey , "" Thread-Topic: [TLS] WG adoption call: draft-rescorla-tls-esni Thread-Index: AQHUI721xXMwVNemiEWTohe/rqIJC6SgFPoA Date: Wed, 25 Jul 2018 15:43:28 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.215] Content-Type: multipart/alternative; boundary="_000_D83DE315EFEA4E2C8D484B42191B3130akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-25_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=872 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807250167 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-25_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=805 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807250168 Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 15:43:33 -0000 --_000_D83DE315EFEA4E2C8D484B42191B3130akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBpbiBmYXZvciBvZiBhZG9wdGlvbiBhbmQgd2lsbCB3b3JrIG9uIGl0LiAgSXTigJlzIHVz ZSBvZiBETlMgaXMgcHJvYmxlbWF0aWMgZm9yIGNhc2VzIHRoYXQgYXJlIGltcG9ydGFudCB0byB1 cy4NCg== --_000_D83DE315EFEA4E2C8D484B42191B3130akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgYW0gaW4gZmF2b3Igb2YgYWRvcHRpb24gYW5kIHdpbGwgd29yayBvbiBpdC4m bmJzcDsgSXTigJlzIHVzZSBvZiBETlMgaXMgcHJvYmxlbWF0aWMgZm9yIGNhc2VzIHRoYXQgYXJl IGltcG9ydGFudCB0byB1cy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_D83DE315EFEA4E2C8D484B42191B3130akamaicom_-- From nobody Wed Jul 25 09:33:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DFA3130DC0 for ; Wed, 25 Jul 2018 09:33:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sw1fycW3Vqp2 for ; Wed, 25 Jul 2018 09:33:10 -0700 (PDT) Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF1B2126BED for ; Wed, 25 Jul 2018 09:33:09 -0700 (PDT) Received: by mail-ua0-x234.google.com with SMTP id q12-v6so5476780ual.2 for ; Wed, 25 Jul 2018 09:33:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=amtGPgG3FIb/QLFyncQ7YkQw7v0vOUS0dAM/rHxT+WU=; b=bBGJaZuv7nQKAtJkiskW6pT7telpQ5gR0h35rMLXdQx4X1rCCT7X1pPl8xywherP4u XM3ylfCVBSikFPTB0oK5LWQVmpgKzHfxjJwH9DWM1x2eow4ovUi1g0FNgGZepTkDDsEe rRQ7DbPdTIiRO+14rA+fXxINylsbTx8YBqIqg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=amtGPgG3FIb/QLFyncQ7YkQw7v0vOUS0dAM/rHxT+WU=; b=Msz83/Y+18zPz0QXnyZb8IvSnvCWNmvp4VmuzxtX3VizDY+XZDy5sAQikkHxi3jFyX AmXUyjSxCFUeD143gys16NLmRzAZeMQyWiRcr0PjRLejOBc5xaZRHXqrSC++Aqgvj3/+ cnskgu/3izKynJVL0MS7FQ7Vz9FTyIVJtJcwj//NZMlAZbCFxmlZK13K0Px5f4FtXZic qPZ5gvONd+VsQR72iur7RHUGwtlTJ1Kn20wc7ZYUv/Cr0spIrXTKvN9RKBFr13NJRb75 C71cgD49ot6Sc+QtfWVYypYL6gIQkUl/hqz2AXWVif+dN8x1+8cyuDEgIMONiScnrr+C oSGw== X-Gm-Message-State: AOUpUlHQO6zk0bFksxdzRK4PqU+lKS2sJDPCztQCJ8H8z9c212UN/p1A IV6SbzkEJzBkPEUH/DU0TVGS3immw+uwwFweBpQS+Q== X-Google-Smtp-Source: AAOMgpd2fD8SfD1YQjBuvCfQTtGYSDSVTfnZJqNG1b3eE+70eY9YlXWL35HdzBhSgLXrOiuvWbpEm6pQt0NJB3XipBI= X-Received: by 2002:ab0:50cd:: with SMTP id d13-v6mr15420889uaa.45.1532536388610; Wed, 25 Jul 2018 09:33:08 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Joseph Lorenzo Hall Date: Wed, 25 Jul 2018 12:32:57 -0400 Message-ID: To: Joseph Salowey Cc: TLS WG Content-Type: multipart/alternative; boundary="0000000000000c817a0571d56fdf" Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 25 Jul 2018 16:33:13 -0000 --0000000000000c817a0571d56fdf Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable support, will review On Tue, Jul 24, 2018 at 10:17 PM Joseph Salowey wrote: > > The sense of the TLS@IETF102 room was the the WG should adopt > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. > But, we need to confirm this on list. If you would like for this draft t= o > become a WG document and you are willing to review it as it moves through > the process, then please let the list know by 2359UTC 20180807. If you a= re > opposed to this being a WG document, please say so (and say why). > > Note that the draft has been marked as a "Candidate for WG Adoption=E2=80= =9D in > the datatracker. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --0000000000000c817a0571d56fdf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
support, will review

On Tue, Jul 24, 2018 at 10:17 PM Joseph Salowey <joe@salowey.net> wrote:

The sense of the TLS@IETF102 room was the the= WG should adopt=C2=A0https://datatracker.ietf.org= /doc/draft-rescorla-tls-esni/
Note that the draft has = been marked as a "Candidate for WG Adoption=E2=80=9D in the datatracke= r.


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


--
Jo= seph Lorenzo Hall
Chief Technologist, Center for Democracy & Technol= ogy [https://www.cdt.org<= /a>]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: <= a href=3D"https://josephhall.org/gpg-key" target=3D"_blank">https://josephh= all.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F8= 6 6987 40A9 A871

--0000000000000c817a0571d56fdf-- From nobody Wed Jul 25 23:44:09 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70642130E03 for ; Wed, 25 Jul 2018 23:44:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.02 X-Spam-Level: X-Spam-Status: No, score=-6.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tefEXuq27Po0 for ; Wed, 25 Jul 2018 23:44:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 4FE5B130DD2 for ; Wed, 25 Jul 2018 23:44:03 -0700 (PDT) Received: from [192.168.3.222] (ip-86-49-243-161.net.upcbroadband.cz [86.49.243.161]) by mail.nic.cz (Postfix) with ESMTPSA id B43B66079C for ; Thu, 26 Jul 2018 08:44:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1532587440; bh=cHV9bUcj9iTdA6XmqBtHWtz+bLAU7nn7bF975d7GSic=; h=To:From:Date; b=TqlGJ6z8PwbkgWh0cp4ngL0bl2bv6gc9UiXtNZOmoGpFlneSd2cxW6EDGokEWztJY PkwWMTyyA0jaBKYi2SRE/oz76U7T64yUe8GZy347YfBIOJI3j6C+NY0Xgw6vVMH9Y4 G3QYtfmIMhLIywXgSBS/QmRrxAvyPQfvtNuW7qy8= To: tls@ietf.org References: From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Openpgp: preference=signencrypt Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= xsFNBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABzSJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+wsF9BBMBCAAnBQJYa4wfAhsDBQkDwmcABQsJCAcC BhUICQoLAgQWAgMBAh4BAheAAAoJEM6N1qGlCiHkjGoP/3fvimzczcaqPM8lgY9fKKcr2DhH 42HF+fXsj0SvPeEoYDuWwIcsTGna6sdmrhCD/mB6eCNivAOcZYDH7j3YDgdFX2xy1sRY0ylF uyfcOT1Qn1xNTglSaf00gUWDgLBQB/USphB9Of6U1ka4gLJpCWKoZ3cLQe09cUpq9HOZYs/g WSNx9UTr06fcO0rtgZpg+IZJN/R2ORhQBwk4n2Dtx5J+Xyoy7ht1Fwz07BWAGJ4P8oJOhsi1 LukDD8ul3+6IeoSbRvyGpP6boegaMwxPR10VgsrYU2t1cK58iRv/xJ3TClb0JBn5aI3Bmh1j mPROrC55tvxRoeRLmxXHzbPZpWdbRjEcf9SEiAGNTgo9C+eXbubeSETWgisfJhZ4ebhkHnfz e+e+hvbaTSoFyMbKeOlfoYCmaDRBgT53i72HIkvO+HrVcmulZytw/yyOHuwObEFVgn3AeORv rb8I1kiv5W4wnZxDslhCeRR+wMGiKhc9ewU/mg3Rqo6GN+8mT0DHnsHuq1lu3WYslfNYkBSo nFcctFD2KXVozrwpn3vWJ4Qt6qu5XS1lDCD5WshZXh7qoISWnnMqsMyBW/R7WyiABeIz4uOg SkRwT2wSUYr+JtBZIjREy2JQDVhjf18DL1Qa7OxSes8YwWSx1pQAzwbfFx0gzRDyIT/39le4 pX430yTQzsFNBFhri/0BEADFp4ZfxSoKTAad0IkFK9CVoZ6XKywYLFNPPhzw++gbvHL2EX7Q qhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQou0FeSNnzRGb607U8OFOPQ+ei92Mm 1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkhwtWU/6yo+RZs7cFRuihuLl8FuoP0 A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAwGDtjWkBVawpoHWwq58OQSx5piwyO CnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdWJw5OV9BoA7UTHG95xVHV5QiEm6q6 igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8mmKyS8E+mSh3djmqdJNHF1pJqKxA xPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03duzocyU95DfP/lwNJr5SH918Vf1t7 WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkSeXNoMlHJOIqbqm7N414I0HytbENf 7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw3f3Gn3+PDzGEHI9sfQv/mYvO77oR SGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6IfZZ0OIWKLSRa/DQARAQABwsFlBBgB CAAPBQJYa4v9AhsMBQkDwmcAAAoJEM6N1qGlCiHkn54P/AgyzrffYzRq6d7vHfFhd8HzHHrU BtOK+5182DME1JX9Aow5Dy9kbfxAfTc4tbCY5EnhoUICbmVAJ5wL5lrGxQPSnulIyF8OmJjc VlGI6zXYvP0VHZ/L8dPcf+RPqhMCPpaxe2+h5XpPxvOkDLlnCrsA4J1bAGW5kpxdGnY4aRrv aKhtGMqgSwSx25l3RnoOROU/hTDV4EHCuTkMRfILmsuNT7It40iL5nyDiJ8o3p1CLjRwUzVn 4r4jE8DXhbWXaKJ0KQZpKiQDVV7qJcJIeBJvZpFfxJ44LxBct9TkC69ROntYhd6M7031DT3P IYW9VyMhLN5dRfzhEdFUc+3AlnoOOKcGwYiCnH2DwDva3ZicOAH8099mWZcwVL/sjKKbJGPo JbdT9C3gSnsoa3uBbsiChRhAno80Jsk/igb4QaMw4PsS3230kfBGkQ/oAPPM0iJ9kn8NXB/9 iBe5cKEUiiYQfSn9x1HyG0sT3/jSYaq3obmBNHJE24w/RKWoPsaKjoyaInAuU5L0cNZ30OWd eWFREIxlajFl2vXb9nCc80/i6PceJySiyJgd5cYEL4hfn/B6RXph9kAJySsqlIZoBhcwneGX mAS0M41jJjuIQdt5pkLhM9XoXjBFMGGtA/CtiicEgitItJfVCxdLG4bZOCrfPmevMGLxpEmB GouQ9dVQ Organization: CZ.NIC Message-ID: Date: Thu, 26 Jul 2018 08:44:00 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 06:44:08 -0000 I support this & will review DNS parts. Petr Špaček @ CZ.NIC On 25.7.2018 04:16, Joseph Salowey wrote: > > The sense of the TLS@IETF102 room was the the WG should > adopt https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ >  as a WG > item.  But, we need to confirm this on list.  If you would like for this > draft to become a WG document and you are willing to review it as it > moves through the process, then please let the list know by 2359UTC > 20180807.  If you are opposed to this being a WG document, please say so > (and say why). > > Note that the draft has been marked as a "Candidate for WG Adoption” in > the datatracker. From nobody Thu Jul 26 09:22:13 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83C2D1311E6 for ; Thu, 26 Jul 2018 09:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mz_tSaSFq-jr for ; Thu, 26 Jul 2018 09:22:09 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30D0131129 for ; Thu, 26 Jul 2018 09:22:08 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id e19-v6so2123836qtp.8 for ; Thu, 26 Jul 2018 09:22:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=4qpksDxbEAgpi7qCzJbQh0HpJfqEUuM7orDaRMyv0o4=; b=e+M5wYm0JpnvupKI2ypKM08HTPwBo0UCNPac+7BhxHsF2arBM/g22DcMhEjnwFOKdp zMuxAeePVogPvsZzlzt4UtTHMLOCSGh4SueKKXli9feMMM1gGIYdR8gZ1HrHMUscSO6O D9Z1Le4sTr2R3P1TzCdUwfBAceiOeFmgvpVVkJqMw1i+59WNawitw0x7Nqz2MhnjjPnN 1C6jNpU+ZUgQQTHydxb4cMqw/niszFpG8PAoc2hZZTgGrmNe++QxLwYalGa+QkQokbqm g+B2YKoSIl5lBIy1gWXf9+Nx4RtFGqDDtV12fRqIA2Ihl/tVlMgJIPoUvPQZc4hygz1p hmLA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=4qpksDxbEAgpi7qCzJbQh0HpJfqEUuM7orDaRMyv0o4=; b=A2/6L5bLDwGD+RKt3C3PTQAizSxKwQjvZAgj2NYkCgKuser1FZc8w7TIcpHKFNnWxv UL4Zc/De4G9LmplXbUB8QCaQVg4hhVH6R6eUfSbfn0JB+NRqJRucqNNyO6PPaAE0wvCa mfH/pVk1FNP/bK/+mqd0TPmXe3owAaiG45oBvlriFgyXwETHJ5Io/xZX4sJnSrRmMxdn vDY5AJsRLFaI5sd0NrZnkilPiDvf0tjte2IUJ9lGZz+BB3y30sRRCho+16eutlEDK5ay JrITKOVsH7OMP4xGGt06FD0qcpSdCImmdm6doclfZG91ESFgjWzSJjTqqsoQTS29NKQV Nsrw== X-Gm-Message-State: AOUpUlFpdkWJp3kw4RqTWcX7QmDBJe7ev79k9ri3dMke/7c2Sn9L8S/V O/wLOZCLKWsmZ7Yy1P4J5zg= X-Google-Smtp-Source: AAOMgpe8FEMxULR7t1vSNor+lJhMsiDvvbL+V4Hm1vSWBURVeSe2ELyNQxtJ9euD3L8rciw0YsO8gA== X-Received: by 2002:ac8:1834:: with SMTP id q49-v6mr2574908qtj.223.1532622128021; Thu, 26 Jul 2018 09:22:08 -0700 (PDT) Received: from [192.168.0.101] (pool-71-241-128-60.burl.east.myfairpoint.net. [71.241.128.60]) by smtp.gmail.com with ESMTPSA id g39-v6sm1236587qtb.47.2018.07.26.09.22.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Jul 2018 09:22:07 -0700 (PDT) From: Karthikeyan Bhargavan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C7702972-9C40-45D4-AE03-D4CB302ED930" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Thu, 26 Jul 2018 12:21:59 -0400 In-Reply-To: Cc: Nikos Mavrogiannopoulos , "" , Benjamin Kaduk To: Eric Rescorla References: <20180719230009.GD14551@akamai.com> <86b69d7d0534d7c711d13182c18774cf484e6431.camel@redhat.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 16:22:13 -0000 --Apple-Mail=_C7702972-9C40-45D4-AE03-D4CB302ED930 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I can speak a little to how the reuse of keys will affect existing TLS = 1.3 proofs and analyses. First it is worth noting that most TLS 1.3 proofs do not consider hash = function agility, and say nothing about deploying TLS 1.3 in parallel to = TLS 1.2 (with some exceptions like [1], [2]) So, the good news is that these proofs do not care much about how PSKs = or signature keys are used in TLS 1.2. The bad news is that this means that, in general, reusing the same keys = in 1.2 and 1.3 is insecure. Even just within TLS 1.3, if we use the same PSK with two versions of = HKDF that use different hash algorithms, we would need a strong = =E2=80=9Cjoint=E2=80=9D assumption on both these hash functions. Assuming that the HKDF hash algorithm is fixed (either by the standard = or for each key), we can then use the Universal PSK trick to specialize = the PSK for other parameters (such as hash algorithm used for the TLS = transcript). But from what I understand the HKDF hash algorithm is itself determined = by the cipher suite hash algorithm, so I need to think whether the = specialisation provides any formal guarantees. Secondly, TLS 1.3 analyses that account for downgrade attack (like = [1],[2]) show that the downgrade countermeasures in TLS 1.3 are = sufficient to protect TLS 1.3 sessions, but only under some conditions. In particular, [2] shows that it is only safe for an endpoint to reuse = keys between TLS 1.2 and TLS 1.3 if (1) even in TLS 1.2, the endpoint only supports PSK-based or = signature-based ciphersuites (i.e. no RSA encryption) (2) even in TLS 1.2, the endpoint only supports =E2=80=9Cstrong=E2=80=9D = hash functions=20 (3) in TLS 1.2 and 1.3, all the hash functions used within signatures = and MACs are *jointly* collision resistant (i.e. you cannot easily find = b such that H2(b) =3D=3D H1(a), for different supported hash functions = H1 and H2) In summary, the security proofs for TLS 1.3 require fairly strong = conditions on what modes and algorithms of TLS 1.2 can be safely = supported by the same client/server. It is probably worth writing these down as security considerations, and = we can quickly discuss this with the academics who did the various = proofs. -Karthik [1] Downgrade Resilience in Key-Exchange Protocols (IEEE S&P 2016) = https://eprint.iacr.org/2016/072 [2] Verified Models and Reference Implementations for the TLS 1.3 = Standard Candidate (IEEE S&P 2017) https://hal.inria.fr/hal-01528752v2/ > On 20 juil. 2018, at 08:08, Eric Rescorla wrote: >=20 > Karthik --Apple-Mail=_C7702972-9C40-45D4-AE03-D4CB302ED930 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I = can speak a little to how the reuse of keys will affect existing TLS 1.3 = proofs and analyses.

First it is worth = noting that most TLS 1.3 proofs do not consider hash function agility, = and say nothing about deploying TLS 1.3 in parallel to TLS 1.2 (with = some exceptions like [1], [2])
So, the good news is that = these proofs do not care much about how PSKs or signature keys are used = in TLS 1.2.
The bad news is that this means that, in = general, reusing the same keys in 1.2 and 1.3 is insecure.
Even just within TLS 1.3, if we use the same PSK with two = versions of HKDF that use different hash algorithms, we would need a = strong =E2=80=9Cjoint=E2=80=9D assumption on both these hash = functions.
Assuming that the HKDF hash algorithm is fixed = (either by the standard or for each key), we can then use the Universal = PSK trick to specialize the PSK for other parameters (such as hash = algorithm used for the TLS transcript).
But from what I = understand the HKDF hash algorithm is itself determined by the cipher = suite hash algorithm, so I need to think whether the specialisation = provides any formal guarantees.

Secondly, = TLS 1.3 analyses that account for downgrade attack (like [1],[2]) show = that the downgrade countermeasures in TLS 1.3 are sufficient to protect = TLS 1.3 sessions, but only under some conditions.
In = particular, [2] shows that it is only safe for an endpoint to reuse keys = between TLS 1.2 and TLS 1.3 if
(1) even in TLS 1.2, the = endpoint only supports PSK-based or signature-based ciphersuites (i.e. = no RSA encryption)
(2) even in TLS 1.2, the endpoint only = supports =E2=80=9Cstrong=E2=80=9D hash functions 
(3) = in TLS 1.2 and 1.3, all the hash functions used within signatures and = MACs are *jointly* collision resistant (i.e. you cannot easily find b = such that H2(b) =3D=3D H1(a), for different supported hash functions H1 = and H2)

In summary, the security proofs for = TLS 1.3 require fairly strong conditions on what modes and algorithms of = TLS 1.2 can be safely supported by the same client/server.
It is probably worth writing these down as security = considerations, and we can quickly discuss this with the academics who = did the various proofs.

-Karthik

[1] Downgrade Resilience in = Key-Exchange Protocols (IEEE S&P 2016) https://eprint.iacr.org/2016/072
[2] = Verified Models and Reference Implementations for the TLS 1.3 Standard = Candidate (IEEE S&P 2017)  https://hal.inria.fr/hal-01528752v2/


On 20 juil. 2018, at 08:08, Eric Rescorla = <ekr@rtfm.com> = wrote:

Karthik

= --Apple-Mail=_C7702972-9C40-45D4-AE03-D4CB302ED930-- From nobody Thu Jul 26 10:20:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E314C131225 for ; Thu, 26 Jul 2018 10:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.72 X-Spam-Level: X-Spam-Status: No, score=-0.72 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, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IWGf4QuaDGrD for ; Thu, 26 Jul 2018 10:20:39 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F33DF131223 for ; Thu, 26 Jul 2018 10:20:38 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6QHCAMH011548 for ; Thu, 26 Jul 2018 18:20:38 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=xltW2AYu4+bZn3+LuevXIEuFEqQoKjO579SWajjhZTU=; b=Ljt5yCM01XS0UN7Q9DfyfyaqZ+/1seBhXuSK77G8RHMrIxeWKFVPzh1YFcAGGE0q67H/ n9s9JkY3a6m77wpB8B6j4NsObL8/IJ5Uf1YXBZLDBNeI53/br5gmaJe6R9C/xo+z6813 LPZp2/kWbFZPdaT4KS6OOVg6xysmArEjjXQvfh4npUCuH8SLhU/12IdyA0kBZYoDoYih tlwi+05Q5e/UNlLJXX6gbUOPGiMQvJ+637z1yrHiHXfdt63wORVSN2HbBNskf9RntyT2 Gff237DRLkfyBDLu8fC5gE/+hZnTm3JBwsA2YoNSbxFyUHztB5KEMgouAeOV/acliovx Kw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0b-00190b01.pphosted.com with ESMTP id 2kfhuq84fh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 26 Jul 2018 18:20:37 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6QHJYUJ010009 for ; Thu, 26 Jul 2018 13:20:37 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2kc05ve8w9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Thu, 26 Jul 2018 13:20:36 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 26 Jul 2018 13:20:36 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1365.000; Thu, 26 Jul 2018 13:20:36 -0400 From: "Short, Todd" To: "" Thread-Topic: [TLS] WG adoption call: draft-rescorla-tls-esni Thread-Index: AQHUI723kG6HnNyqdUeGwvNH86VA9aShwnKA Date: Thu, 26 Jul 2018 17:20:35 +0000 Message-ID: <8982EE96-1AAD-4603-87BE-AA0DDCBD738C@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.53] Content-Type: multipart/alternative; boundary="_000_8982EE961AAD460387BEAA0DDCBD738Cakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-26_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807260178 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-26_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=975 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807260177 Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 17:20:41 -0000 --_000_8982EE961AAD460387BEAA0DDCBD738Cakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IFdHIGFkb3B0aW9uLg0KDQotLQ0KLVRvZGQgU2hvcnQNCi8vIHRzaG9ydEBha2Ft YWkuY29tDQovLyAiT25lIGlmIGJ5IGxhbmQsIHR3byBpZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRo ZSBJbnRlcm5ldC4iDQoNCg0KRnJvbTogSm9zZXBoIFNhbG93ZXkgPGpvZUBzYWxvd2V5Lm5ldD4N CkRhdGU6IFR1ZXNkYXksIEp1bHkgMjQsIDIwMTggYXQgMTA6MTggUE0NClRvOiAiPHRsc0BpZXRm Lm9yZz4iIDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVExTXSBXRyBhZG9wdGlvbiBjYWxsOiBk cmFmdC1yZXNjb3JsYS10bHMtZXNuaQ0KDQoNClRoZSBzZW5zZSBvZiB0aGUgVExTQElFVEYxMDIg cm9vbSB3YXMgdGhlIHRoZSBXRyBzaG91bGQgYWRvcHQgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtcmVzY29ybGEtdGxzLWVzbmkvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2Ry YWZ0LTJEcmVzY29ybGEtMkR0bHMtMkRlc25pXyZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpw TjZMWmcmcj1RQkVjUXNxb1VEZGsxUTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210UmlrJm09SC1x QmNxR0RUcEpPa1RpTjRwUDRMTVNoUFJMd2E2SWhwVDZWaGRrV3pIQSZzPTFYN2xKdjFaRDFFNW8t aERnOW9mWnFlcUF4VXJXRXJ1Sk5rVGx4bjhTZkEmZT0+IGFzIGEgV0cgaXRlbS4gIEJ1dCwgd2Ug bmVlZCB0byBjb25maXJtIHRoaXMgb24gbGlzdC4gIElmIHlvdSB3b3VsZCBsaWtlIGZvciB0aGlz IGRyYWZ0IHRvIGJlY29tZSBhIFdHIGRvY3VtZW50IGFuZCB5b3UgYXJlIHdpbGxpbmcgdG8gcmV2 aWV3IGl0IGFzIGl0IG1vdmVzIHRocm91Z2ggdGhlIHByb2Nlc3MsIHRoZW4gcGxlYXNlIGxldCB0 aGUgbGlzdCBrbm93IGJ5IDIzNTlVVEMgMjAxODA4MDcuICBJZiB5b3UgYXJlIG9wcG9zZWQgdG8g dGhpcyBiZWluZyBhIFdHIGRvY3VtZW50LCBwbGVhc2Ugc2F5IHNvIChhbmQgc2F5IHdoeSkuDQoN Ck5vdGUgdGhhdCB0aGUgZHJhZnQgaGFzIGJlZW4gbWFya2VkIGFzIGEgIkNhbmRpZGF0ZSBmb3Ig V0cgQWRvcHRpb27igJ0gaW4gdGhlIGRhdGF0cmFja2VyLg0KDQoNCg0KDQo= --_000_8982EE961AAD460387BEAA0DDCBD738Cakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <136E568B1EB52F48B5A71D38B90E5A37@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkkgc3VwcG9ydCBXRyBhZG9wdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+LS08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWYiPi1Ub2RkIFNob3J0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7LHNlcmlmIj4v LyB0c2hvcnRAYWthbWFpLmNvbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyxzZXJpZiI+Ly8gJnF1b3Q7T25lIGlmIGJ5IGxhbmQsIHR3byBp ZiBieSBzZWEsIHRocmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4mcXVvdDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206 DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5K b3NlcGggU2Fsb3dleSAmbHQ7am9lQHNhbG93ZXkubmV0Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5U dWVzZGF5LCBKdWx5IDI0LCAyMDE4IGF0IDEwOjE4IFBNPGJyPg0KPGI+VG86IDwvYj4mcXVvdDsm bHQ7dGxzQGlldGYub3JnJmd0OyZxdW90OyAmbHQ7dGxzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5bVExTXSBXRyBhZG9wdGlvbiBjYWxsOiBkcmFmdC1yZXNjb3JsYS10bHMtZXNu aTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij48YnI+DQpUaGUgc2Vuc2Ugb2YgdGhlIFRMU0BJ RVRGMTAyIHJvb20gd2FzIHRoZSB0aGUgV0cgc2hvdWxkIGFkb3B0Jm5ic3A7PC9zcGFuPjxhIGhy ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f ZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEcmVzY29ybGEtMkR0bHMtMkRlc25pXyZh bXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1RQkVjUXNxb1VE ZGsxUTI2Q3psek5QUFVrS1lXSWgxTFlzaUhBd210UmlrJmFtcDttPUgtcUJjcUdEVHBKT2tUaU40 cFA0TE1TaFBSTHdhNklocFQ2Vmhka1d6SEEmYW1wO3M9MVg3bEp2MVpEMUU1by1oRGc5b2ZacWVx QXhVcldFcnVKTmtUbHhuOFNmQSZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuNXB0O2NvbG9yOiMxMTU1Q0MiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LXJlc2NvcmxhLXRscy1lc25pLzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo5LjVwdCI+Jm5ic3A7YXMNCiBhIFdHIGl0ZW0uJm5ic3A7IEJ1dCwgd2UgbmVlZCB0 byBjb25maXJtIHRoaXMgb24gbGlzdC4mbmJzcDsgSWYgeW91IHdvdWxkIGxpa2UgZm9yIHRoaXMg ZHJhZnQgdG8gYmVjb21lIGEgV0cgZG9jdW1lbnQgYW5kIHlvdSBhcmUgd2lsbGluZyB0byByZXZp ZXcgaXQgYXMgaXQgbW92ZXMgdGhyb3VnaCB0aGUgcHJvY2VzcywgdGhlbiBwbGVhc2UgbGV0IHRo ZSBsaXN0IGtub3cgYnkgMjM1OVVUQyAyMDE4MDgwNy4mbmJzcDsgSWYgeW91IGFyZSBvcHBvc2Vk IHRvIHRoaXMgYmVpbmcNCiBhIFdHIGRvY3VtZW50LCBwbGVhc2Ugc2F5IHNvIChhbmQgc2F5IHdo eSkuPGJyPg0KPGJyPg0KTm90ZSB0aGF0IHRoZSBkcmFmdCBoYXMgYmVlbiBtYXJrZWQgYXMgYSAm cXVvdDtDYW5kaWRhdGUgZm9yIFdHIEFkb3B0aW9u4oCdIGluIHRoZSBkYXRhdHJhY2tlci48L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS41cHQiPjxicj4NCjxicj4N Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0 Ij48YnI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_8982EE961AAD460387BEAA0DDCBD738Cakamaicom_-- From nobody Thu Jul 26 10:23:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8F32130E20 for ; Thu, 26 Jul 2018 10:23:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FpbAHFHSOb6o for ; Thu, 26 Jul 2018 10:23:32 -0700 (PDT) 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 64CF3126BED for ; Thu, 26 Jul 2018 10:23:32 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id q19-v6so1970317ioh.11 for ; Thu, 26 Jul 2018 10:23:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Es4x8FIUygjiP093JXcmv4bIT3kMnwnQ9rygn6d4cN4=; b=Htngl4coL12YRPCxiFIGPZu6aUhzsERZ3RUK1ty6PNu7vWFvIho6O6rKngse2TJnFl qvKTIrcz2KJjx4dlQnOFLShLN7SCMYYVe/h6Cl5SIGo0vS/jRXEiMNP++m6JjKGRbHtT E9X3J818CqHeNizW1yYGMCT2qMpLpOIhm58rHqPGC0T403V/jt9S6GgPBVmFZ3obLJ+3 BjDWSdodiwtftBCrLayvJaf293C1iLlzpg7BXzvhpBW51XLIaDXixH/BKn85jC8YHyG7 gpkb6yF4yyobyO38JjXk3qeHRokJChrPtP57V+KvEVr06ZRq9543Rkg5fR9SdkWlXyEN cTlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Es4x8FIUygjiP093JXcmv4bIT3kMnwnQ9rygn6d4cN4=; b=BA/Xm/yocZSPLsrEpYbBgdJYCjAu2IHmwzudJOXwGfpUytMXDlu5DEBpxJp86/0qt6 UuU9ldbjEpQuk10lrwJ6NWK66KYcfNQNbs35nFz5CzzuRbOMviFYz+f5bDyAlZ+Zmp9j vcpJ1hLB5siR/WhOj2bumWaTM2uBR18vXL1keVRWKLBinS5OdvZ+am7bBWn/8zs6jJyu zTXUwjTPKgjeaCGyqhTUWPmPbtI9FNulEFFCbkAl7s+TQ3CVh5aiQ67omLgwUB6Q7nyn mDN9E/EO+cyKtr0hb60CT4t1W+i31CqrZenWVDdjR6iDcGPF2l+YeshipXi/yiRBRD+x +Vnw== X-Gm-Message-State: AOUpUlGeYFz3zxFd3077KDpomt3tzRA9Fw8yy8md8vBFF73yfybHZzb4 l3842gJrvJPMDRX/Vm0/FpLJuQmbewFldiR2tbU= X-Google-Smtp-Source: AAOMgpcnWu1KL8k+56Ed3btXWFTZsy4yKlTwX/1Q6dnikEWDNDAP8zFc9kB9//Uwhw9EDrVI+v8sJIBffSB8pzFet2E= X-Received: by 2002:a6b:310d:: with SMTP id j13-v6mr2449469ioa.250.1532625811789; Thu, 26 Jul 2018 10:23:31 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:6985:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 10:23:31 -0700 (PDT) In-Reply-To: <8982EE96-1AAD-4603-87BE-AA0DDCBD738C@akamai.com> References: <8982EE96-1AAD-4603-87BE-AA0DDCBD738C@akamai.com> From: Loganaden Velvindron Date: Thu, 26 Jul 2018 21:23:31 +0400 Message-ID: To: "Short, Todd" Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 17:23:35 -0000 I support the adoption as well. On Thu, Jul 26, 2018 at 9:20 PM, Short, Todd wrote: > I support WG adoption. > > > > -- > > -Todd Short > > // tshort@akamai.com > > // "One if by land, two if by sea, three if by the Internet." > > > > > > From: Joseph Salowey > Date: Tuesday, July 24, 2018 at 10:18 PM > To: "" > Subject: [TLS] WG adoption call: draft-rescorla-tls-esni > > > > > The sense of the TLS@IETF102 room was the the WG should adopt > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. > But, we need to confirm this on list. If you would like for this draft t= o > become a WG document and you are willing to review it as it moves through > the process, then please let the list know by 2359UTC 20180807. If you a= re > opposed to this being a WG document, please say so (and say why). > > Note that the draft has been marked as a "Candidate for WG Adoption=E2=80= =9D in the > datatracker. > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Thu Jul 26 10:58:52 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8446B130E83 for ; Thu, 26 Jul 2018 10:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3r2MsAf8_T4 for ; Thu, 26 Jul 2018 10:58:48 -0700 (PDT) Received: from mail-lj1-x231.google.com (mail-lj1-x231.google.com [IPv6:2a00:1450:4864:20::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 7D117124D68 for ; Thu, 26 Jul 2018 10:58:47 -0700 (PDT) Received: by mail-lj1-x231.google.com with SMTP id p6-v6so2246965ljc.5 for ; Thu, 26 Jul 2018 10:58:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/bWKJKIl0g2HCijCi/SRXWupOwITDycujDqVv1iiKqI=; b=jGbVELmFRpVota9FUGfQuJxR15ElOPsHEW+wj3jSIHQjyC7+q4lZ6hWsvyMX4pnC1N osl/T6iNMtuS3j4rgsXorFE8DgGbDghJ3tEwWgdqvHZtuEKOZzuWIcd6xtsN07V8cH6z jjCqJRyQIA9MSX31Te/gvnQ76Od28UJ3Ws8o4MxvwtKiN0QEbQm7Gu4ZLRgQ/jeGMDGf R0iLdUuJmvNIT2M3dAXjF26cTfhCgJsgQ4x9wKOG2yf0lepEr3xS/pj1hCKKQuosODGe tIpPHAP/Pjsa67P1tV9+4DH+0iwLbiOLliEDmOaXHGQm0QjklG1Eab8eXseR9WzY53Sr x0Lg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/bWKJKIl0g2HCijCi/SRXWupOwITDycujDqVv1iiKqI=; b=axBXOzBN5P5FKHFo5TYghnfExlIpSLvjaBuZhz83ChetlzXrN/uW22MXsMLiHcg6pc TeWOMaGyBHhOEQrca6luX/B2/8EIegaKj4YKQ+IC7kCRK9rTfNK+7MUyD/7QJvVGYE+N iqQvQMrfmrIg6D8ylC8zy91kPsutV7KHTF+n43UgnKIri07mX2PwAOrZwsRS3aA3SPdP FAvKj4K2FZKR+N8IACNu1tCGScxjXdIkUBW/UdD5JGyLofOO87dlrg/4H1KYlifJsGVr 8sXBeZH/bET9q5gamnm1uVK80QBsIRDWDqsr9UsDhHXE4IOUrH3Pe/xivi2d1Rlrc+EE bNzQ== X-Gm-Message-State: AOUpUlFbQ/gdueA4ywTZ+5tVLD/B1AjC3sVPYB60PDn5KRoy5yw3jfOD UBrfPDy582Phbu/8u4aldrBFK0Igq0umR3V5bGbCwOaw X-Google-Smtp-Source: AAOMgpfwrzeRBwFTnhZTTVvQN7Ly4BBgcTap7NVVZ6TRFoUE1J47X+lz/Adnh69+QE+mYwbUa8g6JXax5D6t8g/ZHPE= X-Received: by 2002:a2e:7014:: with SMTP id l20-v6mr2535297ljc.141.1532627925799; Thu, 26 Jul 2018 10:58:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 10:58:05 -0700 (PDT) In-Reply-To: <20180719230009.GD14551@akamai.com> References: <20180719230009.GD14551@akamai.com> From: Eric Rescorla Date: Thu, 26 Jul 2018 10:58:05 -0700 Message-ID: To: Benjamin Kaduk Cc: "" Content-Type: multipart/alternative; boundary="00000000000017267c0571eabf2c" Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 17:58:50 -0000 --00000000000017267c0571eabf2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ben, Thanks for focusing on this issue. Chris and I have been discussing an alternative design which we think is more consistent with the existing structure, which we call PSK Importers. As with your design, we have an input universal PSK, but instead of using explicitly as part of the connection, we just use it as the base key to import a set of new PSKs into TLS. As with Universal PSKs (UPSKs), each input key is a triplet of (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity as used today. To use a UPSK, an implementation takes the set of KDF hashes it knows about H_i and derives a set of PSKs: Hash_i: H_i Identity_i: BaseIdentity || H_i Key_i: Derived from BaseKey and Identity_i This gives you a set of keys which you can offer simultaneously on the TLS connection in independent psk_identity blocks. (Note that the hash algorithm is what differentiates each derived key.) This is a bit ugly, but with the current TLS 1.3 ciphers, this basically just means SHA-256, but even in the worst case it=E2=80=99s probably only 2-3. The nice thing about this design is that if you know the set of hash functions, you can just compute all the imported PSKs in advance, and there=E2=80=99s no need to touch the internals of the TLS stack. This also means that if you have decided you don=E2=80=99t like old hash X, you don= =E2=80=99t need to use it to compute PSK binders, you just use it do the KDF, which seems like it has weakersecurity requirements. Here=E2=80=99s a specific construction, but we=E2=80=99re flexible about th= e details: struct { opaque base_identity<1...2^16-1>; HashAlgorithm hash; } imported_psk_identity; UPSKx =3D HKDF-Extract(0, UPSK) // UPSK is the input universal PSK PSK =3D HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity), TargetHash.length) // Might need to shorten label These functions would be executed with the KDF associated with the UPSK, but produce a key the size of the desired hash. This brings us to the question of TLS 1.2. I found Ilari=E2=80=99s analyis pretty persuasive, so I would suggest we add the following text to the TLS 1.3 spec: TLS 1.3 takes a conservative approach to PSKs by binding them to a specific KDF. TLS 1.2 allows PSKs to be used with any hash function and the TLS 1.2 PRF. The constructions in TLS 1.2 and TLS 1.3, although both based on HMAC, are very different and there is no known way in which reuse of the same PSK in TLS 1.3 and TLS 1.2 would produce related output, although only limited formal analysis has been done. Implementations MAY wish to avoid reuse of keys between TLS 1.3 and TLS 1.2, or use a key derivation proposal such as [Informative ref to this email or a draft]. Other than this, we wouldn=E2=80=99t make any changes to the document. What do people think? -Ekr On Thu, Jul 19, 2018 at 4:00 PM, Benjamin Kaduk wrote: > Hi all, > > As I mentioned at the mic today, there is a question that has been > raised about whether it's wise to reuse an existing (TLS 1.2) PSK > directly in the TLS 1.3 key ladder. At a high level, the reason why one > might want to restrict this is that the security proofs for TLS 1.3 rely > on the pre-shared key being only used with a single key-derivation > function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different > key-derivation function, so formally the proofs do not hold. We don't > currently know of a specifc attack against such reuse, of course, but > perhaps it is prudent to restrict our usage to adhere to the verified > scenarios. > > This is somewhat timely, as if we do want to introduce a restriction, it > would ideally be in the form of some text in the TLS 1.3 specification, > which is very nearly done. > > It would be good to hear more opinions on this question, particularly > from those who have worked on the formal verification directly. > > If I can attempt to summarize some discussion that occurred in the mic > line today, Hannes was surprised that we would care, likening this case > to the regular version negotiation, where we are happy to use the same > certificate to sign messages for both TLS 1.2 and 1.3. David Benjamin > points out that we explicitly go to the trouble of putting 64 bytes of > 0x20 padding at the front of the content that gets signed for > CertificateVerify, to enforce separation between the TLS versions. > > My own personal opinion is that we should enforce a domain separation > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal PSKs" > proposal seems like a potential mechanism by which to do so without > doubling the provisioning needs. > > -Ben (with no hat) > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000017267c0571eabf2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ben,

Thanks for focusing on this issue.

Chr= is and I have been discussing an alternative design which we think
is mo= re consistent with the existing structure, which we call PSK
Importers. = As with your design, we have an input universal PSK, but
instead of usin= g explicitly as part of the connection, we just use it
as the base key t= o import a set of new PSKs into TLS.

As with Universal PSKs (UPSKs),= each input key is a triplet of
(BaseIdentity, BaseKey, KDF), where a Ba= seIdentity is a PSK identity
as used today. To use a UPSK, an implementa= tion takes the set of KDF
hashes it knows about H_i and derives a set of= PSKs:

=C2=A0 Hash_i: H_i
=C2=A0 Identity_i: BaseIdentity || H_i<= br>=C2=A0 Key_i: Derived from BaseKey and Identity_i

This gives you = a set of keys which you can offer simultaneously on the
TLS connection i= n independent psk_identity blocks. (Note that the hash
algorithm is what= differentiates each derived key.) This is a bit
ugly, but with the curr= ent TLS 1.3 ciphers, this basically just means
SHA-256, but even in the = worst case it=E2=80=99s probably only 2-3.

The nice thing about this= design is that if you know the set of hash
functions, you can just comp= ute all the imported PSKs in advance, and
there=E2=80=99s no need to tou= ch the internals of the TLS stack. This also
means that if you have deci= ded you don=E2=80=99t like old hash X, you don=E2=80=99t
need to use it = to compute PSK binders, you just use it do the KDF,
which seems like it = has weakersecurity requirements.

Here=E2=80=99s a specific construc= tion, but we=E2=80=99re flexible about the details:

=C2=A0=C2=A0 str= uct {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque base_identity<1...2= ^16-1>;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HashAlgorithm hash;
= =C2=A0=C2=A0 } imported_psk_identity;

=C2=A0=C2=A0 UPSKx =3D HKDF-Ex= tract(0, UPSK)=C2=A0 // UPSK is the input universal PSK
=C2=A0=C2= =A0 PSK =3D HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_i= dentity), TargetHash.length) // Might need to shorten label

<= /div>
These functions would be executed with the KDF associated with th= e UPSK, but produce
a key the size of the desired hash.
=
This brings us to the question of TLS 1.2. I found Ilari=E2=80=99s anal= yis
pretty persuasive, so I would suggest we add the following text to t= he
TLS 1.3 spec:

=C2=A0=C2=A0=C2=A0 TLS 1.3 takes a conservative = approach to PSKs by binding them to a
=C2=A0=C2=A0=C2=A0 specific KDF. T= LS 1.2 allows PSKs to be used with any hash function
=C2=A0=C2=A0=C2=A0 = and the TLS 1.2 PRF. The constructions in TLS 1.2 and TLS 1.3,
=C2=A0=C2= =A0=C2=A0 although both based on HMAC, are very different and there is no k= nown
=C2=A0=C2=A0=C2=A0 way in which reuse of the same PSK in TLS 1.3 an= d TLS 1.2 would
=C2=A0=C2=A0=C2=A0 produce related output, although only= limited formal analysis has been
=C2=A0=C2=A0=C2=A0 done. Implementatio= ns MAY wish to avoid reuse of keys between TLS 1.3
=C2=A0=C2=A0=C2=A0 an= d TLS 1.2, or use a key derivation proposal such as [Informative ref
=C2= =A0=C2=A0=C2=A0 to this email or a draft].

Other than this, we would= n=E2=80=99t make any changes to the document.

What do people think?<= br>

-Ekr





On Thu, Jul 19, 2018 at 4:00 PM,= Benjamin Kaduk <bkaduk=3D40akamai.com@dmarc.ietf.= org> wrote:
Hi all,

As I mentioned at the mic today, there is a question that has been
raised about whether it's wise to reuse an existing (TLS 1.2) PSK
directly in the TLS 1.3 key ladder.=C2=A0 At a high level, the reason why o= ne
might want to restrict this is that the security proofs for TLS 1.3 rely on the pre-shared key being only used with a single key-derivation
function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different
key-derivation function, so formally the proofs do not hold.=C2=A0 We don&#= 39;t
currently know of a specifc attack against such reuse, of course, but
perhaps it is prudent to restrict our usage to adhere to the verified
scenarios.

This is somewhat timely, as if we do want to introduce a restriction, it would ideally be in the form of some text in the TLS 1.3 specification,
which is very nearly done.

It would be good to hear more opinions on this question, particularly
from those who have worked on the formal verification directly.

If I can attempt to summarize some discussion that occurred in the mic
line today, Hannes was surprised that we would care, likening this case
to the regular version negotiation, where we are happy to use the same
certificate to sign messages for both TLS 1.2 and 1.3.=C2=A0 David Benjamin=
points out that we explicitly go to the trouble of putting 64 bytes of
0x20 padding at the front of the content that gets signed for
CertificateVerify, to enforce separation between the TLS versions.

My own personal opinion is that we should enforce a domain separation
between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal= PSKs"
proposal seems like a potential mechanism by which to do so without
doubling the provisioning needs.

-Ben (with no hat)

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

--00000000000017267c0571eabf2c-- From nobody Thu Jul 26 11:01:28 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75B86130E83 for ; Thu, 26 Jul 2018 11:01:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhhckROr_QkH for ; Thu, 26 Jul 2018 11:01:23 -0700 (PDT) Received: from smtp.ufl.edu (smtp-prod04.osg.ufl.edu [128.227.74.220]) (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 70E4B130E06 for ; Thu, 26 Jul 2018 11:01:22 -0700 (PDT) X-UFL-GatorLink-Authenticated: authenticated as (<>) with from 10.36.133.35 Received: from exmbxprd04.ad.ufl.edu ([10.36.133.35]) by smtp.ufl.edu (8.14.4/8.14.4/3.0.0) with ESMTP id w6QI1Ij2021517 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 26 Jul 2018 14:01:19 -0400 Received: from exmbxprd21.ad.ufl.edu (128.227.145.166) by exmbxprd04.ad.ufl.edu (10.36.133.35) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 26 Jul 2018 14:01:18 -0400 Received: from exmbxprd23.ad.ufl.edu (128.227.145.167) by exmbxprd21.ad.ufl.edu (128.227.145.166) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 26 Jul 2018 14:01:18 -0400 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (207.46.163.53) by exmbxprd23.ad.ufl.edu (128.227.145.167) with Microsoft SMTP Server (TLS) id 15.0.1365.1 via Frontend Transport; Thu, 26 Jul 2018 14:01:18 -0400 Received: from MWHPR22MB0461.namprd22.prod.outlook.com (10.173.55.7) by MWHPR22MB0127.namprd22.prod.outlook.com (10.168.249.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.973.21; Thu, 26 Jul 2018 18:01:15 +0000 Received: from MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::9416:941e:7bdf:c7f]) by MWHPR22MB0461.namprd22.prod.outlook.com ([fe80::9416:941e:7bdf:c7f%7]) with mapi id 15.20.0995.014; Thu, 26 Jul 2018 18:01:15 +0000 From: "Patton,Christopher J" To: "Blumenthal, Uri - 0553 - MITLL" , Ilari Liusvaara CC: "tls@ietf.org" Thread-Topic: [TLS] Proposals for draft-ietf-tls-subcerts-02 Thread-Index: AQHUI4J2izOpwygh4UiboxDIYgPCqaSe0ZmAgAAEZ4CAAvdKBw== Date: Thu, 26 Jul 2018 18:01:15 +0000 Message-ID: References: <20180724202423.GA28235@LK-Perkele-VII>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2606:4700:ff01:8210:e59c:725d:ec6e:3ce1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR22MB0127; 6:n1WfCb1bZezi5kGZkMMtWUmKssKEpo/DlQO532o3V6zROHAIa3Iqan2ZgYcBdhP7uRpHb+N4EIm9CTzrFnBGOoQ3vINgSkFNfIu771rsgllmjcpskWqT42q9n8YA5VRzR3dNV6lv6eu7tcU4iV6P8b5K1zq49tBlZ4qK3nk7WoFRO8VyU4AHZs9pyFDBehiyURKvqOfOXhdYOyYQTa1LEUdTA6BO4z3CkydANALzYgWFtBeLotsMyvZHklF7Ym7qjSuqYiUnAwyR6SCWkYXioEHqqn4Zqbx+hpgTTQ+1WBhn9V2CTzPxQRRo02gXkOdp6Nku7C8PwqhtvlTr84tvvHm11cd8vRZccilvRHyqWHi+s9mAFof76kUJwghOJ0KLT7YFnWAls+GOrwTj8x+Pa8QgzDmBLtnpW2xIJNTI8I3+MJzPScevCOmzARk4pAoyMksqg14mBoKZ6q3+E6i+jg==; 5:HvsNMEtKxUW134soDeJBjXmQSu2TVtFDTNHTsS4Yu+3X57YdJ7lvAcxQ1gpqYzeopS3Np4isd54irRmPEJK37MxYtDdC88jDROuMEbxNsTHaLJXJim0QIvh5wIavwBYcztvAzIk77n1ceSqN3r4WtSP7HMVMlzEWjmaXURIEIaM=; 7:EKU6XtsCPctYkpcUt6OLKs2LxjxMUJHRdxM6hMuhw1zpiVB9XWm50HpwReG5Sqp1aQnQ/kJNPqrdN7Qn4SgUruxqyuT77tMjP468SpwAu4BPqzieEfcAyRfJqSff4bZ3OAhvSLyeeuu0ptXg1zm0JJAd8Y0qQqC0ETsbYw/+yreZLBgL3gbbnPHmRmBuF0ZBDHRHuvN5bbuDwA/JMHHhPThebo5B9qf1ek+tTUKkD57Sg//IKk71VVlF7kR4FQ/S x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a48899dc-9aa8-4133-59ab-08d5f321c7c7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(4627221)(201703031133081)(201702281549075)(8990107)(5600073)(711020)(2017052603328)(7153060)(7193020); SRVR:MWHPR22MB0127; x-ms-traffictypediagnostic: MWHPR22MB0127: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(240460790083961); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(3002001)(149027)(150027)(6041310)(201703131423095)(201702281529075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011)(7699016); SRVR:MWHPR22MB0127; BCL:0; PCL:0; RULEID:; SRVR:MWHPR22MB0127; x-forefront-prvs: 07459438AA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(396003)(136003)(366004)(189003)(199004)(53754006)(966005)(5250100002)(4326008)(2900100001)(606006)(75432002)(6306002)(105586002)(25786009)(236005)(110136005)(53936002)(97736004)(81156014)(14971765001)(561944003)(2171002)(99286004)(14454004)(6246003)(478600001)(229853002)(106356001)(186003)(256004)(33656002)(53546011)(5660300001)(11346002)(6606003)(46003)(446003)(786003)(316002)(6436002)(102836004)(7736002)(2906002)(88552002)(486006)(8936002)(7696005)(74316002)(86362001)(54896002)(19627405001)(8676002)(55016002)(9686003)(81166006)(6116002)(68736007)(6506007)(476003)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR22MB0127; H:MWHPR22MB0461.namprd22.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ufl.edu does not designate permitted sender hosts) x-microsoft-antispam-message-info: Appd8KKAIxmRsImN8apsXwkGbDARktMfV4fFbxfAbwFnS3uSEU7N6j7XLW8akNdw7Kp7+jOQ5B4BvRhfibFEVqNFXuBuX+h+ud6+fgkHU+Pv/4Fn7Vao5jyaEbgJEqChgXQBiTk3b8NqWDa3PckVqjHud+G1rZUR3NNtigYbhaq/Fs5s8ecP4w/NCo2BebDdQiOz22i2pWFH1k9dUo9ZHRaFg6gC/0CIFj+zZvS4BhZV2MiYezfNZ5HBMtCpcAFO3Dh60Ule7X3SheWPqyWDc2RhClok5vFtxL9vGds+RB76T60t7h1AB9/u/b2LK9wVYD+8uQTJvLCTcLcCDQqp38l1R9SNFJ79d7RADqehuFI= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR22MB0461FC1102E9F077185AD97FC62B0MWHPR22MB0461namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a48899dc-9aa8-4133-59ab-08d5f321c7c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jul 2018 18:01:15.1221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0d4da0f8-4a31-4d76-ace6-0a62331e1b84 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR22MB0127 X-OriginatorOrg: ufl.edu X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-26_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807260185 X-UFL-Spam-Level: * Archived-At: Subject: Re: [TLS] Proposals for draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 18:01:27 -0000 --_000_MWHPR22MB0461FC1102E9F077185AD97FC62B0MWHPR22MB0461namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGFsbCBmb3IgdGhlIGZlZWRiYWNrISBJbiBsaWdodCBvZiB5b3VyIG9ic2VydmF0aW9u cywgd2UndmUgcmV2aXNlZCB0aGUgY2hhbmdlcyBwcm9wb3NlZCBmb3IgZHJhZnQtMDI6IGh0dHBz Oi8vZ2l0aHViLmNvbS90bHN3Zy90bHMtc3ViY2VydHMvcHVsbC8xMy4NCg0KDQpUaGUgY2hhbmdl cyBmb3IgZHJhZnQtMDIgYXJlIGFzIGZvbGxvd3M6DQoNCiAgKiAgIERyb3Agc3VwcG9ydCBmb3Ig VExTIDEuMi4NCiAgKiAgIEFkZCB0aGUgcHJvdG9jb2wgdmVyc2lvbiBhbmQgY3JlZGVudGlhbCBz aWduYXR1cmUgYWxnb3JpdGhtIHRvIHRoZSBDcmVkZW50aWFsIHN0cnVjdHVyZS4NCiAgKiAgIFNw ZWNpZnkgdW5kZWZpbmVkIGJlaGF2aW9yIGluIGEgZmV3IGNhc2VzOiB3aGVuIHRoZSBjbGllbnQg cmVjZWl2ZXMgYSBEQyB3aXRob3V0IGluZGljYXRlZCBzdXBwb3J0OyB3aGVuIHRoZSBjbGllbnQg aW5kaWNhdGVzIHRoZSBleHRlbnNpb24gaW4gYW4gaW52YWxpZCBwcm90b2NvbCB2ZXJzaW9uOyBh bmQgd2hlbiBEQ3MgYXJlIHNlbnQgYXMgZXh0ZW5zaW9ucyB0byBjZXJ0aWZpY2F0ZXMgb3RoZXIg dGhhbiB0aGUgZW5kLWVudGl0eSBjZXJ0aWZpY2F0ZS4NCg0KDQpBbnkgYWRkaXRpb25hbCBmZWVk YmFjayBpcyB3ZWxjb21lLg0KDQoNClRoYW5rcywNCg0KQ2hyaXN0b3BoZXIgUGF0dG9uDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkZyb206IEJsdW1lbnRoYWwsIFVyaSAt IDA1NTMgLSBNSVRMTCA8dXJpQGxsLm1pdC5lZHU+DQpTZW50OiBUdWVzZGF5LCBKdWx5IDI0LCAy MDE4IDQ6NDAgUE0NClRvOiBJbGFyaSBMaXVzdmFhcmE7IFBhdHRvbixDaHJpc3RvcGhlciBKDQpD YzogdGxzQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW1RMU10gUHJvcG9zYWxzIGZvciBkcmFmdC1p ZXRmLXRscy1zdWJjZXJ0cy0wMg0KDQpJIG9iamVjdCB0byByZS1pbnRlcnByZXRpbmcvb3Zlcmxv YWRpbmcgdGhlIENyaXRpY2FsIGZsYWcuIEl0IGhhcyBvbmUgYW5kIG9ubHkgb25lIG1lYW5pbmc6 ICJJZiB0aGUgcGFyc2VyIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIGdpdmVuIGF0dHJpYnV0ZSwg aXQgbXVzdCBhYm9ydCBwYXJzaW5nIGlmIHRoaXMgYXR0cmlidXRlIGlzIG1hcmtlZCBhcyBDcml0 aWNhbCAob3IgaWdub3JlIHRoaXMgYXR0cmlidXRlIGFuZCBjb250aW51ZSBwYXJzaW5nIGlmIHRo ZSBDcml0aWNhbCBmbGFnIGlzIG5vdCBzZXQpIi4NCg0KDQrvu79PbiA3LzI0LzE4LCAxNjoyNSwg IlRMUyBvbiBiZWhhbGYgb2YgSWxhcmkgTGl1c3ZhYXJhIiA8dGxzLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbT4gd3JvdGU6DQoNCiAgICBPbiBU dWUsIEp1bCAyNCwgMjAxOCBhdCAwNzoyNDowOVBNICswMDAwLCBQYXR0b24sQ2hyaXN0b3BoZXIg SiB3cm90ZToNCiAgICA+IEhpIGFsbCwNCiAgICA+DQogICAgPg0KICAgID4gSSd2ZSB0YWtlbiB0 aGUgbGliZXJ0eSBvZiBhZGRyZXNzaW5nIHRoZSBjaGFuZ2VzIHRvIHRoZSBkZWxlZ2F0ZWQgY3Jl ZGVudGlhbHMgZXh0ZW5zaW9uIHRoYXQgd2VyZSByZXF1ZXN0ZWQgYXQgSUVURjoNCiAgICA+DQog ICAgPiBodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvdGxzLXN1YmNlcnRzL3B1bGwvMTMNCg0KICAg ID4NCiAgICA+DQogICAgPiBUaGUgY2hhbmdlcyB0aGF0IHdvdWxkIGJlIGFkb3B0ZWQgaW4gZHJh ZnQtMDIgYXJlIGFzIGZvbGxvd3M6DQogICAgPg0KICAgID4gICAqICAgRHJvcCBzdXBwb3J0IGZv ciBUTFMgMS4yLg0KICAgID4gICAqICAgQWxsb3cgdGhlIGNyaXRpY2FsIGJpdCBvZiB0aGUgWC41 MDkgZXh0ZW5zaW9uIHRvIGJlIHNldC4NCiAgICA+ICAgKiAgIEFkZCB0aGUgcHJvdG9jb2wgdmVy c2lvbiBhbmQgY3JlZGVudGlhbCBzaWduYXR1cmUgYWxnb3JpdGhtDQogICAgPiAgICAgICB0byB0 aGUgQ3JlZGVudGlhbCBzdHJ1Y3R1cmUuDQogICAgPiAgICogICBNYWtlIHRoZSBLZXlVc2FnZSBv ZiB0aGUgZGVsZWdhdGlvbiBjZXJ0aWZpY2F0ZSBzdHJpY3Rlci4NCiAgICA+ICAgKiAgIFNwZWNp ZnkgdW5kZWZpbmVkIGJlaGF2aW9yIGluIGEgZmV3IGNhc2VzLg0KICAgID4NCiAgICA+IEl0IHdh cyBzdWdnZXN0ZWQgdGhhdCB3ZSBhZGQgb3B0aW9uYWwgIm11c3QtdXNlLURDIiBzZW1hbnRpY3Mg dG8gdGhlDQogICAgPiBjZXJ0aWZpY2F0ZS4gVGhlIHNvbHV0aW9uIHdlIGNhbWUgdXAgd2l0aCB3 YXMgdG8gYWRkIGEgInN0cmljdCIgZmxhZw0KICAgID4gdG8gdGhlIGV4dGVuc2lvbiB0aGF0IGlz IHNldCBpZiAoYW5kIG9ubHkgaWYpIHRoZSBleHRlbnNpb24gaXMgbWFya2VkDQogICAgPiBjcml0 aWNhbC4gVGhlIGlkZWEgaXMgdGhhdCBpZiB0aGUgInN0cmljdCIgZmxhZyBpcyBzZXQgYW5kIHRo ZSBzZXJ2ZXINCiAgICA+IGRvZXNuJ3Qgb2ZmZXIgYSBEQywgdGhlbiBjbGllbnQgbXVzdCBhYm9y dCB0aGUgaGFuZHNoYWtlLCBJbiBteSBvcGluaW9uLA0KICAgID4gdGhlIGNvbXBsZXhpdHkgdGhp cyBhZGRzIHRvIHRoZSBwcm90b2NvbCBvdXR3ZWlnaHMgdGhlIHBvdGVudGlhbCBiZW5lZml0cy4N CiAgICA+DQogICAgPiBDb21tZW50cyBvbiB0aGUgUFIgYXJlIHdlbGNvbWUuDQoNCiAgICBUaGlz IGhhcyB0aGUgc2lnbmlmY2FudCBjcml0aWNhbCBmbGFnIGlzc3VlLiBJdCBzaG91bGQgYXQgbWlu aW11bSBiZQ0KICAgIGV4cGxpY2l0bHkgY2FsbGVkIG91dCwgYXMgSSBkbyBub3Qga25vdyBhbnkg cHJlY2VuZGVudCBmb3IgdGhpcyBraW5kIG9mDQogICAgYmVoYXZpb3IgKGNoZWNrIHRoYXQgc29t ZSBleHRlbnNpb24gaXMgY3JpdGljYWwgeWVzLCBidXQgbm90IGNoYW5naW5nDQogICAgbWVhbmlu ZyBvZiBleHRlbnNpb24gZGVwZW5kaW5nIG9uIGNyaXRpY2FsIGZsYWcpLg0KDQoNCiAgICBJIHdh dGNoZWQgdGhlIHByZXNlbnRhdGlvbiBhbmQgdGhlIHJlc3VsdGluZyBRJkEgYWdhaW4uIFNob3J0 IHN1bW1hcnkgb2YNCiAgICByZWxldmFudCBzdHVmZjoNCg0KICAgIC0gVGhlIG1vdGl2YXRpb24g aW4gdGhlIHNsaWRlcyBpcyB0byByZWR1Y2UgZXhwb3N1cmUgb2YgcHJpdmF0ZSBrZXlzIHRvDQog ICAgICBtZW1vcnkgZGlzY2xvc3VyZSB2dWxlcm5hYmlsaXRpZXMsIHdpdGhvdXQgcmVkdWNpbmcg cGVyZm9ybWFuY2UuDQogICAgLSBUaGUgb3JpZ25hbCBwcm9wb3NhbCB3YXMgdG8gYWRkIGEgVExT IEZlYXR1cmUgZXh0ZW5zaW9uIHZhbHVlLiBObw0KICAgICAgZGlzY3Vzc2lvbi4NCiAgICAtIFRo ZSBkcmF3YmFjayBvZiAic3RyaWN0IG1vZGUiIHdvdWxkIGJlIGNhdXNpbmcgaXNzdWVzIHdpdGgg c2VydmVycw0KICAgICAgdGhhdCBjYW4gbm90IGVmZmVjdGl2ZWx5IHN3aXRjaCBiZXR3ZWVuIGNl cnRpZmljYXRlcy4NCiAgICAtIFRoZXJlIGlzIHF1ZXN0aW9uIGFib3V0IGZhbGxiYWNrLiBQYXJh cGhyYXNlZCBhbnN3ZXI6IExVUksuDQoNCg0KICAgIFRMUyBGZWF0dXJlIGV4dGVuc2lvbnMgaGF2 ZSBzb21lIHJlYWxseSB1bnduYXRlZCBwcm9wZXJ0aWVzIGhlcmUuIFRoZXkNCiAgICBhcmUgbmV2 ZXIgY3JpdGljYWwgb24gY2xpZW50IHNpZGUsIGFuZCB0aGV5IGhhdmUgT1ItaW5oZXJpdGFuY2Uu IFlvdQ0KICAgIGRlZmluaXRlbHkgZG8gbm90IHdhbnQgT1ItaW5oZXJpdGFuY2UgaGVyZS4NCg0K ICAgIFdlbGwsIGFmdGVyIHRoaXMsIHRoZSBiZXN0IHVzZWNhc2UgSSBjYW4gY29tZSB1cCB3aXRo IHN0cmljdCBmbGFnIGlzDQogICAgc3RpbGwgZGVhbGluZyB3aXRoIExVUksgZW5kcG9pbnRzIHRo YXQgY2FuIG5vdCBkbyBwcm9vZi1vZi1wb3NzZXNzaW9uDQogICAgb3IgZm9ybWF0IGNoZWNraW5n WzFdLg0KDQoNCiAgICBbMV0gVExTIDEuMiBhbmQgMS4zIHNlcnZlcnMgc2hvdWxkIG9ubHkgYXNr IGZvciBzaWduYXR1cmVzIGFuZCBvbmx5DQogICAgb3ZlciB0aGUgZm9sbG93aW5nIGtpbmRzIG9m IGRhdGE6DQoNCiAgICAtIDw2NCBieXRlcz4gMDMgMDAgMTcgNDEgMDQgPDY0IGJ5dGVzPg0KICAg IC0gPDY0IGJ5dGVzPiAwMyAwMCAxOCA2MSAwNCA8OTYgYnl0ZXM+DQogICAgLSA8NjQgYnl0ZXM+ IDAzIDAwIDE5IDg1IDA0IDwxMzIgYnl0ZXM+IChyYXJlLCBQLTUyMSkNCiAgICAtIDw2NCBieXRl cz4gMDMgMDAgMUEgNDEgMDQgPDY0IGJ5dGVzPiAocmFyZSwgYnJhaW5wb29sKQ0KICAgIC0gPDY0 IGJ5dGVzPiAwMyAwMCAxQiA2MSAwNCA8OTYgYnl0ZXM+IChyYXJlLCBicmFpbnBvb2wpDQogICAg LSA8NjQgYnl0ZXM+IDAzIDAwIDFDIDgxIDA0IDwxMjggYnl0ZXM+IChyYXJlLCBicmFpbnBvb2wp DQogICAgLSA8NjQgYnl0ZXM+IDAzIDAwIDFEIDIwIDwzMiBieXRlcz4NCiAgICAtIDw2NCBieXRl cz4gMDMgMDAgMUUgMzggPDU2IGJ5dGVzPiAocmFyZSwgWDQ0OCkNCiAgICAtIDw2NCBzcGFjZXM+ ICJUTFMgMS4zLCBzZXJ2ZXIgQ2VydGlmaWNhdGVWZXJpZnkiIDAwIDwzMiBieXRlcz4NCiAgICAt IDw2NCBzcGFjZXM+ICJUTFMgMS4zLCBzZXJ2ZXIgQ2VydGlmaWNhdGVWZXJpZnkiIDAwIDw0OCBi eXRlcz4NCg0KICAgIE5vbmUgb2YgdGhlc2UgY292ZXJzIGRlbGVnYXRlZCBjcmVkZW50aWFsIHNp Z25hdHVyZXMsIHdoaWNoIHdvdWxkDQogICAgY2F1c2UgYW55IGF0dGVtcHQgdG8gYXNrIGZvciBE QyBzaWduYXR1cmUgdG8gZmFpbCBpZiB0aGUgZm9ybWF0IGlzDQogICAgY2hlY2tlZC4uDQoNCg0K DQogICAgLUlsYXJpDQoNCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgVExTIG1haWxpbmcgbGlzdA0KICAgIFRMU0BpZXRmLm9yZw0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_MWHPR22MB0461FC1102E9F077185AD97FC62B0MWHPR22MB0461namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZSB0eXBlPSJ0ZXh0L2NzcyIgc3R5bGU9 ImRpc3BsYXk6bm9uZTsiPjwhLS0gUCB7bWFyZ2luLXRvcDowO21hcmdpbi1ib3R0b206MDt9IC0t Pjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBkaXI9Imx0ciI+DQo8ZGl2IGlkPSJkaXZ0YWdkZWZh dWx0d3JhcHBlciIgc3R5bGU9ImZvbnQtc2l6ZToxMnB0O2NvbG9yOiMwMDAwMDA7Zm9udC1mYW1p bHk6Q2FsaWJyaSxIZWx2ZXRpY2Esc2Fucy1zZXJpZjsiIGRpcj0ibHRyIj4NCjxwIHN0eWxlPSJt YXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5UaGFua3MgYWxsIGZvciB0aGUgZmVlZGJhY2sh IEluIGxpZ2h0IG9mIHlvdXIgb2JzZXJ2YXRpb25zLCB3ZSd2ZSByZXZpc2VkIHRoZSBjaGFuZ2Vz IHByb3Bvc2VkIGZvciZuYnNwO2RyYWZ0LTAyOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZ2l0aHVi LmNvbS90bHN3Zy90bHMtc3ViY2VydHMvcHVsbC8xMyIgY2xhc3M9Ik9XQUF1dG9MaW5rIiBpZD0i TFBsbmszMzg0NiIgcHJldmlld3JlbW92ZWQ9InRydWUiIHN0eWxlPSIiPmh0dHBzOi8vZ2l0aHVi LmNvbS90bHN3Zy90bHMtc3ViY2VydHMvcHVsbC8xMzwvYT4uPGJyPg0KPC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxicj4NCjwvcD4NCjxwIHN0eWxlPSJtYXJn aW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj5UaGUgY2hhbmdlcyBmb3IgZHJhZnQtMDIgYXJlIGFz IGZvbGxvd3M6PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjwv cD4NCjxkaXY+DQo8dWwgc3R5bGU9Im1hcmdpbi1ib3R0b206IDBweDsgbWFyZ2luLXRvcDogMHB4 OyI+DQo8bGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOiAxMnB0OyI+RHJvcCBzdXBwb3J0IGZvciBUTFMgMS4yLjwvc3Bhbj48YnI+ DQo8L2xpPjxsaT48c3BhbiBzdHlsZT0iZm9udC1zaXplOiAxMnB0OyI+PC9zcGFuPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6IDEycHQ7Ij5BZGQgdGhlIHByb3RvY29sIHZlcnNpb24gYW5kIGNyZWRl bnRpYWwgc2lnbmF0dXJlIGFsZ29yaXRobSB0byB0aGUgQ3JlZGVudGlhbCBzdHJ1Y3R1cmUuPC9z cGFuPjxicj4NCjwvbGk+PGxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDEycHQ7Ij48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTogMTJwdDsiPlNwZWNpZjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOiAxMnB0OyI+eSB1bmRlZmluZWQgYmVoYXZpb3IgaW4gYSBmZXcgY2FzZXM6IHdo ZW4gdGhlIGNsaWVudCByZWNlaXZlcyBhIERDIHdpdGhvdXQgaW5kaWNhdGVkIHN1cHBvcnQ7IHdo ZW4gdGhlIGNsaWVudCBpbmRpY2F0ZXMgdGhlIGV4dGVuc2lvbiBpbiBhbg0KIGludmFsaWQgcHJv dG9jb2wgdmVyc2lvbjsgYW5kIHdoZW4gRENzIGFyZSBzZW50IGFzIGV4dGVuc2lvbnMgdG8gY2Vy dGlmaWNhdGVzIG90aGVyIHRoYW4gdGhlIGVuZC1lbnRpdHkgY2VydGlmaWNhdGUuPC9zcGFuPjxi cj4NCjwvbGk+PC91bD4NCjwvZGl2Pg0KPGJyPg0KPHA+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10 b3A6MDttYXJnaW4tYm90dG9tOjAiPkFueSBhZGRpdGlvbmFsIGZlZWRiYWNrIGlzIHdlbGNvbWUu PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi10b3A6MDttYXJnaW4tYm90dG9tOjAiPjxicj4NCjwvcD4N CjxwIHN0eWxlPSJtYXJnaW4tdG9wOjA7bWFyZ2luLWJvdHRvbTowIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOiAxMnB0OyI+VGhhbmtzLDwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLXRvcDow O21hcmdpbi1ib3R0b206MCI+Q2hyaXN0b3BoZXIgUGF0dG9uPC9wPg0KPGJyPg0KPGJyPg0KPGRp diBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsiPg0KPGhyIHN0eWxlPSJkaXNwbGF5OmlubGlu ZS1ibG9jazt3aWR0aDo5OCUiIHRhYmluZGV4PSItMSI+DQo8ZGl2IGlkPSJkaXZScGx5RndkTXNn IiBkaXI9Imx0ciI+PGZvbnQgZmFjZT0iQ2FsaWJyaSwgc2Fucy1zZXJpZiIgc3R5bGU9ImZvbnQt c2l6ZToxMXB0IiBjb2xvcj0iIzAwMDAwMCI+PGI+RnJvbTo8L2I+IEJsdW1lbnRoYWwsIFVyaSAt IDA1NTMgLSBNSVRMTCAmbHQ7dXJpQGxsLm1pdC5lZHUmZ3Q7PGJyPg0KPGI+U2VudDo8L2I+IFR1 ZXNkYXksIEp1bHkgMjQsIDIwMTggNDo0MCBQTTxicj4NCjxiPlRvOjwvYj4gSWxhcmkgTGl1c3Zh YXJhOyBQYXR0b24sQ2hyaXN0b3BoZXIgSjxicj4NCjxiPkNjOjwvYj4gdGxzQGlldGYub3JnPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBQcm9wb3NhbHMgZm9yIGRyYWZ0LWlldGYtdGxz LXN1YmNlcnRzLTAyPC9mb250Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBjbGFz cz0iQm9keUZyYWdtZW50Ij48Zm9udCBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx cHQ7Ij4NCjxkaXYgY2xhc3M9IlBsYWluVGV4dCI+SSBvYmplY3QgdG8gcmUtaW50ZXJwcmV0aW5n L292ZXJsb2FkaW5nIHRoZSBDcml0aWNhbCBmbGFnLiBJdCBoYXMgb25lIGFuZCBvbmx5IG9uZSBt ZWFuaW5nOiAmcXVvdDtJZiB0aGUgcGFyc2VyIGRvZXMgbm90IHVuZGVyc3RhbmQgdGhlIGdpdmVu IGF0dHJpYnV0ZSwgaXQgbXVzdCBhYm9ydCBwYXJzaW5nIGlmIHRoaXMgYXR0cmlidXRlIGlzIG1h cmtlZCBhcyBDcml0aWNhbCAob3IgaWdub3JlIHRoaXMgYXR0cmlidXRlDQogYW5kIGNvbnRpbnVl IHBhcnNpbmcgaWYgdGhlIENyaXRpY2FsIGZsYWcgaXMgbm90IHNldCkmcXVvdDsuIDxicj4NCjxi cj4NCjxicj4NCu+7v09uIDcvMjQvMTgsIDE2OjI1LCAmcXVvdDtUTFMgb24gYmVoYWxmIG9mIEls YXJpIExpdXN2YWFyYSZxdW90OyAmbHQ7dGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IGlsYXJpbGl1c3ZhYXJhQHdlbGhvLmNvbSZndDsgd3JvdGU6PGJyPg0KPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IE9uIFR1ZSwgSnVsIDI0LCAyMDE4IGF0IDA3OjI0OjA5UE0gJiM0MzswMDAwLCBQ YXR0b24sQ2hyaXN0b3BoZXIgSiB3cm90ZTo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBI aSBhbGwsPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7ICZndDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgSSd2ZSB0YWtlbiB0aGUgbGli ZXJ0eSBvZiBhZGRyZXNzaW5nIHRoZSBjaGFuZ2VzIHRvIHRoZSBkZWxlZ2F0ZWQgY3JlZGVudGlh bHMgZXh0ZW5zaW9uIHRoYXQgd2VyZSByZXF1ZXN0ZWQgYXQgSUVURjo8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YSBocmVmPSJodHRw czovL2dpdGh1Yi5jb20vdGxzd2cvdGxzLXN1YmNlcnRzL3B1bGwvMTMiIGlkPSJMUGxuazExODU2 MSIgY2xhc3M9Ik9XQUF1dG9MaW5rIiBwcmV2aWV3cmVtb3ZlZD0idHJ1ZSI+DQpodHRwczovL2dp dGh1Yi5jb20vdGxzd2cvdGxzLXN1YmNlcnRzL3B1bGwvMTM8L2E+PGJyPg0KPGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7ICZndDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsgPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7ICZndDsgVGhlIGNoYW5nZXMgdGhhdCB3b3VsZCBiZSBhZG9wdGVkIGlu IGRyYWZ0LTAyIGFyZSBhcyBmb2xsb3dzOjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7IDxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsgRHJv cCBzdXBwb3J0IGZvciBUTFMgMS4yLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7 Jm5ic3A7ICombmJzcDsmbmJzcDsgQWxsb3cgdGhlIGNyaXRpY2FsIGJpdCBvZiB0aGUgWC41MDkg ZXh0ZW5zaW9uIHRvIGJlIHNldC48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyZuYnNwOyZu YnNwOyAqJm5ic3A7Jm5ic3A7IEFkZCB0aGUgcHJvdG9jb2wgdmVyc2lvbiBhbmQgY3JlZGVudGlh bCBzaWduYXR1cmUgYWxnb3JpdGhtPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdG8gdGhlIENyZWRlbnRpYWwgc3RydWN0dXJl Ljxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAmZ3Q7Jm5ic3A7Jm5ic3A7ICombmJzcDsmbmJzcDsg TWFrZSB0aGUgS2V5VXNhZ2Ugb2YgdGhlIGRlbGVnYXRpb24gY2VydGlmaWNhdGUgc3RyaWN0ZXIu PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsmbmJzcDsmbmJzcDsgKiZuYnNwOyZuYnNwOyBT cGVjaWZ5IHVuZGVmaW5lZCBiZWhhdmlvciBpbiBhIGZldyBjYXNlcy48YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBJdCB3YXMgc3VnZ2Vz dGVkIHRoYXQgd2UgYWRkIG9wdGlvbmFsICZxdW90O211c3QtdXNlLURDJnF1b3Q7IHNlbWFudGlj cyB0byB0aGU8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyBjZXJ0aWZpY2F0ZS4gVGhlIHNv bHV0aW9uIHdlIGNhbWUgdXAgd2l0aCB3YXMgdG8gYWRkIGEgJnF1b3Q7c3RyaWN0JnF1b3Q7IGZs YWc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyB0byB0aGUgZXh0ZW5zaW9uIHRoYXQgaXMg c2V0IGlmIChhbmQgb25seSBpZikgdGhlIGV4dGVuc2lvbiBpcyBtYXJrZWQ8YnI+DQombmJzcDsm bmJzcDsmbmJzcDsgJmd0OyBjcml0aWNhbC4gVGhlIGlkZWEgaXMgdGhhdCBpZiB0aGUgJnF1b3Q7 c3RyaWN0JnF1b3Q7IGZsYWcgaXMgc2V0IGFuZCB0aGUgc2VydmVyPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7ICZndDsgZG9lc24ndCBvZmZlciBhIERDLCB0aGVuIGNsaWVudCBtdXN0IGFib3J0IHRo ZSBoYW5kc2hha2UsIEluIG15IG9waW5pb24sPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ICZndDsg dGhlIGNvbXBsZXhpdHkgdGhpcyBhZGRzIHRvIHRoZSBwcm90b2NvbCBvdXR3ZWlnaHMgdGhlIHBv dGVudGlhbCBiZW5lZml0cy48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgJmd0OyA8YnI+DQombmJz cDsmbmJzcDsmbmJzcDsgJmd0OyBDb21tZW50cyBvbiB0aGUgUFIgYXJlIHdlbGNvbWUuPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGhhcyB0aGUg c2lnbmlmY2FudCBjcml0aWNhbCBmbGFnIGlzc3VlLiBJdCBzaG91bGQgYXQgbWluaW11bSBiZTxi cj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBleHBsaWNpdGx5IGNhbGxlZCBvdXQsIGFzIEkgZG8gbm90 IGtub3cgYW55IHByZWNlbmRlbnQgZm9yIHRoaXMga2luZCBvZjxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyBiZWhhdmlvciAoY2hlY2sgdGhhdCBzb21lIGV4dGVuc2lvbiBpcyBjcml0aWNhbCB5ZXMs IGJ1dCBub3QgY2hhbmdpbmc8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgbWVhbmluZyBvZiBleHRl bnNpb24gZGVwZW5kaW5nIG9uIGNyaXRpY2FsIGZsYWcpLjxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IEkgd2F0 Y2hlZCB0aGUgcHJlc2VudGF0aW9uIGFuZCB0aGUgcmVzdWx0aW5nIFEmYW1wO0EgYWdhaW4uIFNo b3J0IHN1bW1hcnkgb2Y8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgcmVsZXZhbnQgc3R1ZmY6PGJy Pg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAtIFRoZSBtb3Rp dmF0aW9uIGluIHRoZSBzbGlkZXMgaXMgdG8gcmVkdWNlIGV4cG9zdXJlIG9mIHByaXZhdGUga2V5 cyB0bzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBtZW1vcnkgZGlzY2xvc3Vy ZSB2dWxlcm5hYmlsaXRpZXMsIHdpdGhvdXQgcmVkdWNpbmcgcGVyZm9ybWFuY2UuPGJyPg0KJm5i c3A7Jm5ic3A7Jm5ic3A7IC0gVGhlIG9yaWduYWwgcHJvcG9zYWwgd2FzIHRvIGFkZCBhIFRMUyBG ZWF0dXJlIGV4dGVuc2lvbiB2YWx1ZS4gTm88YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsgZGlzY3Vzc2lvbi48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgLSBUaGUgZHJhd2JhY2sg b2YgJnF1b3Q7c3RyaWN0IG1vZGUmcXVvdDsgd291bGQgYmUgY2F1c2luZyBpc3N1ZXMgd2l0aCBz ZXJ2ZXJzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoYXQgY2FuIG5vdCBl ZmZlY3RpdmVseSBzd2l0Y2ggYmV0d2VlbiBjZXJ0aWZpY2F0ZXMuPGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7IC0gVGhlcmUgaXMgcXVlc3Rpb24gYWJvdXQgZmFsbGJhY2suIFBhcmFwaHJhc2VkIGFu c3dlcjogTFVSSy48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBUTFMgRmVhdHVyZSBleHRlbnNpb25zIGhhdmUg c29tZSByZWFsbHkgdW53bmF0ZWQgcHJvcGVydGllcyBoZXJlLiBUaGV5PGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IGFyZSBuZXZlciBjcml0aWNhbCBvbiBjbGllbnQgc2lkZSwgYW5kIHRoZXkgaGF2 ZSBPUi1pbmhlcml0YW5jZS4gWW91PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IGRlZmluaXRlbHkg ZG8gbm90IHdhbnQgT1ItaW5oZXJpdGFuY2UgaGVyZS48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsg PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFdlbGwsIGFmdGVyIHRoaXMsIHRoZSBiZXN0IHVzZWNh c2UgSSBjYW4gY29tZSB1cCB3aXRoIHN0cmljdCBmbGFnIGlzPGJyPg0KJm5ic3A7Jm5ic3A7Jm5i c3A7IHN0aWxsIGRlYWxpbmcgd2l0aCBMVVJLIGVuZHBvaW50cyB0aGF0IGNhbiBub3QgZG8gcHJv b2Ytb2YtcG9zc2Vzc2lvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBvciBmb3JtYXQgY2hlY2tp bmdbMV0uPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgWzFdIFRMUyAxLjIgYW5kIDEuMyBzZXJ2ZXJzIHNob3Vs ZCBvbmx5IGFzayBmb3Igc2lnbmF0dXJlcyBhbmQgb25seTxicj4NCiZuYnNwOyZuYnNwOyZuYnNw OyBvdmVyIHRoZSBmb2xsb3dpbmcga2luZHMgb2YgZGF0YTo8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gJmx0OzY0IGJ5dGVzJmd0OyAwMyAwMCAxNyA0 MSAwNCAmbHQ7NjQgYnl0ZXMmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gJmx0OzY0IGJ5 dGVzJmd0OyAwMyAwMCAxOCA2MSAwNCAmbHQ7OTYgYnl0ZXMmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7 Jm5ic3A7IC0gJmx0OzY0IGJ5dGVzJmd0OyAwMyAwMCAxOSA4NSAwNCAmbHQ7MTMyIGJ5dGVzJmd0 OyAocmFyZSwgUC01MjEpPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC0gJmx0OzY0IGJ5dGVzJmd0 OyAwMyAwMCAxQSA0MSAwNCAmbHQ7NjQgYnl0ZXMmZ3Q7IChyYXJlLCBicmFpbnBvb2wpPGJyPg0K Jm5ic3A7Jm5ic3A7Jm5ic3A7IC0gJmx0OzY0IGJ5dGVzJmd0OyAwMyAwMCAxQiA2MSAwNCAmbHQ7 OTYgYnl0ZXMmZ3Q7IChyYXJlLCBicmFpbnBvb2wpPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC0g Jmx0OzY0IGJ5dGVzJmd0OyAwMyAwMCAxQyA4MSAwNCAmbHQ7MTI4IGJ5dGVzJmd0OyAocmFyZSwg YnJhaW5wb29sKTxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAtICZsdDs2NCBieXRlcyZndDsgMDMg MDAgMUQgMjAgJmx0OzMyIGJ5dGVzJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyAtICZsdDs2 NCBieXRlcyZndDsgMDMgMDAgMUUgMzggJmx0OzU2IGJ5dGVzJmd0OyAocmFyZSwgWDQ0OCk8YnI+ DQombmJzcDsmbmJzcDsmbmJzcDsgLSAmbHQ7NjQgc3BhY2VzJmd0OyAmcXVvdDtUTFMgMS4zLCBz ZXJ2ZXIgQ2VydGlmaWNhdGVWZXJpZnkmcXVvdDsgMDAgJmx0OzMyIGJ5dGVzJmd0Ozxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyAtICZsdDs2NCBzcGFjZXMmZ3Q7ICZxdW90O1RMUyAxLjMsIHNlcnZl ciBDZXJ0aWZpY2F0ZVZlcmlmeSZxdW90OyAwMCAmbHQ7NDggYnl0ZXMmZ3Q7PGJyPg0KJm5ic3A7 Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyBOb25lIG9mIHRoZXNlIGNvdmVy cyBkZWxlZ2F0ZWQgY3JlZGVudGlhbCBzaWduYXR1cmVzLCB3aGljaCB3b3VsZDxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyBjYXVzZSBhbnkgYXR0ZW1wdCB0byBhc2sgZm9yIERDIHNpZ25hdHVyZSB0 byBmYWlsIGlmIHRoZSBmb3JtYXQgaXM8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgY2hlY2tlZC4u PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IC1JbGFyaTxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsgPGJyPg0KJm5ic3A7Jm5i c3A7Jm5ic3A7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IFRMUyBtYWlsaW5nIGxpc3Q8YnI+DQombmJzcDsmbmJz cDsmbmJzcDsgVExTQGlldGYub3JnPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIiBpZD0iTFBsbms5NjY2MzYi IGNsYXNzPSJPV0FBdXRvTGluayIgcHJldmlld3JlbW92ZWQ9InRydWUiPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHM8L2E+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 IDxicj4NCjwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_MWHPR22MB0461FC1102E9F077185AD97FC62B0MWHPR22MB0461namp_-- From nobody Thu Jul 26 11:38:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83ECA130E09 for ; Thu, 26 Jul 2018 11:38:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.711 X-Spam-Level: X-Spam-Status: No, score=-2.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f0vqkZuG6BIq for ; Thu, 26 Jul 2018 11:38:40 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76E1F130DBE for ; Thu, 26 Jul 2018 11:38:40 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6QIbvjQ010461; Thu, 26 Jul 2018 19:38:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=date : from : to : cc : subject : message-id : references : mime-version : content-type : content-transfer-encoding : in-reply-to; s=jan2016.eng; bh=zJXCGlc8gnsfMd5bLV0G9zH12t5qdONwsFAkgYWQJxs=; b=PVpQy5Q1GMAKemDJ/+wXP/z8OkPLyy7vhgqr4J2pgvfSyEc4F+9qf3SgQVCGdDe5YBxW SC5aNVSt7MBL1qWrNy4JcwD+9iuz0OJLv7rjwMWSIrQy7NuaqWDgt9W7GWVubpbCTo/1 IqRIZh3GT4r7uEeNEiNmGgYv/5Svu+w2HKSh9BiZ0CwBkeK10uXYkKA//9Bs37n8EruT 1FUhfApo7wMkQ14SvWIjSMfHBT7FKyhtqStRUL4DPoQa/3lohDWnFgdOovZOHyUShya+ 3TT3A7BCEUxZKtkasMC9JzoXhrPJTRwDpqMSZcCwCPqPh0hfFvptZbKDjYDhC7GxsmYS VA== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2ke39bgu9n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Jul 2018 19:38:39 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6QIYjSC006348; Thu, 26 Jul 2018 14:38:38 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2kc05uxgym-1; Thu, 26 Jul 2018 14:38:37 -0400 Received: from bos-lpczi.kendall.corp.akamai.com (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 815942099F; Thu, 26 Jul 2018 18:38:36 +0000 (GMT) Received: from bkaduk by bos-lpczi.kendall.corp.akamai.com with local (Exim 4.86_2) (envelope-from ) id 1fil9n-00021M-SS; Thu, 26 Jul 2018 13:38:35 -0500 Date: Thu, 26 Jul 2018 13:38:35 -0500 From: Benjamin Kaduk To: Eric Rescorla Cc: "" Message-ID: <20180726183835.GQ14551@akamai.com> References: <20180719230009.GD14551@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-26_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=925 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807260190 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-26_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=914 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807260190 Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 18:38:43 -0000 On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote: > Ben, > > Thanks for focusing on this issue. Just trying to make sure loose ends get wrapped up before TLS 1.3 goes final... > Chris and I have been discussing an alternative design which we think > is more consistent with the existing structure, which we call PSK > Importers. As with your design, we have an input universal PSK, but (I think you mean David Benjamin's design?) > instead of using explicitly as part of the connection, we just use it > as the base key to import a set of new PSKs into TLS. > > As with Universal PSKs (UPSKs), each input key is a triplet of > (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity > as used today. To use a UPSK, an implementation takes the set of KDF > hashes it knows about H_i and derives a set of PSKs: > > Hash_i: H_i > Identity_i: BaseIdentity || H_i > Key_i: Derived from BaseKey and Identity_i > > This gives you a set of keys which you can offer simultaneously on the > TLS connection in independent psk_identity blocks. (Note that the hash > algorithm is what differentiates each derived key.) This is a bit > ugly, but with the current TLS 1.3 ciphers, this basically just means > SHA-256, but even in the worst case it’s probably only 2-3. > > The nice thing about this design is that if you know the set of hash > functions, you can just compute all the imported PSKs in advance, and > there’s no need to touch the internals of the TLS stack. This also > means that if you have decided you don’t like old hash X, you don’t > need to use it to compute PSK binders, you just use it do the KDF, > which seems like it has weakersecurity requirements. > > Here’s a specific construction, but we’re flexible about the details: > > struct { > opaque base_identity<1...2^16-1>; > HashAlgorithm hash; > } imported_psk_identity; > > UPSKx = HKDF-Extract(0, UPSK) // UPSK is the input universal PSK > PSK = HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity), > TargetHash.length) // Might need to shorten label > > These functions would be executed with the KDF associated with the UPSK, > but produce > a key the size of the desired hash. > > This brings us to the question of TLS 1.2. I found Ilari’s analyis > pretty persuasive, so I would suggest we add the following text to the > TLS 1.3 spec: > > TLS 1.3 takes a conservative approach to PSKs by binding them to a > specific KDF. TLS 1.2 allows PSKs to be used with any hash function (I know it's awkward to write about, but we don't really get away with pretending that 1.2 1.3 are the only versions in the rest of the document.) > and the TLS 1.2 PRF. The constructions in TLS 1.2 and TLS 1.3, > although both based on HMAC, are very different and there is no known > way in which reuse of the same PSK in TLS 1.3 and TLS 1.2 would > produce related output, although only limited formal analysis has been > done. Implementations MAY wish to avoid reuse of keys between TLS 1.3 > and TLS 1.2, or use a key derivation proposal such as [Informative ref > to this email or a draft]. I might add "to avoid the risk of using under-analyzed cryptographic constructions" (or similar), but implicit might be good enough. > > Other than this, we wouldn’t make any changes to the document. > > What do people think? This seems like a good sort of approach to take (that is, make the key derivation for hash specificity something that happens outside of the TLS mechanics itself), given the context in which we're thinking about it. It might be worth going even farther, and including the target TLS version in the (derived) identities and keys. Though maybe the negotiation process means that doesn't actually protect against an attack; I haven't thought it through enough. Thanks for putting this together, Ben (no hats) From nobody Thu Jul 26 11:47:56 2018 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 59F52130F67; Thu, 26 Jul 2018 11:47:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153263087436.24689.11828594079061718291.idtracker@ietfa.amsl.com> Date: Thu, 26 Jul 2018 11:47:54 -0700 Archived-At: Subject: [TLS] The TLS WG has placed draft-housley-tls-tls13-cert-with-extern-psk in state "Candidate for WG Adoption" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 List-Id: "This is the mailing list 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, 26 Jul 2018 18:47:54 -0000 The TLS WG has placed draft-housley-tls-tls13-cert-with-extern-psk in state Candidate for WG Adoption (entered by Christopher Wood) The document is available at https://datatracker.ietf.org/doc/draft-housley-tls-tls13-cert-with-extern-psk/ From nobody Thu Jul 26 11:48:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E6413115B for ; Thu, 26 Jul 2018 11:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p-jT7ePQBROf for ; Thu, 26 Jul 2018 11:48:09 -0700 (PDT) Received: from mail-lf1-x133.google.com (mail-lf1-x133.google.com [IPv6:2a00:1450:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499AF130F3B for ; Thu, 26 Jul 2018 11:48:08 -0700 (PDT) Received: by mail-lf1-x133.google.com with SMTP id a4-v6so1894466lff.5 for ; Thu, 26 Jul 2018 11:48:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eX6bPgS4Y+VfzaAkB69AgczHLKJJkU1oAb/+1xsnhR0=; b=duDhxfCEkIHiuE+j8Ysko6IGYqhp6dsacHaBnavzaU0dBfx7GSzrrG5MHgQ8IuniHQ HIF7PKSigrRiBbOOaHcMOv25GNrCuKi1p12Y9JekajwqJcERgZZ+ozTtLhfxT9KB7v3T ++3JjPHliZyTcfNiDFgeL0tjVUTAdWeBB53R4qTKytwGhFIUpm2s4Tn6Bu7qDcbzPIPE D9PhfsmUhVF/jTfFuGV1U5naG93LGKytBgZo5h0cvJ9577fjWDLXlvN0jE1LKiqME2Q0 L2iCgjf0C7Lm5k7I/uV+QYLfUDDkvMo28iUMyZtiJ4IXRK9ZZRWfdVZZHsKCS+NkMfJt HTbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eX6bPgS4Y+VfzaAkB69AgczHLKJJkU1oAb/+1xsnhR0=; b=mBm6UTHN7Wi36166CgfUqFEtbb1MfsqwY5ybLqjpi3pAaNdd4RHBw31U9p1ojbvARX YwRkVWr/h0oUa2aaDxTH6dxwhsx2LCLhwYmgrIZMUVjExSOwj+TMXDk5MHBbYejqCuDH 1edSeZVeYs5+lz8tz9IfqxxRnj3FqDZqbsPt44U7wG2u/QDFJfmoGreCqcKMaD6frIg+ eTp0KmWhqG1vDTRzlLmQ6JDn/4EMCZUqv0dx12//tFBcF6EU3Dz7nfGSghVQutjDeSwA VL5DdFymhrah3xgfk4fLYubv45v38wAAv+sgDYGi04NZfg/KwX1IA1Ecs2lWukH2KGy0 sbsA== X-Gm-Message-State: AOUpUlFgDUVLnUy4vt6+zmItmOylacFia9Z1Zqq4ezCYf7lyIjHf5RuM rId1314fDp7mwhvv1yL10/vrAQ74ullAJ18RL0YfDA== X-Google-Smtp-Source: AAOMgpcgg2L6pApP1y9ovKkxpMQeHXvgcpHOf0ydaN2YK/qyLJWvuZQsf6oIl5vJhRangx+NPioPpXR2IWLA2JUyitU= X-Received: by 2002:a19:1460:: with SMTP id k93-v6mr2035614lfi.15.1532630886044; Thu, 26 Jul 2018 11:48:06 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Thu, 26 Jul 2018 11:47:25 -0700 (PDT) In-Reply-To: <20180726183835.GQ14551@akamai.com> References: <20180719230009.GD14551@akamai.com> <20180726183835.GQ14551@akamai.com> From: Eric Rescorla Date: Thu, 26 Jul 2018 11:47:25 -0700 Message-ID: To: Benjamin Kaduk Cc: "" Content-Type: multipart/alternative; boundary="00000000000088ecfd0571eb6f1f" Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 18:48:20 -0000 --00000000000088ecfd0571eb6f1f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 26, 2018 at 11:38 AM, Benjamin Kaduk wrote: > On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote: > > Ben, > > > > Thanks for focusing on this issue. > > Just trying to make sure loose ends get wrapped up before TLS 1.3 goes > final... > > > Chris and I have been discussing an alternative design which we think > > is more consistent with the existing structure, which we call PSK > > Importers. As with your design, we have an input universal PSK, but > > (I think you mean David Benjamin's design?) > Oh, yeah. I originally meant to be responding to davidben and then forgot to edit the msg. > > > instead of using explicitly as part of the connection, we just use it > > as the base key to import a set of new PSKs into TLS. > > > > As with Universal PSKs (UPSKs), each input key is a triplet of > > (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity > > as used today. To use a UPSK, an implementation takes the set of KDF > > hashes it knows about H_i and derives a set of PSKs: > > > > Hash_i: H_i > > Identity_i: BaseIdentity || H_i > > Key_i: Derived from BaseKey and Identity_i > > > > This gives you a set of keys which you can offer simultaneously on the > > TLS connection in independent psk_identity blocks. (Note that the hash > > algorithm is what differentiates each derived key.) This is a bit > > ugly, but with the current TLS 1.3 ciphers, this basically just means > > SHA-256, but even in the worst case it=E2=80=99s probably only 2-3. > > > > The nice thing about this design is that if you know the set of hash > > functions, you can just compute all the imported PSKs in advance, and > > there=E2=80=99s no need to touch the internals of the TLS stack. This a= lso > > means that if you have decided you don=E2=80=99t like old hash X, you d= on=E2=80=99t > > need to use it to compute PSK binders, you just use it do the KDF, > > which seems like it has weakersecurity requirements. > > > > Here=E2=80=99s a specific construction, but we=E2=80=99re flexible abou= t the details: > > > > struct { > > opaque base_identity<1...2^16-1>; > > HashAlgorithm hash; > > } imported_psk_identity; > > > > UPSKx =3D HKDF-Extract(0, UPSK) // UPSK is the input universal PSK > > PSK =3D HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity= ), > > TargetHash.length) // Might need to shorten label > > > > These functions would be executed with the KDF associated with the UPSK= , > > but produce > > a key the size of the desired hash. > > > > This brings us to the question of TLS 1.2. I found Ilari=E2=80=99s anal= yis > > pretty persuasive, so I would suggest we add the following text to the > > TLS 1.3 spec: > > > > TLS 1.3 takes a conservative approach to PSKs by binding them to a > > specific KDF. TLS 1.2 allows PSKs to be used with any hash function > > (I know it's awkward to write about, but we don't really get away with > pretending that 1.2 1.3 are the only versions in the rest of the document= .) > Fair enough. > > and the TLS 1.2 PRF. The constructions in TLS 1.2 and TLS 1.3, > > although both based on HMAC, are very different and there is no kno= wn > > way in which reuse of the same PSK in TLS 1.3 and TLS 1.2 would > > produce related output, although only limited formal analysis has > been > > done. Implementations MAY wish to avoid reuse of keys between TLS 1= .3 > > and TLS 1.2, or use a key derivation proposal such as [Informative > ref > > to this email or a draft]. > > I might add "to avoid the risk of using under-analyzed cryptographic > constructions" > (or similar), but implicit might be good enough. > I like that. -Ekr > > > > Other than this, we wouldn=E2=80=99t make any changes to the document. > > > > What do people think? > > This seems like a good sort of approach to take (that is, make the key > derivation > for hash specificity something that happens outside of the TLS mechanics > itself), > given the context in which we're thinking about it. > > It might be worth going even farther, and including the target TLS versio= n > in the > (derived) identities and keys. Though maybe the negotiation process mean= s > that > doesn't actually protect against an attack; I haven't thought it through > enough. > > Thanks for putting this together, > > Ben (no hats) > --00000000000088ecfd0571eb6f1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jul 26, 2018 at 11:38 AM, Benjamin Kaduk <= bkaduk@akamai.com> wrote:
On T= hu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
> Ben,
>
> Thanks for focusing on this issue.

Just trying to make sure loose ends get wrapped up before TLS 1.3 go= es final...

> Chris and I have been discussing an alternative design which we think<= br> > is more consistent with the existing structure, which we call PSK
> Importers. As with your design, we have an input universal PSK, but
(I think you mean David Benjamin's design?)


> instead of using explicitly as part of the connection, we just use it<= br> > as the base key to import a set of new PSKs into TLS.
>
> As with Universal PSKs (UPSKs), each input key is a triplet of
> (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity > as used today. To use a UPSK, an implementation takes the set of KDF > hashes it knows about H_i and derives a set of PSKs:
>
>=C2=A0 =C2=A0Hash_i: H_i
>=C2=A0 =C2=A0Identity_i: BaseIdentity || H_i
>=C2=A0 =C2=A0Key_i: Derived from BaseKey and Identity_i
>
> This gives you a set of keys which you can offer simultaneously on the=
> TLS connection in independent psk_identity blocks. (Note that the hash=
> algorithm is what differentiates each derived key.) This is a bit
> ugly, but with the current TLS 1.3 ciphers, this basically just means<= br> > SHA-256, but even in the worst case it=E2=80=99s probably only 2-3. >
> The nice thing about this design is that if you know the set of hash > functions, you can just compute all the imported PSKs in advance, and<= br> > there=E2=80=99s no need to touch the internals of the TLS stack. This = also
> means that if you have decided you don=E2=80=99t like old hash X, you = don=E2=80=99t
> need to use it to compute PSK binders, you just use it do the KDF,
> which seems like it has weakersecurity requirements.
>
> Here=E2=80=99s a specific construction, but we=E2=80=99re flexible abo= ut the details:
>
>=C2=A0 =C2=A0 struct {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque base_identity<1...2^16-1>;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 HashAlgorithm hash;
>=C2=A0 =C2=A0 } imported_psk_identity;
>
>=C2=A0 =C2=A0 UPSKx =3D HKDF-Extract(0, UPSK)=C2=A0 // UPSK is the inpu= t universal PSK
>=C2=A0 =C2=A0 PSK =3D HKDF-Expand-Label(UPSKx, "derived psk",= BaseKDF(psk_identity),
> TargetHash.length) // Might need to shorten label
>
> These functions would be executed with the KDF associated with the UPS= K,
> but produce
> a key the size of the desired hash.
>
> This brings us to the question of TLS 1.2. I found Ilari=E2=80=99s ana= lyis
> pretty persuasive, so I would suggest we add the following text to the=
> TLS 1.3 spec:
>
>=C2=A0 =C2=A0 =C2=A0TLS 1.3 takes a conservative approach to PSKs by bi= nding them to a
>=C2=A0 =C2=A0 =C2=A0specific KDF. TLS 1.2 allows PSKs to be used with a= ny hash function

(I know it's awkward to write about, but we don't reall= y get away with
pretending that 1.2 1.3 are the only versions in the rest of the document.)=



>=C2=A0 =C2=A0 =C2=A0and the TLS 1.2 PRF. The constructions in TLS 1.2 a= nd TLS 1.3,
>=C2=A0 =C2=A0 =C2=A0although both based on HMAC, are very different and= there is no known
>=C2=A0 =C2=A0 =C2=A0way in which reuse of the same PSK in TLS 1.3 and T= LS 1.2 would
>=C2=A0 =C2=A0 =C2=A0produce related output, although only limited forma= l analysis has been
>=C2=A0 =C2=A0 =C2=A0done. Implementations MAY wish to avoid reuse of ke= ys between TLS 1.3
>=C2=A0 =C2=A0 =C2=A0and TLS 1.2, or use a key derivation proposal such = as [Informative ref
>=C2=A0 =C2=A0 =C2=A0to this email or a draft].

I might add "to avoid the risk of using under-analyzed cryptogr= aphic constructions"
(or similar), but implicit might be good enough.

--00000000000088ecfd0571eb6f1f-- From nobody Thu Jul 26 15:05:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C967131240 for ; Thu, 26 Jul 2018 15:05:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mqE9sDnWwyu for ; Thu, 26 Jul 2018 15:05:32 -0700 (PDT) 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 259F5130E6F for ; Thu, 26 Jul 2018 15:05:32 -0700 (PDT) Received: by mail-io0-x22f.google.com with SMTP id g11-v6so2631246ioq.9 for ; Thu, 26 Jul 2018 15:05:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=TFtDgjvoXJLmyBJaGkCDCRsbGHCyp28qgFHI7Gqg2+Q=; b=ObBmhaVfoo4XAiv6u5UfM3a5+kkM5qLsAA0OzzDBIrnJ3Y7J+/gBn90pGXlDP9fq8E GnCOSCPjP8tpn9LZT0XRz6XS4Khz45aJfSXZJ2kAWpZOqVZyFuUKsWPfjjIPYkH9mgFr 04yL3/mOQoFXTn83oKdw8+h/0m0VgQhGZ26yM9FIfJ4L1MENVDJGIHvw3LNXLE4xl4Yg W8cEAAthrg5C2jFjunjWdr3X1/CBpT+dYbG3ETKzHJ9uGxgFbmOEWkqZmNQJ1tex2TJw ZWfDpfkIJaDQyaEHXs8pomIVQBVJg+vHt7uuyg2I+n8RNlTPAMWBqzBbbo+hL9Hon57g BPDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=TFtDgjvoXJLmyBJaGkCDCRsbGHCyp28qgFHI7Gqg2+Q=; b=gR6flX5OeZukf7r5Fe64WkryIc37IOJeatp5RlNP0yGyzAOsX6x4IFW+ZcaWk2E7+i z927Kao3X3R4DMzc2heNr7OienWBpijR+DSDY22V469jPjd4jN7b/tI7O1znaMLEoO94 v4sYCVYlZs6h+MaERpqAO8vpWLRu6wYiqUQuSnFbHb8hcOir4C7dRlSY1nru3kbuhAZB xFxQ+r3spTtEaiV6qRRbmsnmtGoHX7+rCCvXA+umszWPYhP30TEND8mNyjoePE7lJdr5 WvU+U1Ru1h2iSKku7hgtOGmBD+ZBk273o/KhpI9xlPbLTwJOfiFGNYlxvpOL//kGPLaM SgvA== X-Gm-Message-State: AOUpUlF52Z+LqT0g4abeQVvJfQJunj8kDmKdKH+OtTM56BJrpeIkhxVt epHn9j+w3K4w9IhnJFMvaAyrTj6T2ek+ssm9OQ9lEZGZ X-Google-Smtp-Source: AAOMgpdlY1REX75wOuBl/jPfre1UUCNZ7Y8VyT0iE6ePiqsrk9whls0/PITD4KpzXPf8wOG/3hzybyPCviXr/PoEELw= X-Received: by 2002:a6b:2055:: with SMTP id g82-v6mr3047533iog.204.1532642731035; Thu, 26 Jul 2018 15:05:31 -0700 (PDT) MIME-Version: 1.0 From: Christopher Wood Date: Thu, 26 Jul 2018 15:05:19 -0700 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] WG adoption call: draft-housley-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 22:05:34 -0000 The sense of the TLS@IETF102 room was that the WG should adopt draft-housley-tls-tls13-cert-with-extern-psk as a WG item. This email is to confirm this sense on list. If you would like for this draft to become a WG document and you are willing to review it as it moves through the process, then please let the list know by 2359UTC 20180809. If you are opposed to this being a WG document, please say so (and say why). Thanks, Chris, Joe and Sean From nobody Thu Jul 26 16:03:42 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 933DF131255 for ; Thu, 26 Jul 2018 16:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGvWxOP1fOGw for ; Thu, 26 Jul 2018 16:03:37 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003: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 948E813125B for ; Thu, 26 Jul 2018 16:03:37 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id v8-v6so5938509oie.5 for ; Thu, 26 Jul 2018 16:03:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AjxFksPwO/FqBoUYZc7HEDgAjvJNmpw0BTcex9CtGoE=; b=v+jUfr2smqMirx+Aq6eZd0rZBTM8vejMHnWnFbJ6rHvJ2HvezxWl5sAuXMrxlPAjip LXRH/omvP9a+zf5nvbAK8E7fy5N8XzsKsKOJhrm5TIAUDN1zbbsOwN3xD5gUPJsQxchz N47MHeoh+2CorQfmEVuNhh4SmoTOGg/Bv2148= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AjxFksPwO/FqBoUYZc7HEDgAjvJNmpw0BTcex9CtGoE=; b=Qt87t1pnUcKl1jmDEbadNl4wDcqIbuh9vo/qNy3vrO1QmIWG82D6/PFXFYP3AYypbj 1Yys71aoBQTs/x875x8pk75TaVH3CLQGgtj9LkiJIQVgnsO5nPFgIxnZfy00rowd49Ff ElBjVDKHnNMbdkwOTqNEi8CkK0BA+AAIJgedW4naj/7n+P9jzBzEGY72ftQ/wMryg1py tGB4wFDuwLsaVviOugds24NGStwAjny9YtyHsMwyQtmWcnAkl2TuXKEpe59Dv6rRnkw/ lqrnSo5X4hi7uHpoqhpvtHkl+KnlbyGyQ5V44PhsiAsBIjRROrGQ8UF2+lDvDJo3OOm1 /qJw== X-Gm-Message-State: AOUpUlEa4fE2JBGVfxgnRooYneC3SSPJiAcWYv4SV9EBwIifcxI2Ux3z tMAu4kAuwNeNLmDZB4XNHHQ/wQrOlCXCBCITwCtIqw== X-Google-Smtp-Source: AAOMgpd4Wde7ewuO/ogsy91OCW4NrDL+B//0IEKDkzKh4UzFoZA0yGhkt+iwPLjOwL+T5UYiJrF5MsTFG+UsoagbvK4= X-Received: by 2002:aca:dc55:: with SMTP id t82-v6mr4305695oig.159.1532646216797; Thu, 26 Jul 2018 16:03:36 -0700 (PDT) MIME-Version: 1.0 References: <20180724202423.GA28235@LK-Perkele-VII> In-Reply-To: From: Nick Sullivan Date: Thu, 26 Jul 2018 16:03:25 -0700 Message-ID: To: "Patton,Christopher J" Cc: "Blumenthal, Uri - 0553 - MITLL" , Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary="00000000000051a9f50571ef01f6" Archived-At: Subject: Re: [TLS] Proposals for draft-ietf-tls-subcerts-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 26 Jul 2018 23:03:41 -0000 --00000000000051a9f50571ef01f6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support these changes. Nick On Thu, Jul 26, 2018 at 11:01 AM Patton,Christopher J wrote: > Thanks all for the feedback! In light of your observations, we've revised > the changes proposed for draft-02: > https://github.com/tlswg/tls-subcerts/pull/13. > > > The changes for draft-02 are as follows: > > > > > - Drop support for TLS 1.2. > - Add the protocol version and credential signature algorithm to the > Credential structure. > > > - Specify undefined behavior in a few cases: when the client receives > a DC without indicated support; when the client indicates the extensio= n in > an invalid protocol version; and when DCs are sent as extensions to > certificates other than the end-entity certificate. > > > Any additional feedback is welcome. > > > Thanks, > > Christopher Patton > > > ------------------------------ > *From:* Blumenthal, Uri - 0553 - MITLL > *Sent:* Tuesday, July 24, 2018 4:40 PM > *To:* Ilari Liusvaara; Patton,Christopher J > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Proposals for draft-ietf-tls-subcerts-02 > > I object to re-interpreting/overloading the Critical flag. It has one and > only one meaning: "If the parser does not understand the given attribute, > it must abort parsing if this attribute is marked as Critical (or ignore > this attribute and continue parsing if the Critical flag is not set)". > > > =EF=BB=BFOn 7/24/18, 16:25, "TLS on behalf of Ilari Liusvaara" < > tls-bounces@ietf.org on behalf of ilariliusvaara@welho.com> wrote: > > On Tue, Jul 24, 2018 at 07:24:09PM +0000, Patton,Christopher J wrote: > > Hi all, > > > > > > I've taken the liberty of addressing the changes to the delegated > credentials extension that were requested at IETF: > > > > https://github.com/tlswg/tls-subcerts/pull/13 > > > > > > > The changes that would be adopted in draft-02 are as follows: > > > > * Drop support for TLS 1.2. > > * Allow the critical bit of the X.509 extension to be set. > > * Add the protocol version and credential signature algorithm > > to the Credential structure. > > * Make the KeyUsage of the delegation certificate stricter. > > * Specify undefined behavior in a few cases. > > > > It was suggested that we add optional "must-use-DC" semantics to th= e > > certificate. The solution we came up with was to add a "strict" fla= g > > to the extension that is set if (and only if) the extension is mark= ed > > critical. The idea is that if the "strict" flag is set and the serv= er > > doesn't offer a DC, then client must abort the handshake, In my > opinion, > > the complexity this adds to the protocol outweighs the potential > benefits. > > > > Comments on the PR are welcome. > > This has the signifcant critical flag issue. It should at minimum be > explicitly called out, as I do not know any precendent for this kind = of > behavior (check that some extension is critical yes, but not changing > meaning of extension depending on critical flag). > > > I watched the presentation and the resulting Q&A again. Short summary > of > relevant stuff: > > - The motivation in the slides is to reduce exposure of private keys = to > memory disclosure vulernabilities, without reducing performance. > - The orignal proposal was to add a TLS Feature extension value. No > discussion. > - The drawback of "strict mode" would be causing issues with servers > that can not effectively switch between certificates. > - There is question about fallback. Paraphrased answer: LURK. > > > TLS Feature extensions have some really unwnated properties here. The= y > are never critical on client side, and they have OR-inheritance. You > definitely do not want OR-inheritance here. > > Well, after this, the best usecase I can come up with strict flag is > still dealing with LURK endpoints that can not do proof-of-possession > or format checking[1]. > > > [1] TLS 1.2 and 1.3 servers should only ask for signatures and only > over the following kinds of data: > > - <64 bytes> 03 00 17 41 04 <64 bytes> > - <64 bytes> 03 00 18 61 04 <96 bytes> > - <64 bytes> 03 00 19 85 04 <132 bytes> (rare, P-521) > - <64 bytes> 03 00 1A 41 04 <64 bytes> (rare, brainpool) > - <64 bytes> 03 00 1B 61 04 <96 bytes> (rare, brainpool) > - <64 bytes> 03 00 1C 81 04 <128 bytes> (rare, brainpool) > - <64 bytes> 03 00 1D 20 <32 bytes> > - <64 bytes> 03 00 1E 38 <56 bytes> (rare, X448) > - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <32 bytes> > - <64 spaces> "TLS 1.3, server CertificateVerify" 00 <48 bytes> > > None of these covers delegated credential signatures, which would > cause any attempt to ask for DC signature to fail if the format is > checked.. > > > > -Ilari > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --00000000000051a9f50571ef01f6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support these changes.

Nick

Thanks all for the feedback! In l= ight of your observations, we've revised the changes proposed for=C2=A0= draft-02:=C2=A0https://github.com/tlswg/tls-subcerts/pull/13.=


The changes for draft-02 are as f= ollows:

    • Dr= op support for TLS 1.2.
    • Add the protocol version and credential signature algorithm to the Crede= ntial structure.
    • Specify undefined be= havior in a few cases: when the client receives a DC without indicated supp= ort; when the client indicates the extension in an invalid protocol version; and when DCs are sent as extensions to certifica= tes other than the end-entity certificate.

    Any additional feedback is welcom= e.


    Th= anks,

    Christopher Patton



    From:= Blumenthal, Uri - 0553 - MITLL <uri@ll.mit.edu>
    Sent: Tuesday, July 24, 2018 4:40 PM
    To: Ilari Liusvaara; Patton,Christopher J
    Cc: tls@ietf.org
    Subject: Re: [TLS] Proposals for draft-ietf-tls-subcerts-02
    =C2=A0
    I object to re-interpreting/= overloading the Critical flag. It has one and only one meaning: "If th= e parser does not understand the given attribute, it must abort parsing if = this attribute is marked as Critical (or ignore this attribute and continue parsing if the Critical flag is not set)".


    =EF=BB=BFOn 7/24/18, 16:25, "TLS on behalf of Ilari Liusvaara" &l= t;    tls-bounces@iet= f.org on behalf of ilariliusvaara@welho.com> wrote:

    =C2=A0=C2=A0=C2=A0 On Tue, Jul 24, 2018 at 07:24:09PM +0000, Patton,Christo= pher J wrote:
    =C2=A0=C2=A0=C2=A0 > Hi all,
    =C2=A0=C2=A0=C2=A0 >
    =C2=A0=C2=A0=C2=A0 >
    =C2=A0=C2=A0=C2=A0 > I've taken the liberty of addressing the change= s to the delegated credentials extension that were requested at IETF:
    =C2=A0=C2=A0=C2=A0 >
    =C2=A0=C2=A0=C2=A0 > https://github.com/tlswg/tls-subcerts/pull/13

    =C2=A0=C2=A0=C2=A0 >
    =C2=A0=C2=A0=C2=A0 >
    =C2=A0=C2=A0=C2=A0 > The changes that would be adopted in draft-02 are a= s follows:
    =C2=A0=C2=A0=C2=A0 >
    =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0 *=C2=A0=C2=A0 Drop support for TLS 1.2.=
    =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0 *=C2=A0=C2=A0 Allow the critical bit of= the X.509 extension to be set.
    =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0 *=C2=A0=C2=A0 Add the protocol version = and credential signature algorithm
    =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 to the Credenti= al structure.
    =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0 *=C2=A0=C2=A0 Make the KeyUsage of the = delegation certificate stricter.
    =C2=A0=C2=A0=C2=A0 >=C2=A0=C2=A0 *=C2=A0=C2=A0 Specify undefined behavio= r in a few cases.
    =C2=A0=C2=A0=C2=A0 >
    =C2=A0=C2=A0=C2=A0 > It was suggested that we add optional "must-us= e-DC" semantics to the
    =C2=A0=C2=A0=C2=A0 > certificate. The solution we came up with was to ad= d a "strict" flag
    =C2=A0=C2=A0=C2=A0 > to the extension that is set if (and only if) the e= xtension is marked
    =C2=A0=C2=A0=C2=A0 > critical. The idea is that if the "strict"= ; flag is set and the server
    =C2=A0=C2=A0=C2=A0 > doesn't offer a DC, then client must abort the = handshake, In my opinion,
    =C2=A0=C2=A0=C2=A0 > the complexity this adds to the protocol outweighs = the potential benefits.
    =C2=A0=C2=A0=C2=A0 >
    =C2=A0=C2=A0=C2=A0 > Comments on the PR are welcome.
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 This has the signifcant critical flag issue. It should a= t minimum be
    =C2=A0=C2=A0=C2=A0 explicitly called out, as I do not know any precendent f= or this kind of
    =C2=A0=C2=A0=C2=A0 behavior (check that some extension is critical yes, but= not changing
    =C2=A0=C2=A0=C2=A0 meaning of extension depending on critical flag).
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 I watched the presentation and the resulting Q&A aga= in. Short summary of
    =C2=A0=C2=A0=C2=A0 relevant stuff:
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 - The motivation in the slides is to reduce exposure of = private keys to
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 memory disclosure vulernabilities, without r= educing performance.
    =C2=A0=C2=A0=C2=A0 - The orignal proposal was to add a TLS Feature extensio= n value. No
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 discussion.
    =C2=A0=C2=A0=C2=A0 - The drawback of "strict mode" would be causi= ng issues with servers
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 that can not effectively switch between cert= ificates.
    =C2=A0=C2=A0=C2=A0 - There is question about fallback. Paraphrased answer: = LURK.
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 TLS Feature extensions have some really unwnated propert= ies here. They
    =C2=A0=C2=A0=C2=A0 are never critical on client side, and they have OR-inhe= ritance. You
    =C2=A0=C2=A0=C2=A0 definitely do not want OR-inheritance here.
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 Well, after this, the best usecase I can come up with st= rict flag is
    =C2=A0=C2=A0=C2=A0 still dealing with LURK endpoints that can not do proof-= of-possession
    =C2=A0=C2=A0=C2=A0 or format checking[1].
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 [1] TLS 1.2 and 1.3 servers should only ask for signatur= es and only
    =C2=A0=C2=A0=C2=A0 over the following kinds of data:
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 - <64 bytes> 03 00 17 41 04 <64 bytes>
    =C2=A0=C2=A0=C2=A0 - <64 bytes> 03 00 18 61 04 <96 bytes>
    =C2=A0=C2=A0=C2=A0 - <64 bytes> 03 00 19 85 04 <132 bytes> (rar= e, P-521)
    =C2=A0=C2=A0=C2=A0 - <64 bytes> 03 00 1A 41 04 <64 bytes> (rare= , brainpool)
    =C2=A0=C2=A0=C2=A0 - <64 bytes> 03 00 1B 61 04 <96 bytes> (rare= , brainpool)
    =C2=A0=C2=A0=C2=A0 - <64 bytes> 03 00 1C 81 04 <128 bytes> (rar= e, brainpool)
    =C2=A0=C2=A0=C2=A0 - <64 bytes> 03 00 1D 20 <32 bytes>
    =C2=A0=C2=A0=C2=A0 - <64 bytes> 03 00 1E 38 <56 bytes> (rare, X= 448)
    =C2=A0=C2=A0=C2=A0 - <64 spaces> "TLS 1.3, server CertificateVer= ify" 00 <32 bytes>
    =C2=A0=C2=A0=C2=A0 - <64 spaces> "TLS 1.3, server CertificateVer= ify" 00 <48 bytes>
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 None of these covers delegated credential signatures, wh= ich would
    =C2=A0=C2=A0=C2=A0 cause any attempt to ask for DC signature to fail if the= format is
    =C2=A0=C2=A0=C2=A0 checked..
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 -Ilari
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0
    =C2=A0=C2=A0=C2=A0 _______________________________________________
    =C2=A0=C2=A0=C2=A0 TLS mailing list
    =C2=A0=C2=A0=C2=A0 TLS@ie= tf.org
    =C2=A0=C2=A0=C2=A0 https://www.ietf.org/mailman/listinfo/tls
    =C2=A0=C2=A0=C2=A0
    _______________________________________________
    TLS mailing list
    TLS@ietf.org
    https://www.ietf.org/mailman/listinfo/tls
    --00000000000051a9f50571ef01f6-- From nobody Thu Jul 26 17:16:40 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4A7F131297 for ; Thu, 26 Jul 2018 17:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j6f7NH3xOhN8 for ; Thu, 26 Jul 2018 17:16:36 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003: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 B4E5F13129A for ; Thu, 26 Jul 2018 17:16:36 -0700 (PDT) Received: by mail-oi0-x22e.google.com with SMTP id b15-v6so6160199oib.10 for ; Thu, 26 Jul 2018 17:16:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=V/iH8XTmrv37zAjiMvGmKlqnyLcFX7YmrLDf30VA9Mw=; b=uEqniXvzMV2dlPVSM25J9OxDj8NJJd75ziLv2wyve6BzLDLl/GJHB3TT2CpqvC+xoh Z/4m6FGCWzXisg/UvvQ8RDQR5cD4y+TneforV3+QdSFObkEcgR3x4TmMCqqcsCGmw7bj zSJGYV31wtKy7CMP00FCpqaUCUgr87DofESYuLQAX/XSrUDS0W16AWPFoplOt+BrhCJD 7Gj5SE2mLt1Memh2MYlfm9IlDaKAz9NwM6LuCjKxIKuGirWbkkh2jE63F3VjZRMEiX44 Qc4qaypPoVzh55yXST3f0gI0glqM7YYQZ2XdGJTMvAKknrzTZhPLmIopCqY+ZijLf1f0 y33g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=V/iH8XTmrv37zAjiMvGmKlqnyLcFX7YmrLDf30VA9Mw=; b=ZJkz5VGFTxMwLXWFxv1Ov/4+jXnL+l4zrbmad/Eq2HmQHpJ/GpK/GEtEId9WMsmvQT FX/BVbxnLlp60aCkdmPXMbpEve4frBnk7gEIGhfuCkb8ehoDU7KBAJQ80r0/be0dwFqH 8x857giBfSmgjInqgwJAwOF59nitcuXK7SMXB4BhWq5o0bDDmDqcXslSO0OsLoxzISNF 9G3kXYwYwzl6sZUWZHrHqwHpipvitPnOlB6M4W1jHXpQo9JF2QaPJRAOP9tUXipAwHA7 PngII5lBb7Ljw/RUDjw6/EdVKDpVbjRQG/8DosPQYzyPNw6PGYm2grr0BKJh02+pLNEi 7ZsA== X-Gm-Message-State: AOUpUlFoebs2PPAAbvAjnX3QRPpB64e/+YluerMPgiP5fL4JR+38Q+5z 7q6jqU4thkvjz8OV/wb3PSl31k34oOPOuTijvpc= X-Google-Smtp-Source: AAOMgpfr0CdjAdVBnXyXrf1hV5t+WNLSgZZbh/TpU606/IFImgDDn1D5NWilE0OHUDkoN9fVqIOzCL9ZE1GhnqjUOGg= X-Received: by 2002:aca:3d56:: with SMTP id k83-v6mr4112454oia.166.1532650595995; Thu, 26 Jul 2018 17:16:35 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Fri, 27 Jul 2018 10:16:25 +1000 Message-ID: To: Christopher Wood Cc: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] WG adoption call: draft-housley-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 00:16:39 -0000 I think that we need a little more clarity on the goals before we talk about adoption for this. I'm sorry if that message wasn't clear at the meeting. On Fri, Jul 27, 2018 at 8:06 AM Christopher Wood wrote: > > The sense of the TLS@IETF102 room was that the WG should adopt > draft-housley-tls-tls13-cert-with-extern-psk as a WG item. This email > is to confirm this sense on list. If you would like for this draft to > become a WG document and you are willing to review it as it moves > through the process, then please let the list know by 2359UTC > 20180809. If you are opposed to this being a WG document, please say > so (and say why). > > Thanks, > Chris, Joe and Sean > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jul 26 18:03:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC6E130E33 for ; Thu, 26 Jul 2018 18:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvnxyydR8KiW for ; Thu, 26 Jul 2018 18:03:21 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E8D31274D0 for ; Thu, 26 Jul 2018 18:03:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id EA996300A46 for ; Thu, 26 Jul 2018 21:03:18 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 8wPnHRNQ_6ZH for ; Thu, 26 Jul 2018 21:03:17 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id A9A67300568; Thu, 26 Jul 2018 21:03:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: Date: Thu, 26 Jul 2018 21:03:18 -0400 Cc: Christopher Wood , IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] WG adoption call: draft-housley-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 01:03:23 -0000 My recollection is that we would do a call for adoption, and that would = lead to comments, and then I post an update. If the comments are = addressed adequately, then the update will be adopted, otherwise not. Russ > On Jul 26, 2018, at 8:16 PM, Martin Thomson = wrote: >=20 > I think that we need a little more clarity on the goals before we talk > about adoption for this. I'm sorry if that message wasn't clear at > the meeting. > On Fri, Jul 27, 2018 at 8:06 AM Christopher Wood > wrote: >>=20 >> The sense of the TLS@IETF102 room was that the WG should adopt >> draft-housley-tls-tls13-cert-with-extern-psk as a WG item. This email >> is to confirm this sense on list. If you would like for this draft to >> become a WG document and you are willing to review it as it moves >> through the process, then please let the list know by 2359UTC >> 20180809. If you are opposed to this being a WG document, please say >> so (and say why). >>=20 >> Thanks, >> Chris, Joe and Sean >>=20 >> _______________________________________________ >> 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 From nobody Fri Jul 27 00:20:02 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63278130DE2 for ; Fri, 27 Jul 2018 00:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tswg7X_-Ev2R for ; Fri, 27 Jul 2018 00:19:58 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADE6E130E3B for ; Fri, 27 Jul 2018 00:19:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id AD66820A20; Fri, 27 Jul 2018 10:19:54 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id 6j31J7F-tIUZ; Fri, 27 Jul 2018 10:19:54 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D2F6E28A; Fri, 27 Jul 2018 10:18:20 +0300 (EEST) Date: Fri, 27 Jul 2018 10:18:20 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: Benjamin Kaduk , "" Message-ID: <20180727071820.GA8452@LK-Perkele-VII> References: <20180719230009.GD14551@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 07:20:01 -0000 On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote: > Here’s a specific construction, but we’re flexible about the details: > > struct { > opaque base_identity<1...2^16-1>; > HashAlgorithm hash; > } imported_psk_identity; > > UPSKx = HKDF-Extract(0, UPSK) // UPSK is the input universal PSK > PSK = HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity), > TargetHash.length) // Might need to shorten label > > These functions would be executed with the KDF associated with the UPSK, > but produce > a key the size of the desired hash. Using HashAlgorithm here does not seem to be great. The problem being that HashAlgorithm is shadowed by SignatureScheme, which could make adding a new ciphersuite hash problematic, due to needing to add a new HashAlgorithm. -Ilari From nobody Fri Jul 27 02:07:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03CCE130DF2 for ; Fri, 27 Jul 2018 02:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CKEmMfRyT7yr for ; Fri, 27 Jul 2018 02:07:23 -0700 (PDT) Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0601712426A for ; Fri, 27 Jul 2018 02:07:23 -0700 (PDT) Received: by mail-wm0-f50.google.com with SMTP id h20-v6so4672481wmb.4 for ; Fri, 27 Jul 2018 02:07:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=J5BpsvFhaRapqOB1Io7rlkVth6zAcH8lL0zXhfxP6n0=; b=phVX+eDgMjMSPs5n7Z7+yfj0MsFl63EDY9xe/EteL+kzECfO0SmzhbXH8aVk+4seYl F2DqtKistldMVL6+4ztlUHzNydob3g16pccXN10dH8uipHaK3C8unZ7Rb0uRLfL3y5AT UmU9hE7ZHV3sALhLbWnENmQPNn8XqZ3NZ5HZCYXHR3o0YXOAX8sIsi0dUTIPuwydEXIU 34/VQQ4Vaf9U0UfIXUoytHkbHsw02k59hAsDhBnoYPNWTrQiaozNSGB6/BSAPIrep6Za WxytxDcRB4iNjzRmZRmV4sBjBdICZxhyRMdWOWDGDiyKlbSlh+/Rxsi6RSQonfCWEU76 5kTg== X-Gm-Message-State: AOUpUlH9qByj3yx+JFY/qe7wPnlxK5H4UF2VOmyEkgZep5bZALxXl6oF Jva69OZ0m1SS2Ifp+W33eo6oaA== X-Google-Smtp-Source: AAOMgpdPQk2/ST7LeaEMnRsYxFSAxYGiSPafy01TKCJfml9W8UkxL9BL6qt5ll5rT3D+HXYIgyDWBw== X-Received: by 2002:a1c:93d2:: with SMTP id v201-v6mr3622191wmd.77.1532682441422; Fri, 27 Jul 2018 02:07:21 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id h83-v6sm4792324wmf.46.2018.07.27.02.07.20 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Jul 2018 02:07:20 -0700 (PDT) Message-ID: <53da03a8ca05f4bb443bba1a2faeb46b750e7c2e.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Cc: "" Date: Fri, 27 Jul 2018 11:07:20 +0200 In-Reply-To: References: <20180719230009.GD14551@akamai.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.4 (3.28.4-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 09:07:25 -0000 On Thu, 2018-07-26 at 10:58 -0700, Eric Rescorla wrote: > Ben, > > Thanks for focusing on this issue. > > Chris and I have been discussing an alternative design which we think > is more consistent with the existing structure, which we call PSK > Importers. As with your design, we have an input universal PSK, but > instead of using explicitly as part of the connection, we just use it > as the base key to import a set of new PSKs into TLS. > > As with Universal PSKs (UPSKs), each input key is a triplet of > (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity > as used today. To use a UPSK, an implementation takes the set of KDF > hashes it knows about H_i and derives a set of PSKs: > > Hash_i: H_i > Identity_i: BaseIdentity || H_i > Key_i: Derived from BaseKey and Identity_i > > This gives you a set of keys which you can offer simultaneously on > the > TLS connection in independent psk_identity blocks. (Note that the > hash > algorithm is what differentiates each derived key.) This is a bit > ugly, but with the current TLS 1.3 ciphers, this basically just means > SHA-256, but even in the worst case it’s probably only 2-3. > > The nice thing about this design is that if you know the set of hash > functions, you can just compute all the imported PSKs in advance, and > there’s no need to touch the internals of the TLS stack. This also > means that if you have decided you don’t like old hash X, you don’t > need to use it to compute PSK binders, you just use it do the KDF, > which seems like it has weakersecurity requirements. > > Here’s a specific construction, but we’re flexible about the details: > > struct { > opaque base_identity<1...2^16-1>; > HashAlgorithm hash; > } imported_psk_identity; That looks nice, as it allows compatibility with existing psk implementations. One improvement could be to have a magic number, to allow easy disambiguation between an potential existing "raw" (non ascii username identity), and the new approach. struct { opaque magic[4]; // 0x544c0103 HashAlgorithm hash; opaque base_identity<1...2^16-1>; } imported_psk_identity; Such a field will also allow further future improvements to that approach if needed and allow for incompatible changes in draft versions as the magic serves as version number. regards, Nikos From nobody Fri Jul 27 02:13:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09145130E13 for ; Fri, 27 Jul 2018 02:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbjAYLEhrrQd for ; Fri, 27 Jul 2018 02:13:41 -0700 (PDT) Received: from mail-wr1-f41.google.com (mail-wr1-f41.google.com [209.85.221.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB9312F295 for ; Fri, 27 Jul 2018 02:13:41 -0700 (PDT) Received: by mail-wr1-f41.google.com with SMTP id b15-v6so4313087wrv.10 for ; Fri, 27 Jul 2018 02:13:41 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=hYrPiwfon9t0UpXgYFL1o7SUqHcvSC6Gmz7VZGDTfU0=; b=iiafpjqZhajgQFBaxQvUNug5Odk4VkMiTQ5Q7pXgvwMWGsnvhR1xqKJHjOkESjCjkS 0/ZaZHIAL5cyyIsJ8VasikYbDPZscWYdi3Y5L3oZggTI1NvxWoa7U//BxWmOO8SAq3gR grPFuTJ8pLtWTBXfZ0u9SpIRF5bwT1lk2ySQnbl4tE23NVYGvcR4tlJypsNXcFU7ypJ9 M/42vvpgfjPBaj+IPjLjNHjSnJSQqbhqfDu3yXsR6MYE0bRcK+YK/haY6NubOPWjc3BW gg559Omd/8sE2mqM4EV3jaWnTp3iKWGXnDJKbyc6XMfrARnI/bn/XsHRYnGzV/Ql0WxX Qjrg== X-Gm-Message-State: AOUpUlFO74v2rC8RE88bTKz9j18ZymJ1WV7VHF91qUjnLyCvrnVmFNnx 9w0zcrBpKEse4aN2mmZI81lQsAaWBUw= X-Google-Smtp-Source: AAOMgpej1Gq9dayjGcPGjI/p0r4nNlKsZgTy1Q+OE1kTXnKyco0rxyxyAJJ6cd1xxVzDOeB/ZlYrxg== X-Received: by 2002:adf:992d:: with SMTP id x42-v6mr3973983wrb.81.1532682819708; Fri, 27 Jul 2018 02:13:39 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id v5-v6sm2683252wru.60.2018.07.27.02.13.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Jul 2018 02:13:38 -0700 (PDT) Message-ID: From: Nikos Mavrogiannopoulos To: Christopher Wood , "" Date: Fri, 27 Jul 2018 11:13:38 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.4 (3.28.4-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] WG adoption call: draft-housley-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 09:13:43 -0000 On Thu, 2018-07-26 at 15:05 -0700, Christopher Wood wrote: > The sense of the TLS@IETF102 room was that the WG should adopt > draft-housley-tls-tls13-cert-with-extern-psk as a WG item. This email > is to confirm this sense on list. If you would like for this draft to > become a WG document and you are willing to review it as it moves > through the process, then please let the list know by 2359UTC > 20180809. If you are opposed to this being a WG document, please say > so (and say why). Would it make sense to communicate the reasons of adopting this document by the WG? From nobody Fri Jul 27 02:23:25 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60CCE130E14 for ; Fri, 27 Jul 2018 02:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ikhN-j8n-sq for ; Fri, 27 Jul 2018 02:23:20 -0700 (PDT) Received: from mail-wr1-f48.google.com (mail-wr1-f48.google.com [209.85.221.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEFE130DF2 for ; Fri, 27 Jul 2018 02:23:20 -0700 (PDT) Received: by mail-wr1-f48.google.com with SMTP id h9-v6so4372581wro.3 for ; Fri, 27 Jul 2018 02:23:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=7txWMCjdAzrf+gClU9El9p9Uz3qdDZ9jI2V2z/83Yd0=; b=hppA55mYhpyWWTqNkIsKB7urWyfqrpdgHOcJ+1rRDqQ+Mfjsb0CtznEbdGbCw1rau0 glQlVE8DYfofwPrEpycUbe4fkwmf07LAiqM0HY6JbJtsGpALf68m5rF1myF5nTXc+PNw 7tDLJFwpx5DcO3a1MJfRS1+DN4yT95VLMrFYBbyckZ18J1I7R1u99ADi3rrmB/b4y+M1 AVzmxLNttx0wQehlh0xJ00EibQGDteh/fyOhyvrn/xJvcowRWXzhSMgey33Q3YbhJmfB 86Y3rW0ugI9XDYB8Qs1wpizB8WUGvLCZw375AfM22T/cw2LHPcbq8/8OyCWdvLkXcTR4 nRHg== X-Gm-Message-State: AOUpUlEO/f99CNCcnBjhjQq/QolwpJdXfFYBS8HPcFjVzJH66uouMrCv d970ENwxD9uye5TknA7THcDj26Rpvks= X-Google-Smtp-Source: AAOMgpfgRvTaV/OjYXpHBKeznT2h4+l72rm9m5FWBPF8dD2z8fS/83/XSMJL/PqdZaOf6hKB20R2LQ== X-Received: by 2002:a5d:4e49:: with SMTP id r9-v6mr3927078wrt.27.1532683399096; Fri, 27 Jul 2018 02:23:19 -0700 (PDT) Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id w204-v6sm4408491wmw.5.2018.07.27.02.23.18 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Jul 2018 02:23:18 -0700 (PDT) Message-ID: <98fd53a18dc6b06ecd750201239721e8f88d5e7e.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Russ Housley Cc: IETF TLS Date: Fri, 27 Jul 2018 11:23:17 +0200 In-Reply-To: References: <797D67EC-9390-47CD-BD6A-75E34E5FE33F@vigilsec.com> <1524474119.4793.7.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.28.4 (3.28.4-1.fc28) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 09:23:24 -0000 On Mon, 2018-04-23 at 15:30 -0400, Russ Housley wrote: > > > > In the presentation the main driver for it seems to be quantum > > computer > > resistance as temporary measure. If that's the main argument I > > don't > > think it is really significant. PSK can hardly be used with PKI, > > and as > > a matter of fact we use PKI because of PSK key distribution > > problems. > > If we switch to PSK for quantum computer resistance there is there > > a > > reason to use PKI? Probably no (I may be wrong here, if there is a > > reason for a hubrid model I'm missing, I'd be glad to know). > > I am not advocating for a pairwise PSK between every client and > server. If that were available to us, then as you say, we would > always use the PSK without any PKI. > > I envision a PSK being distributed to a group of clients and group of > severs. At some point in the future a large-scale quantum computer > might get invented, and if any member of the group has access to it, > then they can recover the traffic. However, parties outside the > group cannot recover the traffic because the large-scale quantum > computer does not assist with the discovery of the PSK. [going back to this thread, as I have missed that reply and only saw it after the request for adoption was made] It certainly makes sense. > > I could see the main driver for such proposal the replacement of > > the > > RSA-PSK ciphersuites. I know they have _some_ adoption, but I'm not > > sure whether that is significant to require update to TLS1.3. > > This is not my goal. > > > On the implementation side, why not use post-handshake > > authentication > > here? I.e., extend it to be usable from client-side, and on a PSK > > key > > exchange, have the client request server authentication after the > > handshake? > > I'm not sure why that is easier to implement. Can you say more? Current TLS1.3 implementations can do a PSK key exchange and authenticate the client's certificate with post-handshake auth. Based on that, what you'd need to make that authentication two-way (both server and client use cert) is the ability for client to ask the server for certificate. As PHA is fairly simple (server sends a certificate request to client if the PHA extension is seen), doing the opposite if another extension is seen, seems trivial (the bits and pieces are already there). regards, Nikos From nobody Fri Jul 27 05:01:43 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643D8129C6A for ; Fri, 27 Jul 2018 05:01:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uatfiES9Yta for ; Fri, 27 Jul 2018 05:01:34 -0700 (PDT) Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879E5126F72 for ; Fri, 27 Jul 2018 05:01:34 -0700 (PDT) Received: by mail-lf1-x134.google.com with SMTP id y200-v6so3354450lfd.7 for ; Fri, 27 Jul 2018 05:01:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RhmhIxi9vCzZLpIVBpQui+Kd7C+5vkTe9oM0JsyiLW8=; b=MkC3ygHjvygaAAmEG11W/Otzbw5EntgoXk0RHf9SpA7y09wEXA5Pj9k4oAn1YvLLi0 7TsY3KlvlHxVFG9JzeQxoS5s8iC9OFJdHeNRKhzCqPZGfWngU4R0UwwM2XGI2hKCEFTe hG+D9iDphZNjjEMfS+TFQK2b5YTYTBRlfKroCgP3d6QaoSS7IDYM+EB6SE5+R5pHwsdG p0NjubpWMolC5T+M5Pu5T7TkX+XBFQ0SbDc2MuwUXlvD1G2b96q/pmGmqSwjqD6bwG+m Pj7Gn09NzYl7xkI6AmWIYf/QirbeE4bh8zK6MHiCBReRLUApfPFJhED6aITeZ6VGS1Zn 44yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RhmhIxi9vCzZLpIVBpQui+Kd7C+5vkTe9oM0JsyiLW8=; b=dtAeCqbDJ0J2W0DZs+Ne2Jk1IicmGbo4TVPDWlwUrli3hqw/KWzySXEg/bUTvLUt8K PktcEtvRosv5K22NKaFjr2xr3DS5620AyC/Z0zEBaoHwxxVCCDsgDTq5FZub8Et8nOYT LgdxIRlzW2Niqxe09xcehHyMVnjJj1Nbv1j79OO5/igCMeI34M9BWCVWgx6OSVygAH3U 50aJ9fK9WXbzhM8D34DF1Cc46j4tsxyjaO3F6ORVqq+Ew/nPOF6t82kclUntFwIHGHMZ FPfQrGabHirOnbSMgqDeVfloMo5aOW1RHluu7QHC3D3acVzgQTtLcC+hjHW3D35P0VT3 1Lew== X-Gm-Message-State: AOUpUlHk8GHW05fHN3hBUiBGKEExinvUwvdYB59cZHWDWFpmtQW/Z/OW 1mnCuNxLaBAA53r6Q47OCsapx77WM8rvMBY//ZkR1MX+ X-Google-Smtp-Source: AAOMgpfTwoJlTJpoxKj6brc0rQRpsMIG0WIxkzRRDsO7GOTlJTudmy+LlCjzJSI0Yopn9tz57e8jEeZ9PDiJXLyesZw= X-Received: by 2002:a19:1ad1:: with SMTP id a200-v6mr3809971lfa.49.1532692892817; Fri, 27 Jul 2018 05:01:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 05:00:52 -0700 (PDT) In-Reply-To: <20180727071820.GA8452@LK-Perkele-VII> References: <20180719230009.GD14551@akamai.com> <20180727071820.GA8452@LK-Perkele-VII> From: Eric Rescorla Date: Fri, 27 Jul 2018 05:00:52 -0700 Message-ID: To: Ilari Liusvaara Cc: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary="0000000000006d35930571f9df27" Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 12:01:42 -0000 --0000000000006d35930571f9df27 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2018 at 12:18 AM, Ilari Liusvaara wrote: > On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote: > > > Here=E2=80=99s a specific construction, but we=E2=80=99re flexible abou= t the details: > > > > struct { > > opaque base_identity<1...2^16-1>; > > HashAlgorithm hash; > > } imported_psk_identity; > > > > UPSKx =3D HKDF-Extract(0, UPSK) // UPSK is the input universal PSK > > PSK =3D HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity= ), > > TargetHash.length) // Might need to shorten label > > > > These functions would be executed with the KDF associated with the UPSK= , > > but produce > > a key the size of the desired hash. > > Using HashAlgorithm here does not seem to be great. The problem being > that HashAlgorithm is shadowed by SignatureScheme, which could make > adding a new ciphersuite hash problematic, due to needing to add a > new HashAlgorithm. > That's a reasonable point. Do you have a proposed alternative? We don't require that you associate a cipher suite with the key unless you want to do 0-RTT. -Ekr > > -Ilari > --0000000000006d35930571f9df27 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Fri, Jul 27, 2018 at 12:18 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
    On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote:
    > Here=E2=80=99s a specific construction, but we= =E2=80=99re flexible about the details:
    >
    >=C2=A0 =C2=A0 struct {
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque base_identity<1...2^16-1>;
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0 HashAlgorithm hash;
    >=C2=A0 =C2=A0 } imported_psk_identity;
    >
    >=C2=A0 =C2=A0 UPSKx =3D HKDF-Extract(0, UPSK)=C2=A0 // UPSK is the inpu= t universal PSK
    >=C2=A0 =C2=A0 PSK =3D HKDF-Expand-Label(UPSKx, "derived psk",= BaseKDF(psk_identity),
    > TargetHash.length) // Might need to shorten label
    >
    > These functions would be executed with the KDF associated with the UPS= K,
    > but produce
    > a key the size of the desired hash.

    Using HashAlgorithm here does not seem to be great. The problem bein= g
    that HashAlgorithm is shadowed by SignatureScheme, which could make
    adding a new ciphersuite hash problematic, due to needing to add a
    new HashAlgorithm.

    That's a reasona= ble point. Do you have a proposed alternative? We don't require that yo= u associate a cipher suite with the key unless you want to do 0-RTT.

    -Ekr



    -Ilari

    --0000000000006d35930571f9df27-- From nobody Fri Jul 27 05:49:34 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08A03127598 for ; Fri, 27 Jul 2018 05:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zHEssEKIEx8X for ; Fri, 27 Jul 2018 05:49:29 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7BB71277D2 for ; Fri, 27 Jul 2018 05:49:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id A62A3A4A4F; Fri, 27 Jul 2018 15:49:26 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id sY96KS_y1dLq; Fri, 27 Jul 2018 15:49:26 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id D33B4294; Fri, 27 Jul 2018 15:49:22 +0300 (EEST) Date: Fri, 27 Jul 2018 15:49:22 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: Benjamin Kaduk , "" Message-ID: <20180727124922.GA11594@LK-Perkele-VII> References: <20180719230009.GD14551@akamai.com> <20180727071820.GA8452@LK-Perkele-VII> 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.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 12:49:32 -0000 On Fri, Jul 27, 2018 at 05:00:52AM -0700, Eric Rescorla wrote: > On Fri, Jul 27, 2018 at 12:18 AM, Ilari Liusvaara > wrote: > > > On Thu, Jul 26, 2018 at 10:58:05AM -0700, Eric Rescorla wrote: > > > > > Here’s a specific construction, but we’re flexible about the details: > > > > > > struct { > > > opaque base_identity<1...2^16-1>; > > > HashAlgorithm hash; > > > } imported_psk_identity; > > > > > > UPSKx = HKDF-Extract(0, UPSK) // UPSK is the input universal PSK > > > PSK = HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity), > > > TargetHash.length) // Might need to shorten label > > > > > > These functions would be executed with the KDF associated with the UPSK, > > > but produce > > > a key the size of the desired hash. > > > > Using HashAlgorithm here does not seem to be great. The problem being > > that HashAlgorithm is shadowed by SignatureScheme, which could make > > adding a new ciphersuite hash problematic, due to needing to add a > > new HashAlgorithm. > > > > That's a reasonable point. Do you have a proposed alternative? We don't > require that you associate a cipher suite with the key unless you want to > do 0-RTT. Well, one could do a new enumeration or pick a canonical ciphersuite for every hash. Both have maintenance concerns when a new hash is introduced. OTOH, using HashAlgorithm would not solve those (even if the thing had not gotten shadowed), since the new hash is likely not any of the current ones in HashAlgorithm enumeration (the only non- deprecated algorithm that is not in use as ciphersuite hash is SHA-512) The new enumeration would currently only need sha256 and sha384. For canonical, the first TLS 1.3 ciphersuites for those would be 1301 and 1302 (the first in all TLS would be 003B and 009D). As can be seen from, this, picking canonicals is a bit yucky. -Ilari From nobody Fri Jul 27 06:43:11 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3241130EC5 for ; Fri, 27 Jul 2018 06:43:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eFKclkT1IEnB for ; Fri, 27 Jul 2018 06:43:06 -0700 (PDT) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 374C8127598 for ; Fri, 27 Jul 2018 06:43:06 -0700 (PDT) Received: by mail-qk0-x22a.google.com with SMTP id z74-v6so3268417qkb.10 for ; Fri, 27 Jul 2018 06:43:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=/USKlVlxM7fzhmcGftio79IABy6hk9ZDrRYvGPvvARM=; b=K4qF86KDfkzfcBD3IHKy7uxYvsJJP3VuTSaLFRzzBCxU4W6qRI2orSCWT/LgvREzd4 Ffg6xfRQd2J25ByA41X3f5tKw1kZPcwt9sEgDSjKrRMsqQlL5oO2VfsKYAHz9juYkFKQ whPuvbG7wv5XHc/C4V8tgY0dmakKtHr9c7GS/kJZwohszbpN6Fm0Rwi6WOILxc0JbIJZ udldbCZGyKzp7EF2RTJURKi0DQQfBcl+HCJ7M9JsrqPS2fR3l/JHMq7teeIdEd6EX6Rb EXgGEkLzdzAaW+CK8ZWaH8qf19IaEzvjbdx/tsUG7Kj8vkeovCUPRfJIrXsF4egdriKY bgJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=/USKlVlxM7fzhmcGftio79IABy6hk9ZDrRYvGPvvARM=; b=AG6P3gqtvvJxoejKjW/IesKBCEDsHb4n6ZO9KXtmL1EiPOuTkoQVQj9AwJ1V9wksLG eCy25QwOL+XCq7oB2NAIVCno5TB92YCyCcpE31bmsA3k3eqRZhy9NlSMKSdQuGlmk1lw JVrptcUjPK7gmDK17Ah1a/jbVPMsJwKwfppGFfHatVg3F+bQiZYH736lWMA6P/xFr2cN asAeaDSxfW42JhSntkO0+ZYGSY8acwKep4yZtRn7ZuBZIv4hFBa/KksmEbxPYcgnEPaY j3D/9yKVsgc6wnriH0Dntn+UeynPQ2L/96iOzH35C9pjzxp1/eIFuaUh1jCnBi+JS6Ui B6Bw== X-Gm-Message-State: AOUpUlFTe8U9otl+Cu89ZMbxcSOgXMMs8Vm2p+KzAUTkSQz8JsKf0q5Q W7GM250ZfcaeaPcHyOzDYiuoTjud X-Google-Smtp-Source: AAOMgpdRpYNdt92HsEbK7zfD5RAk6zqkmQCyFjTmag8kqiZZRzaLJ74nZZtBNLct0Lz8Ty7ehi1Yjg== X-Received: by 2002:a37:86:: with SMTP id t6-v6mr5835587qkg.443.1532698985138; Fri, 27 Jul 2018 06:43:05 -0700 (PDT) Received: from [192.168.1.28] ([71.181.119.27]) by smtp.gmail.com with ESMTPSA id v41-v6sm3117575qtk.70.2018.07.27.06.43.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 27 Jul 2018 06:43:04 -0700 (PDT) From: Karthikeyan Bhargavan Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2B595C65-118E-4432-ABA9-F8FB593B2143" Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Fri, 27 Jul 2018 09:43:03 -0400 In-Reply-To: Cc: Benjamin Kaduk , "" To: Eric Rescorla References: <20180719230009.GD14551@akamai.com> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 13:43:10 -0000 --Apple-Mail=_2B595C65-118E-4432-ABA9-F8FB593B2143 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > As with Universal PSKs (UPSKs), each input key is a triplet of > (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity > as used today. To use a UPSK, an implementation takes the set of KDF > hashes it knows about H_i and derives a set of PSKs To be clear, you=E2=80=99re suggesting that the KDF attached to an = input key could be different from the KDF used within TLS 1.3 itself. E.g. the KDF here could use HKDF-SHA256 whereas H_i and the hash = function in the TLS 1.3 cipher suite could be SHA-384 or whatever, is = that correct? The nice feature of this imported PSK is that it is then completely = outside the model of TLS, its just a way of provisioning multiple = independent TLS PSKs, where each TLS PSK can presumably only be used = with one hash algorithm (and one protocol version?) If so, this should compose nicely with existing TLS proofs. -Karthik >=20 > Hash_i: H_i > Identity_i: BaseIdentity || H_i > Key_i: Derived from BaseKey and Identity_i >=20 > This gives you a set of keys which you can offer simultaneously on the > TLS connection in independent psk_identity blocks. (Note that the hash > algorithm is what differentiates each derived key.) This is a bit > ugly, but with the current TLS 1.3 ciphers, this basically just means > SHA-256, but even in the worst case it=E2=80=99s probably only 2-3. >=20 > The nice thing about this design is that if you know the set of hash > functions, you can just compute all the imported PSKs in advance, and > there=E2=80=99s no need to touch the internals of the TLS stack. This = also > means that if you have decided you don=E2=80=99t like old hash X, you = don=E2=80=99t > need to use it to compute PSK binders, you just use it do the KDF, > which seems like it has weakersecurity requirements.=20 >=20 > Here=E2=80=99s a specific construction, but we=E2=80=99re flexible = about the details: >=20 > struct { > opaque base_identity<1...2^16-1>; > HashAlgorithm hash; > } imported_psk_identity; >=20 > UPSKx =3D HKDF-Extract(0, UPSK) // UPSK is the input universal PSK > PSK =3D HKDF-Expand-Label(UPSKx, "derived psk", = BaseKDF(psk_identity), TargetHash.length) // Might need to shorten label >=20 > These functions would be executed with the KDF associated with the = UPSK, but produce > a key the size of the desired hash. >=20 > This brings us to the question of TLS 1.2. I found Ilari=E2=80=99s = analyis > pretty persuasive, so I would suggest we add the following text to the > TLS 1.3 spec: >=20 > TLS 1.3 takes a conservative approach to PSKs by binding them to a > specific KDF. TLS 1.2 allows PSKs to be used with any hash = function > and the TLS 1.2 PRF. The constructions in TLS 1.2 and TLS 1.3, > although both based on HMAC, are very different and there is no = known > way in which reuse of the same PSK in TLS 1.3 and TLS 1.2 would > produce related output, although only limited formal analysis has = been > done. Implementations MAY wish to avoid reuse of keys between TLS = 1.3 > and TLS 1.2, or use a key derivation proposal such as [Informative = ref > to this email or a draft]. >=20 > Other than this, we wouldn=E2=80=99t make any changes to the document. >=20 > What do people think? >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 > On Thu, Jul 19, 2018 at 4:00 PM, Benjamin Kaduk = > wrote: > Hi all, >=20 > As I mentioned at the mic today, there is a question that has been > raised about whether it's wise to reuse an existing (TLS 1.2) PSK > directly in the TLS 1.3 key ladder. At a high level, the reason why = one > might want to restrict this is that the security proofs for TLS 1.3 = rely > on the pre-shared key being only used with a single key-derivation > function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different > key-derivation function, so formally the proofs do not hold. We don't > currently know of a specifc attack against such reuse, of course, but > perhaps it is prudent to restrict our usage to adhere to the verified > scenarios. >=20 > This is somewhat timely, as if we do want to introduce a restriction, = it > would ideally be in the form of some text in the TLS 1.3 = specification, > which is very nearly done. >=20 > It would be good to hear more opinions on this question, particularly > from those who have worked on the formal verification directly. >=20 > If I can attempt to summarize some discussion that occurred in the mic > line today, Hannes was surprised that we would care, likening this = case > to the regular version negotiation, where we are happy to use the same > certificate to sign messages for both TLS 1.2 and 1.3. David Benjamin > points out that we explicitly go to the trouble of putting 64 bytes of > 0x20 padding at the front of the content that gets signed for > CertificateVerify, to enforce separation between the TLS versions. >=20 > My own personal opinion is that we should enforce a domain separation > between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal = PSKs" > proposal seems like a potential mechanism by which to do so without > doubling the provisioning needs. >=20 > -Ben (with no hat) >=20 > _______________________________________________ > 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=_2B595C65-118E-4432-ABA9-F8FB593B2143 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
    As with Universal PSKs (UPSKs), each input key is = a triplet of
    (BaseIdentity, BaseKey, KDF), where a = BaseIdentity is a PSK identity
    as used today. To use a = UPSK, an implementation takes the set of KDF
    hashes it = knows about H_i and derives a set of PSKs

    To be = clear, you=E2=80=99re suggesting that the KDF  attached to an input = key could be different from the KDF used within TLS 1.3 = itself.
    E.g. the KDF here could use HKDF-SHA256 whereas H_i = and the hash function in the TLS 1.3 cipher suite could be SHA-384 or = whatever, is that correct?

    The nice = feature of this imported PSK is that it is then completely outside the = model of TLS, its just a way of provisioning multiple independent TLS = PSKs, where each TLS PSK can presumably only be used with one hash = algorithm (and one protocol version?)
    If so, this should = compose nicely with existing TLS proofs.

    -Karthik





      Hash_i: H_i
      Identity_i: = BaseIdentity || H_i
      Key_i: Derived from BaseKey and = Identity_i

    This gives you a set of keys = which you can offer simultaneously on the
    TLS connection = in independent psk_identity blocks. (Note that the hash
    algorithm is what differentiates each derived key.) This is a = bit
    ugly, but with the current TLS 1.3 ciphers, this = basically just means
    SHA-256, but even in the worst case = it=E2=80=99s probably only 2-3.

    The nice = thing about this design is that if you know the set of hash
    functions, you can just compute all the imported PSKs in = advance, and
    there=E2=80=99s no need to touch the = internals of the TLS stack. This also
    means that if you = have decided you don=E2=80=99t like old hash X, you don=E2=80=99t
    need to use it to compute PSK binders, you just use it do the = KDF,
    which seems like it has weakersecurity requirements. =

    Here=E2=80=99s a specific construction, = but we=E2=80=99re flexible about the details:

       struct {
           opaque = base_identity<1...2^16-1>;
           HashAlgorithm hash;
       } imported_psk_identity;

       UPSKx =3D HKDF-Extract(0, UPSK)  // UPSK is = the input universal PSK
       PSK =3D= HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity), = TargetHash.length) // Might need to shorten label
    These functions would be executed with = the KDF associated with the UPSK, but produce
    a key = the size of the desired hash.

    This = brings us to the question of TLS 1.2. I found Ilari=E2=80=99s analyis
    pretty persuasive, so I would suggest we add the following = text to the
    TLS 1.3 spec:

        TLS 1.3 takes a conservative approach to = PSKs by binding them to a
        specific KDF. = TLS 1.2 allows PSKs to be used with any hash function
        and the TLS 1.2 PRF. The constructions in = TLS 1.2 and TLS 1.3,
        although both = based on HMAC, are very different and there is no known
        way in which reuse of the same PSK in TLS = 1.3 and TLS 1.2 would
        produce related = output, although only limited formal analysis has been
        done. Implementations MAY wish to avoid = reuse of keys between TLS 1.3
        and TLS = 1.2, or use a key derivation proposal such as [Informative ref
        to this email or a draft].
    Other than this, we wouldn=E2=80=99t make any changes to the = document.

    What do people think?

    -Ekr





    On Thu, Jul 19, 2018 at 4:00 PM, = Benjamin Kaduk <bkaduk=3D40akamai.com@dmarc.ietf.org> wrote:
    Hi all,

    As I mentioned at the mic today, there is a question that has been
    raised about whether it's wise to reuse an existing (TLS 1.2) PSK
    directly in the TLS 1.3 key ladder.  At a high level, the reason = why one
    might want to restrict this is that the security proofs for TLS 1.3 = rely
    on the pre-shared key being only used with a single key-derivation
    function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different
    key-derivation function, so formally the proofs do not hold.  We = don't
    currently know of a specifc attack against such reuse, of course, but
    perhaps it is prudent to restrict our usage to adhere to the verified
    scenarios.

    This is somewhat timely, as if we do want to introduce a restriction, = it
    would ideally be in the form of some text in the TLS 1.3 = specification,
    which is very nearly done.

    It would be good to hear more opinions on this question, particularly
    from those who have worked on the formal verification directly.

    If I can attempt to summarize some discussion that occurred in the = mic
    line today, Hannes was surprised that we would care, likening this = case
    to the regular version negotiation, where we are happy to use the = same
    certificate to sign messages for both TLS 1.2 and 1.3.  David = Benjamin
    points out that we explicitly go to the trouble of putting 64 bytes = of
    0x20 padding at the front of the content that gets signed for
    CertificateVerify, to enforce separation between the TLS versions.

    My own personal opinion is that we should enforce a domain separation
    between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal = PSKs"
    proposal seems like a potential mechanism by which to do so without
    doubling the provisioning needs.

    -Ben (with no hat)

    _______________________________________________
    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=_2B595C65-118E-4432-ABA9-F8FB593B2143-- From nobody Fri Jul 27 08:50:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 885C5130F8D for ; Fri, 27 Jul 2018 08:50:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nI8TQixSDwRe for ; Fri, 27 Jul 2018 08:50:20 -0700 (PDT) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::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 5B7AA130F97 for ; Fri, 27 Jul 2018 08:50:19 -0700 (PDT) Received: by mail-lj1-x235.google.com with SMTP id v9-v6so4831049ljk.4 for ; Fri, 27 Jul 2018 08:50:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H4i23eL11Wzz+iBgPQyu3x5JEapPA5yM44a1G1X3S4A=; b=keLUAp5b1cYzdZrWEAS5jUTc35H6yj5xbX++AhNp3A2956u0Bh8HEQByGXzphhiPbQ 5J5ayFu94us5vWh7zKfabfpFcFHCyDnJHbVUg8sPFJiQDFjx/mJfvPAu5BUBZAFVa2nr u7YihYDY6uoxjRLeEEy20LJAWaiRyFAetG8XbDsq13fHy9ZaZL08spR2iErqzngJFcP0 4zxkfdz26vny2qpIeIa8gLS/BNXashXA/n20XFWzgWq9Lha51NQk08Ket3Eo4fYN1d0y pldnLyLEmUsrc3p4r1LnUIWIgQLSAVNVuSM2EWBn/eyorjq6QtyXDGlFsz+SG7FmiwFQ vYAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H4i23eL11Wzz+iBgPQyu3x5JEapPA5yM44a1G1X3S4A=; b=DTyGw2TOYW9I87vZCmZHVkfLVBztEperJDSQbdcAzCOxiDO6wlWCWR4cmGRXBbtGxz n+W2F8DxgsIxKHp3Tu0x7BwdJO4ox3YN9YjxoYUEysU1lXREyh+MXHmAZce1fEjSVT8w JBkemeEDFCbwFnfMeAuyJDBGM1O4yTQSxFS01fO1fxb0x49EjFUA2FPXtmXxl3/DUTHR JsREkB8t8pMs3cGYh322hVJ8J0tfFaJG5sPX6ythGmqr8OOLlNGDmO45uidMjzRs4byL 11Tn0DiZsPzgjw480/HPkr+rVwI7Wg7wJEDapqM1KDnkdgtqVKEbBihBwMvYfI+r+CvZ PVvQ== X-Gm-Message-State: AOUpUlFiijFPwGP8Ra+cb+DMAnJDZbFufPZl7goNEkF+FcATu36vKN5E b7nyGwktBm6LrsxaoJKTIpQYETVkeTnZZwRUjBelhQ== X-Google-Smtp-Source: AAOMgpfbRkjD8TJIJ/pnN8gNODx86iey1mNHqfWPoYWs8RARtZwMMjoEyAfHJWclnWy/bK73h7geNpF1PvxxKswyPfo= X-Received: by 2002:a2e:2096:: with SMTP id g22-v6mr5230068lji.37.1532706617649; Fri, 27 Jul 2018 08:50:17 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 08:49:36 -0700 (PDT) In-Reply-To: References: <20180719230009.GD14551@akamai.com> From: Eric Rescorla Date: Fri, 27 Jul 2018 08:49:36 -0700 Message-ID: To: Karthikeyan Bhargavan Cc: Benjamin Kaduk , "" Content-Type: multipart/alternative; boundary="0000000000007d7e6c0571fd1101" Archived-At: Subject: Re: [TLS] on sharing PSKs between TLS 1.2 and TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 15:50:25 -0000 --0000000000007d7e6c0571fd1101 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Jul 27, 2018 at 6:43 AM, Karthikeyan Bhargavan < karthik.bhargavan@gmail.com> wrote: > > As with Universal PSKs (UPSKs), each input key is a triplet of > (BaseIdentity, BaseKey, KDF), where a BaseIdentity is a PSK identity > as used today. To use a UPSK, an implementation takes the set of KDF > hashes it knows about H_i and derives a set of PSKs > > > To be clear, you=E2=80=99re suggesting that the KDF attached to an input= key > could be different from the KDF used within TLS 1.3 itself. > E.g. the KDF here could use HKDF-SHA256 whereas H_i and the hash function > in the TLS 1.3 cipher suite could be SHA-384 or whatever, is that correct= ? > Precisely. In fact, the KDF associated with the UPSK could be some KDF that TLS doesn't even specify (e.g., a SHA-3 based construction). > The nice feature of this imported PSK is that it is then completely > outside the model of TLS, its just a way of provisioning multiple > independent TLS PSKs, where each TLS PSK can presumably only be used with > one hash algorithm > Yes. (and one protocol version?) > This is less clear. We'd obviously prefer to allow TLS 1.3 PSKs to be used with TLS 1.4 if possible (this would require the binders to be compatible). But we can figure that out if we do 1.4. If so, this should compose nicely with existing TLS proofs. > Good news! Do you have any comments on my proposed disclaimer text? -Ekr > -Karthik > > > > > > Hash_i: H_i > Identity_i: BaseIdentity || H_i > Key_i: Derived from BaseKey and Identity_i > > This gives you a set of keys which you can offer simultaneously on the > TLS connection in independent psk_identity blocks. (Note that the hash > algorithm is what differentiates each derived key.) This is a bit > ugly, but with the current TLS 1.3 ciphers, this basically just means > SHA-256, but even in the worst case it=E2=80=99s probably only 2-3. > > The nice thing about this design is that if you know the set of hash > functions, you can just compute all the imported PSKs in advance, and > there=E2=80=99s no need to touch the internals of the TLS stack. This als= o > means that if you have decided you don=E2=80=99t like old hash X, you don= =E2=80=99t > need to use it to compute PSK binders, you just use it do the KDF, > which seems like it has weakersecurity requirements. > > Here=E2=80=99s a specific construction, but we=E2=80=99re flexible about = the details: > > struct { > opaque base_identity<1...2^16-1>; > HashAlgorithm hash; > } imported_psk_identity; > > UPSKx =3D HKDF-Extract(0, UPSK) // UPSK is the input universal PSK > PSK =3D HKDF-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity), > TargetHash.length) // Might need to shorten label > > These functions would be executed with the KDF associated with the UPSK, > but produce > a key the size of the desired hash. > > This brings us to the question of TLS 1.2. I found Ilari=E2=80=99s analyi= s > pretty persuasive, so I would suggest we add the following text to the > TLS 1.3 spec: > > TLS 1.3 takes a conservative approach to PSKs by binding them to a > specific KDF. TLS 1.2 allows PSKs to be used with any hash function > and the TLS 1.2 PRF. The constructions in TLS 1.2 and TLS 1.3, > although both based on HMAC, are very different and there is no known > way in which reuse of the same PSK in TLS 1.3 and TLS 1.2 would > produce related output, although only limited formal analysis has bee= n > done. Implementations MAY wish to avoid reuse of keys between TLS 1.3 > and TLS 1.2, or use a key derivation proposal such as [Informative re= f > to this email or a draft]. > > Other than this, we wouldn=E2=80=99t make any changes to the document. > > What do people think? > > -Ekr > > > > > > On Thu, Jul 19, 2018 at 4:00 PM, Benjamin Kaduk < > bkaduk=3D40akamai.com@dmarc.ietf.org> wrote: > >> Hi all, >> >> As I mentioned at the mic today, there is a question that has been >> raised about whether it's wise to reuse an existing (TLS 1.2) PSK >> directly in the TLS 1.3 key ladder. At a high level, the reason why one >> might want to restrict this is that the security proofs for TLS 1.3 rely >> on the pre-shared key being only used with a single key-derivation >> function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different >> key-derivation function, so formally the proofs do not hold. We don't >> currently know of a specifc attack against such reuse, of course, but >> perhaps it is prudent to restrict our usage to adhere to the verified >> scenarios. >> >> This is somewhat timely, as if we do want to introduce a restriction, it >> would ideally be in the form of some text in the TLS 1.3 specification, >> which is very nearly done. >> >> It would be good to hear more opinions on this question, particularly >> from those who have worked on the formal verification directly. >> >> If I can attempt to summarize some discussion that occurred in the mic >> line today, Hannes was surprised that we would care, likening this case >> to the regular version negotiation, where we are happy to use the same >> certificate to sign messages for both TLS 1.2 and 1.3. David Benjamin >> points out that we explicitly go to the trouble of putting 64 bytes of >> 0x20 padding at the front of the content that gets signed for >> CertificateVerify, to enforce separation between the TLS versions. >> >> My own personal opinion is that we should enforce a domain separation >> between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal PSKs" >> proposal seems like a potential mechanism by which to do so without >> doubling the provisioning needs. >> >> -Ben (with no hat) >> >> _______________________________________________ >> 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 > > > --0000000000007d7e6c0571fd1101 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Fri, Jul 27, 2018 at 6:43 AM, Karthikeyan Bhargavan <kart= hik.bhargavan@gmail.com> wrote:

    <= div>
    As wit= h Universal PSKs (UPSKs), each input key is a triplet of
    (BaseIdentity, = BaseKey, KDF), where a BaseIdentity is a PSK identity
    as used today. To = use a UPSK, an implementation takes the set of KDF
    hashes it knows about= H_i and derives a set of PSKs

    <= /span>
    To be clear, you=E2=80=99re suggesting that the KDF =C2=A0attach= ed to an input key could be different from the KDF used within TLS 1.3 itse= lf.
    E.g. the KDF here could use HKDF-SHA256 whereas H_i and the h= ash function in the TLS 1.3 cipher suite could be SHA-384 or whatever, is t= hat correct?
    =C2=A0
    Precis= ely. In fact, the KDF associated with the UPSK could be some KDF that TLS d= oesn't even specify (e.g., a SHA-3 based construction).

    <= /div>

    The nice feat= ure of this imported PSK is that it is then completely outside the model of= TLS, its just a way of provisioning multiple independent TLS PSKs, where e= ach TLS PSK can presumably only be used with one hash algorithm

    Yes.

    (and one protocol version?)

    This is less clear. We'd obviously prefer to a= llow TLS 1.3 PSKs to be used with TLS 1.4 if possible (this would require t= he binders to be compatible). But we can figure that out if we do 1.4.




    If so, this should compose nicely with existing TLS proofs.

    Good news!

    Do you have any comments on my proposed disclaimer text?

    <= /div>
    -Ekr


    -Karthik


    <= div>


    =C2= =A0 Hash_i: H_i
    =C2=A0 Identity_i: BaseIdentity || H_i
    =C2=A0 Key_i: = Derived from BaseKey and Identity_i

    This gives you a set of keys whi= ch you can offer simultaneously on the
    TLS connection in independent psk= _identity blocks. (Note that the hash
    algorithm is what differentiates e= ach derived key.) This is a bit
    ugly, but with the current TLS 1.3 ciphe= rs, this basically just means
    SHA-256, but even in the worst case it=E2= =80=99s probably only 2-3.

    The nice thing about this design is that = if you know the set of hash
    functions, you can just compute all the impo= rted PSKs in advance, and
    there=E2=80=99s no need to touch the internals= of the TLS stack. This also
    means that if you have decided you don=E2= =80=99t like old hash X, you don=E2=80=99t
    need to use it to compute PSK= binders, you just use it do the KDF,
    which seems like it has weakersecu= rity requirements.

    Here=E2=80=99s a specific construction, but we= =E2=80=99re flexible about the details:

    =C2=A0=C2=A0 struct {
    =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 opaque base_identity<1...2^16-1>;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 HashAlgorithm hash;
    =C2=A0=C2=A0 = } imported_psk_identity;

    =C2=A0=C2=A0 UPSKx =3D HKDF-Extract(0, UPSK= )=C2=A0 // UPSK is the input universal PSK
    =C2=A0=C2=A0 PSK =3D HKD= F-Expand-Label(UPSKx, "derived psk", BaseKDF(psk_identity), Targe= tHash.length) // Might need to shorten label

    These= functions would be executed with the KDF associated with the UPSK, but pro= duce
    a key the size of the desired hash.

    This brings= us to the question of TLS 1.2. I found Ilari=E2=80=99s analyis
    pretty p= ersuasive, so I would suggest we add the following text to the
    TLS 1.3 s= pec:

    =C2=A0=C2=A0=C2=A0 TLS 1.3 takes a conservative approach to PSK= s by binding them to a
    =C2=A0=C2=A0=C2=A0 specific KDF. TLS 1.2 allows P= SKs to be used with any hash function
    =C2=A0=C2=A0=C2=A0 and the TLS 1.2= PRF. The constructions in TLS 1.2 and TLS 1.3,
    =C2=A0=C2=A0=C2=A0 altho= ugh both based on HMAC, are very different and there is no known
    =C2=A0= =C2=A0=C2=A0 way in which reuse of the same PSK in TLS 1.3 and TLS 1.2 woul= d
    =C2=A0=C2=A0=C2=A0 produce related output, although only limited forma= l analysis has been
    =C2=A0=C2=A0=C2=A0 done. Implementations MAY wish to= avoid reuse of keys between TLS 1.3
    =C2=A0=C2=A0=C2=A0 and TLS 1.2, or = use a key derivation proposal such as [Informative ref
    =C2=A0=C2=A0=C2= =A0 to this email or a draft].

    Other than this, we wouldn=E2=80=99t = make any changes to the document.

    What do people think?

    =
    -Ekr




    =
    On Thu, Jul 19, 2018 at 4:00 PM, Benjamin Ka= duk <bkaduk=3D40akamai.com@dmarc.ietf.org><= /span> wrote:
    Hi all,

    As I mentioned at the mic today, there is a question that has been
    raised about whether it's wise to reuse an existing (TLS 1.2) PSK
    directly in the TLS 1.3 key ladder.=C2=A0 At a high level, the reason why o= ne
    might want to restrict this is that the security proofs for TLS 1.3 rely on the pre-shared key being only used with a single key-derivation
    function (our HKDF-using Derive-Secret), and TLS 1.2 uses a different
    key-derivation function, so formally the proofs do not hold.=C2=A0 We don&#= 39;t
    currently know of a specifc attack against such reuse, of course, but
    perhaps it is prudent to restrict our usage to adhere to the verified
    scenarios.

    This is somewhat timely, as if we do want to introduce a restriction, it would ideally be in the form of some text in the TLS 1.3 specification,
    which is very nearly done.

    It would be good to hear more opinions on this question, particularly
    from those who have worked on the formal verification directly.

    If I can attempt to summarize some discussion that occurred in the mic
    line today, Hannes was surprised that we would care, likening this case
    to the regular version negotiation, where we are happy to use the same
    certificate to sign messages for both TLS 1.2 and 1.3.=C2=A0 David Benjamin=
    points out that we explicitly go to the trouble of putting 64 bytes of
    0x20 padding at the front of the content that gets signed for
    CertificateVerify, to enforce separation between the TLS versions.

    My own personal opinion is that we should enforce a domain separation
    between TLS 1.2 PSKs and TLS 1.3 PSKs; David Benjamin's "Universal= PSKs"
    proposal seems like a potential mechanism by which to do so without
    doubling the provisioning needs.

    -Ben (with no hat)

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

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


    --0000000000007d7e6c0571fd1101-- From nobody Fri Jul 27 09:58:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F04D130F43 for ; Fri, 27 Jul 2018 09:58:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ncsc.gov.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1xw83OjKGUh for ; Fri, 27 Jul 2018 09:58:01 -0700 (PDT) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100122.outbound.protection.outlook.com [40.107.10.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7104912D7F8 for ; Fri, 27 Jul 2018 09:58:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ncsc.gov.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pML0t7H6WPQ6CeGNyMhn5r8STHYUMoJRWvipcT6seAw=; b=fBTR0uxn7xZXt0HdNXJ9CM/IE6/ftRaz53l8pIxdkSXaA4/R1fuBQR4Xqn7bsU2YKGFGcQq50KbV14V42MbntjfmGNcz+/RXD8OCTdGaQowFW75nXpKxCIeyp0nO8mYuKL0Kbi1FxgKnnABnVZOaPVl7Ic4GDmIUgAKPooUfJbQ= Received: from LOXP123MB1176.GBRP123.PROD.OUTLOOK.COM (10.166.252.145) by LOXP123MB1416.GBRP123.PROD.OUTLOOK.COM (10.166.255.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.995.19; Fri, 27 Jul 2018 16:57:58 +0000 Received: from LOXP123MB1176.GBRP123.PROD.OUTLOOK.COM ([fe80::4c32:d4f5:1a0d:9900]) by LOXP123MB1176.GBRP123.PROD.OUTLOOK.COM ([fe80::4c32:d4f5:1a0d:9900%3]) with mapi id 15.20.0995.019; Fri, 27 Jul 2018 16:57:57 +0000 From: Mark O To: "tls@ietf.org" Thread-Topic: Re: [TLS] Last Call: (Example Handshake Traces for TLS 1.3) to Informational RFC Thread-Index: AdQlvLgjCo2xIe9fRqOnyG5Q7NEmMQ== Date: Fri, 27 Jul 2018 16:57:57 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Mark.O@ncsc.gov.uk; x-originating-ip: [51.141.34.27] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; LOXP123MB1416; 6:JTf4CCwmfdDgKKLFjXW316plqtbzc6hK+KdlJ50RKIWaEoz/Cq5Qc69wTvA6irqzldLLlmlWgxFMehMJOMLGTZzZq3W6UBtZwtYFRnRPZCYVFjoHrZs/5s4XR97QVgWL6T3/ZkRIKhXnsqmX9zoOOopUjtJwDFbNPG9ewU2E3evwQlfjCBayIk0FFf01xMD9v1ALE6+qodei9+EDircla/iuFkpQgCMvi8zm/IV8TqQwdrgsgioDZ4XyLNerOQZeWN/WWe3cj35K7cfsWifvb0y4+Nv3G+5Oeur/yoQIA/6GTDodNvaJRQWLucq4Itn+91gCfOz1g+U1CmH/Pa3Qc6UWsgth2JDbq2/J9QxW3XjXTGUEfTvTg77CgQnfMgZrS4+baCTYtOPmGm7Vsu3yzXS//LCu7Y/S/OcoRFNxxcypSLnkvMwWbNfH4Cl5p6X4dg/lRP1Yn1IOfXt12Qv3Cg==; 5:7qN8BirIRzWefMBrd9F60dZ4KNsXtkfXZKkb4Mj75C/oMSsmzNDyWeJzmFdP2xKJIoqSoRGcI3PYnP09Xxvt/ORgeJ+YXtiZiajLzgPdEYBTMbueBSudyFGk55+WBpm0LXBljnUrDJXVUaj/cV/gR8RSjgs7LduFgeMXBWNyUdU=; 7:jq1rJZYhov+KYdfh0GeCgyDIxCRaWoWT1QGcyoycVSDU5ua34n8JxE5gL9v+uYLni6ASLxmiPUpEELwbk5m2SnmLizdwfaJJ2EkWTwmzKVHYT177dK98EBpOZwWGV2iGt1mUH986tGH1vLnCbQ5NyJX2WMRdEI3RSgSODqdM2klNSCynx51uhqP2KmlkCtaPTiLyqhec0s2/HVU11IopaXPFJAqt7xLGvrdB+duSkj7vt3JpdQEzpiorZt2eNFNa x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f2ca930b-9d54-4270-ec9a-08d5f3e21abb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989117)(4534165)(7168020)(4627221)(201703031133081)(201702281549075)(8990107)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:LOXP123MB1416; x-ms-traffictypediagnostic: LOXP123MB1416: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(27231711734898)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3231311)(944501410)(52105095)(3002001)(149027)(150027)(6041310)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:LOXP123MB1416; BCL:0; PCL:0; RULEID:; SRVR:LOXP123MB1416; x-forefront-prvs: 07467C4D33 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39850400004)(366004)(346002)(136003)(376002)(396003)(199004)(189003)(6436002)(6246003)(2501003)(5250100002)(6506007)(7696005)(55236004)(102836004)(26005)(186003)(68736007)(1730700003)(8676002)(74482002)(74316002)(7736002)(81166006)(256004)(81156014)(2351001)(105586002)(5660300001)(106356001)(486006)(6916009)(3846002)(6116002)(2900100001)(99286004)(229853002)(478600001)(72206003)(14454004)(316002)(790700001)(476003)(5640700003)(53936002)(5630700001)(8936002)(97736004)(9686003)(55016002)(6306002)(54896002)(2906002)(75922002)(33656002)(25786009)(66066001)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:LOXP123MB1416; H:LOXP123MB1176.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ncsc.gov.uk does not designate permitted sender hosts) x-microsoft-antispam-message-info: mrHBTU5N/XZGrZhuD3rv6sHwwK5PDN43EKu2KacRXzQvBCYuCiVHUTkSYiB6deXZFLDoeJuVuDVxyHfojGvPkJKXJu21MTNdZpcQXKW09mG6Ocs3prxzRFbLuWPgUzpfx06let+WVw1TH9BZfTemMayt8Qu3NDDQ9XB+zMrFcXKdO+rdTaDoWrwG5L1aNHJQiahF1O1Kbnbuuz/24tj8aJ9O/Sl9mKuuGcOOZAUKwiO5DluM9EGOKEF53huHj21JWiImJsCKDIVNWcPHjwchMZjxEZ5K/v5/y4t3+wD9cs9Se8HkFlg4uSxi7IqCsM0kPEE/BemWRyDR2XCm7xx6bE+Po6iVr8C3nA/XVYwI8M8= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_LOXP123MB1176437868ECB2E1FAB41C60D32A0LOXP123MB1176GBRP_" MIME-Version: 1.0 X-OriginatorOrg: ncsc.gov.uk X-MS-Exchange-CrossTenant-Network-Message-Id: f2ca930b-9d54-4270-ec9a-08d5f3e21abb X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2018 16:57:57.8294 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 14aa5744-ece1-474e-a2d7-34f46dda64a1 X-MS-Exchange-Transport-CrossTenantHeadersStamped: LOXP123MB1416 Archived-At: Subject: Re: [TLS] Last Call: (Example Handshake Traces for TLS 1.3) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 16:58:04 -0000 --_000_LOXP123MB1176437868ECB2E1FAB41C60D32A0LOXP123MB1176GBRP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A couple of comments on draft-ietf-tls-tls13-vectors-06: Ordering of messages: * Whenever the steps '{server} derive secret "tls13 c hs traffic":' an= d '{server} derive secret "tls13 s hs traffic":' appear, this is correspon= ding to the steps in the second phase of the key schedule (section 7.1 of t= ls13-28) * To complete these you need to have the encoded ServerHello message (a= s seen in 'Derive-Secret(., "c hs traffic", ClientHello...ServerHello)'). * The description of the ServerHello message doesn't come until several= steps later. Someone using the test vectors to create unit tests would nee= d to look ahead to the ServerHello payload (after '{server} send handshake= record:', starting with 'payload (90 octets): 02 00 00') before they can = recreate the steps above. Coalescence of records: There are several examples where multiple messages are shown concatenated, = both in their payload and ciphertext forms, which makes it much harder to t= est them. Concatenating them (or not) has no effect on the protocol, so it'= s not a requirement. It would be helpful to split out the messages so that = it's clearer which bytes belong to which message. The first example of this= is after "{server} send a EncryptedExtensions handshake message", "{serve= r} send a Certificate handshake message", "{server} send a CertificateVer= ify handshake message", and "{server} send a Finished handshake message"; = starting with "payload (657 octets): 08 00 00". * Mark This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_LOXP123MB1176437868ECB2E1FAB41C60D32A0LOXP123MB1176GBRP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

     

    A couple of comments on draft-ietf-tls-tls13-vectors= -06:

    Ordering of messages:

    • Whenever the steps ‘{server}  d= erive secret "tls13 c hs traffic":’ and ‘{server} &nb= sp;derive secret "tls13 s hs traffic":’ appear, this is cor= responding to the steps in the second phase of the key schedule (section 7.= 1 of tls13-28)
    • To complete these you need to have the enc= oded ServerHello message (as seen in ‘Derive-Secret(., "c hs tra= ffic", ClientHello...ServerHello)’).
    • The description of the ServerHello message= doesn’t come until several steps later. Someone using the test vecto= rs to create unit tests would need to look ahead to the ServerHello payload= (after ‘{server}  send handshake record:’, starting with ‘payload (90 octets):  02 00 00’) before th= ey can recreate the steps above.

    Coalescence of record= s:
    There are several examples where multiple messages are shown concatenated, = both in their payload and ciphertext forms, which makes it much harder to t= est them. Concatenating them (or not) has no effect on the protocol, so it&= #8217;s not a requirement. It would be helpful to split out the messages so that it’s clearer which bytes b= elong to which message. The first example of this is after "{server} &= nbsp;send a EncryptedExtensions handshake message", "{server} &nb= sp;send a Certificate handshake message", "{server}  send a = CertificateVerify handshake message", and "{server}  send a Finished handshak= e message"; starting with "payload (657 octets):  08 00 00&q= uot;.

    • Mark

     

    This information is exempt under the Freedom of Information Act 2000 (FOIA)= and may be exempt under other UK information legislation. Refer any FOIA q= ueries to ncscinfoleg@ncsc.gov.uk --_000_LOXP123MB1176437868ECB2E1FAB41C60D32A0LOXP123MB1176GBRP_-- From nobody Fri Jul 27 12:26:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07EB3131056 for ; Fri, 27 Jul 2018 12:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yj5exn7ym33 for ; Fri, 27 Jul 2018 12:26:10 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C387E13105D for ; Fri, 27 Jul 2018 12:26:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id A60973005A8 for ; Fri, 27 Jul 2018 15:26:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vz6FbIxbdlgS for ; Fri, 27 Jul 2018 15:26:06 -0400 (EDT) Received: from a860b60074bd.home (pool-71-127-50-4.washdc.fios.verizon.net [71.127.50.4]) by mail.smeinc.net (Postfix) with ESMTPSA id 66DEF300541; Fri, 27 Jul 2018 15:26:06 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Russ Housley In-Reply-To: <98fd53a18dc6b06ecd750201239721e8f88d5e7e.camel@redhat.com> Date: Fri, 27 Jul 2018 15:26:07 -0400 Cc: IETF TLS Content-Transfer-Encoding: quoted-printable Message-Id: References: <797D67EC-9390-47CD-BD6A-75E34E5FE33F@vigilsec.com> <1524474119.4793.7.camel@redhat.com> <98fd53a18dc6b06ecd750201239721e8f88d5e7e.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [TLS] draft-housley-tls-tls13-cert-with-extern-psk X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 19:26:17 -0000 > On Jul 27, 2018, at 5:23 AM, Nikos Mavrogiannopoulos = wrote: >=20 > On Mon, 2018-04-23 at 15:30 -0400, Russ Housley wrote: >>>=20 >>> In the presentation the main driver for it seems to be quantum >>> computer >>> resistance as temporary measure. If that's the main argument I >>> don't >>> think it is really significant. PSK can hardly be used with PKI, >>> and as >>> a matter of fact we use PKI because of PSK key distribution >>> problems. >>> If we switch to PSK for quantum computer resistance there is there >>> a >>> reason to use PKI? Probably no (I may be wrong here, if there is a >>> reason for a hubrid model I'm missing, I'd be glad to know). >>=20 >> I am not advocating for a pairwise PSK between every client and >> server. If that were available to us, then as you say, we would >> always use the PSK without any PKI. >>=20 >> I envision a PSK being distributed to a group of clients and group of >> severs. At some point in the future a large-scale quantum computer >> might get invented, and if any member of the group has access to it, >> then they can recover the traffic. However, parties outside the >> group cannot recover the traffic because the large-scale quantum >> computer does not assist with the discovery of the PSK. >=20 > [going back to this thread, as I have missed that reply and only saw = it > after the request for adoption was made] >=20 > It certainly makes sense. >=20 >>> I could see the main driver for such proposal the replacement of >>> the >>> RSA-PSK ciphersuites. I know they have _some_ adoption, but I'm not >>> sure whether that is significant to require update to TLS1.3. >>=20 >> This is not my goal. >>=20 >>> On the implementation side, why not use post-handshake >>> authentication >>> here? I.e., extend it to be usable from client-side, and on a PSK >>> key >>> exchange, have the client request server authentication after the >>> handshake? >>=20 >> I'm not sure why that is easier to implement. Can you say more? >=20 > Current TLS1.3 implementations can do a PSK key exchange and > authenticate the client's certificate with post-handshake auth. Based > on that, what you'd need to make that authentication two-way (both > server and client use cert) is the ability for client to ask the = server > for certificate.=20 >=20 > As PHA is fairly simple (server sends a certificate request to client > if the PHA extension is seen), doing the opposite if another extension > is seen, seems trivial (the bits and pieces are already there). The bits and pieces for using and external PSK with certificates are = also already present. That is why the extension is defines as: struct { select (Handshake.msg_type) { case client_hello: Empty; case server_hello: Empty; }; } CertWithExternPSK; See = https://datatracker.ietf.org/meeting/102/materials/slides-102-tls-certific= ate-based-authentication-with-external-psk-00; Slide 5 shows that other extensions are used, and slide 6 shows the = above syntax. Russ From nobody Fri Jul 27 16:21:31 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E963B130D7A for ; Fri, 27 Jul 2018 16:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODkP8_LVfE1K for ; Fri, 27 Jul 2018 16:21:26 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 15F1F1277C8 for ; Fri, 27 Jul 2018 16:21:26 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id f1-v6so5737410ljc.9 for ; Fri, 27 Jul 2018 16:21:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=qGl9+jsbwUwNI747ds6/oxIBtf/mZe+OMc8Qyhmo/2Y=; b=OuKCiXdmNFCsd3/UxQOpUGPXCQgyPYKFdQdDj5TmOduiv38PsorSujldmOT5i4Rywz b65Q2TVfBtY1OU13CIQ9shyUNgf2RPDFbgud6a5UOGyQEU61Pm/VqLl6CXpVIL736rTm BBMk0U5bacSdIxY6nUCpBrw0cHROLIuWNZ5SehmCiXE/jDU2ZrLGuMwRIBlNN3j3om2m SA/MBuEOP1FChfjQqw34vxS3vHUjxA+/g3/IZ27lTiRENdPSl/WgJ8lvByGEewLhArFe maWOAlQn5CzLLrMHXPPfxVVlAm6NPc08dFRKtjjAEYRb04SIJeuwfR6sBhRGD4pxW1fA CkfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=qGl9+jsbwUwNI747ds6/oxIBtf/mZe+OMc8Qyhmo/2Y=; b=ehclGqFykET+k4odHHaH7axPzcU3xsrp1WgiyDQIdrrkIeWLKNj4fRNJlunQyH+sAu zv2VGOBRKpi5nX9mtoCMLa76Y2aBUVdedQ8HyM1QlvtkGGhJOBqH0gaFre/Xne895ppX tQroMS8IBC25H25Od+Tatj7wU2S80l07E+XPJt8lEELlNBcT7xVvmpA2QxAFuKHPjV0K hCjVraY9NKAQvoc8JE/HN10pHQMLQRcMU3lI+7HujxNsDwBX+88lZSNdwviTyxFmFKJU i1xVTi6UQok5AX3cjW5e+SQ/ndduJ8DtbgdALtUicT9+dHdmT/tUqhpvilqx3alAoepn D/tA== X-Gm-Message-State: AOUpUlEEcmerkQayRTiQpq9kAtfuT7sKP83DTEh45uFFt5kD2QDvGEwM rQfPeeKiTlVkMOWAavO8TShJB0x1lpYSNUVluZLzWk37pNM= X-Google-Smtp-Source: AAOMgpfacezaFZNLjGt5Z7ICLhm7Z6IlvfDFvpehCxMNFxNcZZjsfnpyNTaLnmfFvkMlmT9eMEfWkt/S9HdeQec4Y+8= X-Received: by 2002:a2e:458b:: with SMTP id s133-v6mr6012235lja.151.1532733683963; Fri, 27 Jul 2018 16:21:23 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Fri, 27 Jul 2018 16:20:43 -0700 (PDT) From: Eric Rescorla Date: Fri, 27 Jul 2018 16:20:43 -0700 Message-ID: To: "" Content-Type: multipart/alternative; boundary="000000000000c4a4e40572035e2c" Archived-At: Subject: [TLS] Double-Checking after TLS 1.3 pre-RFC copy edits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 27 Jul 2018 23:21:30 -0000 --000000000000c4a4e40572035e2c Content-Type: text/plain; charset="UTF-8" Dear TLS WG members. I am doing my final copy-edits for the TLS 1.3 RFC and I noted one technical point and two points I would like to edit for clarity but I wanted more eyes on. 1. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.2 If the client is attempting a PSK key establishment, it SHOULD advertise at least one cipher suite indicating a Hash associated with the PSK. This seems like it would be better as a MUST. It's not a disaster if we don't change it, but can anyone think of a reason it should be a SHOULD? 2. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-7.4.2 The following block comes *after* the description of how to compute ECDH for the NIST curves but before stuff about the CFRG curves. ECDH functions are used as follows: - The public key to put into the KeyShareEntry.key_exchange structure is the result of applying the ECDH scalar multiplication function to the secret key of appropriate length (into scalar input) and the standard public basepoint (into u-coordinate point input). - The ECDH shared secret is the result of applying the ECDH scalar multiplication function to the secret key (into scalar input) and the peer's public key (into u-coordinate point input). The output is used raw, with no processing. So it's not clear from the text which it applies to. I'm not the expert here, but it seems like this is at least confusing in the context of NIST curves, so perhaps we need to rescope it in to the CFRG curves. This seems to be Ilari's text. Ilari? 3. The following text: Key derivation in TLS 1.3 uses the HKDF function defined in [RFC5869] and its two components, HKDF-Extract and HKDF-Expand. The full rationale for the HKDF construction can be found in [Kraw10] and the rationale for the way it is used in TLS 1.3 in [KW16]. Throughout this document, each application of HKDF-Extract is followed by one or more invocations of HKDF-Expand. This ordering should always be followed (including in future revisions of this document), in particular, one SHOULD NOT use an output of HKDF-Extract as an input to another application of HKDF-Extract without an HKDF-Expand in between. Consecutive applications of HKDF-Expand are allowed as long as these are differentiated via the key and/or the labels. to another application of HKDF-Extract without an HKDF-Expand in In context, this suggests that we're talking about: HKDF-Expand-Label(HKDF-Expand-Label()) but that's confusing because obviously those differ by key. I think we are not trying to talk about this but rather about two HKDF-Expand-Labels on related inputs. to that end, I changed it to: Multiple applications of HKDF-Expand to some of the same inputs are allowed as long as these are differentiated via the key and/or the labels. We could also say that you can HKDF-Expand-Label() repeatedly as above, but we don't actually do this, I believe, so no point in saying it. Objections? -Ekr --000000000000c4a4e40572035e2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

    Dear TLS WG members.

    I am doing my final copy-e= dits for the TLS 1.3 RFC and I noted one
    technical point and two points = I would like to edit for clarity but I
    wanted more eyes on.


    1= . https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.2<= br>
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If the client is attempting a PSK key=
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 establishment, it SHOULD advertise at le= ast one cipher suite
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 indicating a Hash as= sociated with the PSK.

    This seems like it would be better as a MUST.= It's not a disaster
    if we don't change it, but can anyone think= of a reason it should
    be a SHOULD?


    2. https://tools.ietf.= org/html/draft-ietf-tls-tls13-28#section-7.4.2

    The following blo= ck comes *after* the description of how to compute
    ECDH for the NIST cur= ves but before stuff about the CFRG curves.

    =C2=A0=C2=A0 ECDH functi= ons are used as follows:

    =C2=A0=C2=A0 -=C2=A0 The public key to put = into the KeyShareEntry.key_exchange
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struc= ture is the result of applying the ECDH scalar multiplication
    =C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 function to the secret key of appropriate length (int= o scalar
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 input) and the standard public b= asepoint (into u-coordinate point
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 input).=

    =C2=A0=C2=A0 -=C2=A0 The ECDH shared secret is the result of applyi= ng the ECDH scalar
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 multiplication functio= n to the secret key (into scalar input) and
    =C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 the peer's public key (into u-coordinate point input).=C2=A0 The ou= tput
    =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 is used raw, with no processing.
    =
    So it's not clear from the text which it applies to. I'm not th= e expert
    here, but it seems like this is at least confusing in the conte= xt
    of NIST curves, so perhaps we need to rescope it in to the CFRG
    cu= rves. This seems to be Ilari's text. Ilari?


    3. The following= text:

    =C2=A0=C2=A0 Key derivation in TLS 1.3 uses the HKDF function= defined in [RFC5869]
    =C2=A0=C2=A0 and its two components, HKDF-Extract = and HKDF-Expand.=C2=A0 The full
    =C2=A0=C2=A0 rationale for the HKDF cons= truction can be found in [Kraw10] and the
    =C2=A0=C2=A0 rationale for the= way it is used in TLS 1.3 in [KW16].=C2=A0 Throughout
    =C2=A0=C2=A0 this= document, each application of HKDF-Extract is followed by one or
    =C2=A0= =C2=A0 more invocations of HKDF-Expand.=C2=A0 This ordering should always b= e
    =C2=A0=C2=A0 followed (including in future revisions of this document)= , in
    =C2=A0=C2=A0 particular, one SHOULD NOT use an output of HKDF-Extra= ct as an input
    =C2=A0=C2=A0 to another application of HKDF-Extract witho= ut an HKDF-Expand in
    =C2=A0=C2=A0 between.=C2=A0 Consecutive application= s of HKDF-Expand are allowed as long
    =C2=A0=C2=A0 as these are different= iated via the key and/or the labels.
    =C2=A0=C2=A0 to another application= of HKDF-Extract without an HKDF-Expand in

    In context, this suggests= that we're talking about:

    =C2=A0=C2=A0 HKDF-Expand-Label(HKDF-E= xpand-Label())

    but that's confusing because obviously those diff= er by key. I think we
    are not trying to talk about this but rather about= two HKDF-Expand-Labels
    on related inputs. to that end, I changed it to:=

    =C2=A0=C2=A0 Multiple applications of HKDF-Expand to some of the sa= me inputs are
    =C2=A0=C2=A0 allowed as long as these are differentiated v= ia the key and/or the
    =C2=A0=C2=A0 labels.

    We could also say that= you can HKDF-Expand-Label() repeatedly as
    above, but we don't actua= lly do this, I believe, so no point in
    saying it. Objections?

    -Ek= r




    --000000000000c4a4e40572035e2c-- From nobody Fri Jul 27 20:22:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCD91277CC for ; Fri, 27 Jul 2018 20:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.509 X-Spam-Level: X-Spam-Status: No, score=-17.509 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ejp26UmWK8UC for ; Fri, 27 Jul 2018 20:22:51 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::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 D08A7130EFA for ; Fri, 27 Jul 2018 20:22:50 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id l15-v6so6011055lji.6 for ; Fri, 27 Jul 2018 20:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LgBtu0BjUCjBNJ7IbnfHX86zLoMbhrVNjzVpA7pLcZM=; b=rZbPGXMiIfTWMVT3ubyto7k6JAyEOilFOH+Nu+lA6/aIKDZkV4ckD2iQ7BD+hl2GoO lvlVItFyxWGp3Q2vyS8Ur+cjcqKyV+37USqcSoTRK4h/xbFa5R0O8NGRWQWEICE7sED8 BViugpM/DmLvfGfYe1IgydEkXsnWCmXTXnp9DtSg1Gj8GgKfmKOMpibdmbN+8lDCmuJr 9ijKcPFM+x6OrcZTqSLBoFJpb05V5irfcYUwqPx9Y1JrXuMHyQlfXOr8BbALOsa+11FQ cn8cpORC44sxdh1A7a5/gurAwkaZBxMpfcdIg42VXFLqP/x3UP4ZeTG0hWAjsHEBFvDn y3KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LgBtu0BjUCjBNJ7IbnfHX86zLoMbhrVNjzVpA7pLcZM=; b=GDSlAfU0faIpeOFtCIusLmvV7aFreqnZ7MQLkkHGOaeVqFudBU9wL1JgYt4uRe8HQi hDZ1wAud9IpfI/H/eaBU8EBekxIsImYhMAuGrjbTTQ9NrYeW7YiMbvg6ZBXhjSx3G6vx D84HiFdUTLVM/Q6jo9bQRzdVgEJ3D7jCT0maiCKa2TxLBPE6UgSHm3QA6ch0TSctc6Ss 0QDhi4ks5C99WqwwvXgs7M+ZKwST1En97sGVt8vdzdWpiCFSDStrQAkPI4wz8n1d6ofb Gm1aZeAPoTikWZprzZd/d/Ix61/T9pWD7HhQaRZUqqhPD8LseT18WrrccWE3FtXbGGbR c0qQ== X-Gm-Message-State: AOUpUlFZzPK3uuJqUax8vEkMSgcGFTnhVkiOjuUgYD53brJ9cvy3esE0 fZ5t34bRVH5yw5/54s+RGOw/qKBmnXouFNY9naJnbQ== X-Google-Smtp-Source: AAOMgpe7w9cOFLgIFYy9b3yRHoqGu89b1xa2vrJaqlGexaSTU1RBf99Hs7Z65f6EUv6o5GrbiYapnukvST9UO+K2raY= X-Received: by 2002:a2e:10ca:: with SMTP id 71-v6mr6674200ljq.59.1532748168676; Fri, 27 Jul 2018 20:22:48 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Victor Vasiliev Date: Fri, 27 Jul 2018 23:22:35 -0400 Message-ID: To: Joseph Salowey Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002058b2057206bef1" Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2018 03:22:53 -0000 --0000000000002058b2057206bef1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption of this draft and would be happy to review it. On Tue, Jul 24, 2018, 22:18 Joseph Salowey wrote: > > The sense of the TLS@IETF102 room was the the WG should adopt > https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. > But, we need to confirm this on list. If you would like for this draft t= o > become a WG document and you are willing to review it as it moves through > the process, then please let the list know by 2359UTC 20180807. If you a= re > opposed to this being a WG document, please say so (and say why). > > Note that the draft has been marked as a "Candidate for WG Adoption=E2=80= =9D in > the datatracker. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --0000000000002058b2057206bef1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I support adoption of this draft and would be happy to re= view it.

    On Tue, Jul 2= 4, 2018, 22:18 Joseph Salowey <joe@salowey.net> wrote:

    The sense of the TLS@IETF102 room was the the = WG should adopt=C2=A0https:/= /datatracker.ietf.org/doc/draft-rescorla-tls-esni/=C2=A0as a WG item.=C2=A0 But, we need = to confirm this on list.=C2=A0 If you would like for this draft to become a= WG document and you are willing to review it as it moves through the proce= ss, then please let the list know by 2359UTC 20180807.=C2=A0 If you are opp= osed to this being a WG document, please say so (and say why).

    Note = that the draft has been marked as a "Candidate for WG Adoption=E2=80= =9D in the datatracker.

    <= br>
    _______________________________________________
    TLS mailing list
    TLS@ietf.org
    https://www.ietf.org/mailman/listinfo= /tls
    --0000000000002058b2057206bef1-- From nobody Sat Jul 28 00:50:36 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 169EF130DDC for ; Sat, 28 Jul 2018 00:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.589 X-Spam-Level: X-Spam-Status: No, score=-0.589 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s2_GlLysE8xC for ; Sat, 28 Jul 2018 00:50:30 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD781310F9 for ; Sat, 28 Jul 2018 00:50:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 20E19975E7; Sat, 28 Jul 2018 10:50:27 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id cMavgXg0w1Uj; Sat, 28 Jul 2018 10:50:24 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 585E573; Sat, 28 Jul 2018 10:48:52 +0300 (EEST) Date: Sat, 28 Jul 2018 10:48:51 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "" Message-ID: <20180728074851.GA14017@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Double-Checking after TLS 1.3 pre-RFC copy edits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2018 07:50:33 -0000 On Fri, Jul 27, 2018 at 04:20:43PM -0700, Eric Rescorla wrote: > Dear TLS WG members. > > I am doing my final copy-edits for the TLS 1.3 RFC and I noted one > technical point and two points I would like to edit for clarity but I > wanted more eyes on. > > 2. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-7.4.2 > > The following block comes *after* the description of how to compute > ECDH for the NIST curves but before stuff about the CFRG curves. > > ECDH functions are used as follows: > > - The public key to put into the KeyShareEntry.key_exchange > structure is the result of applying the ECDH scalar multiplication > function to the secret key of appropriate length (into scalar > input) and the standard public basepoint (into u-coordinate point > input). > > - The ECDH shared secret is the result of applying the ECDH scalar > multiplication function to the secret key (into scalar input) and > the peer's public key (into u-coordinate point input). The output > is used raw, with no processing. > > So it's not clear from the text which it applies to. I'm not the expert > here, but it seems like this is at least confusing in the context > of NIST curves, so perhaps we need to rescope it in to the CFRG > curves. This seems to be Ilari's text. Ilari? There are basically three types of asymmetric key exchange TLS 1.3 can currently use: - Multiplicative Diffie-Hellman. - Elliptic-Curve Diffie-Hellman with (x,y) point coordinates. - "ECDH functions". And then the term "ECDH function" is seemingly not defined anywhere. But that definition is certainly intended to encompass X25519 and X448, being any function f from pair of octet strings to a octet string plus octet string G, such that: - f is easy to compute. - f(a,f(b,G)) = f(b,f(a,G)) - It is hard to compute any f(a,f(b_i,G)) from f(a,G) and all f(b_i,G), for some index i, except with very small probability. These condtions imply that one can construct Diffie-Hellman type key exchange safe for multiple uses. For both X25519 and X448, one can find such f and G. There are also other such function + base pairs (not necressarily derived from elliptic curves). And then there are key exchanges that are thought to be secure, but can not be expressed in such framework, even with extra transforms. E.g. key exchanges based on Key Encapsulation Mechanisms (which are important for post-quantum, thus PQ would need a fourth type). Looks like the text after it was considerably expanded from when that text was originally introduced. It initially said "For X25519 and X448, see [RFC7748]." (and in -11, it was a reference to the draft that became RFC7748). Now it has considerably expanded text: For X25519 and X448, implementations SHOULD use the approach specified in [RFC7748] to calculate the Diffie-Hellman shared secret. Implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in Section 6 of [RFC7748]. If implementors use an alternative implementation of these elliptic curves, they SHOULD perform the additional checks specified in Section 7 of [RFC7748]. Might make sense to split the section and define the dangling term somewhere? -Ilari From nobody Sat Jul 28 01:08:51 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 905C51310FF for ; Sat, 28 Jul 2018 01:08:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_7SRpA4HTnY for ; Sat, 28 Jul 2018 01:08:47 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01535130E03 for ; Sat, 28 Jul 2018 01:08:46 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id a3-v6so7262407wrt.2 for ; Sat, 28 Jul 2018 01:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Y4xmEIdhlQ4zR89bhNeZUxnPIQMTVmBSfiVVeyFv/g8=; b=N3fYy6i0zg/ygb7D43oK+bTJ2t/alm2Q/y3og6Uc0TGLYXyPp7ebNpo3k/szQSTDtj YSWJtZNwwTFfgJg2uZ+RJMrxCZ0mOUi7lGy5liKe51Fy95HEk+6SXjcI544NK/yea647 5VmCpbJUwNdtVyCIxWT8CITE2ahmSN1r4m9oVtKoW/28iOmsTSya0UKW/dOHUcc3H329 9799dl5M5FDC+26sqCV1Bkmu3dWA92nhnnUMXfIeHWY5+6J9dySsd5QzuU1UHgJZ5WrB YBnNplea6OcItS5sZICdNL52tNQMXewq5SnyWIvqQzvCUIY7H6VKrZGubMHTs6jk7AtM KhAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Y4xmEIdhlQ4zR89bhNeZUxnPIQMTVmBSfiVVeyFv/g8=; b=Q1XpceLRJ8fiIBRxpRWfuv8svdiiRNtJ/qTX4B/DsjCANZtpZJnvqduufbBXu2HYOG 3p2PmQkS+ispdDmAGUmTGUWRmGz7MLfVxoNlEhPt6P8k1W1L8GX2W0lxQEonWYAHHx2k RbAaApCPiZVGA3BrA/h1YeTO+8BSj5N//iV2Qdrps53jya+1Ln2U5jA5AuA1QNEOcz9Z VOqfuN1bLPXYJMrB6hat0g4OCA9v5fZoUU7Glr5pJTmBbagh0LozpD5BeAli3mcsCt2f tfHBCc6pa+6UpW4AbyPZopd90i3dTwNfRxD46Xd3VhEbCys5pxbQLEL5XaBMubjn7P4N 3GIg== X-Gm-Message-State: AOUpUlFaF8eEdMhRmzQKK3kr3UzDMFrabMWjwaN26ODr6jF+rRYN1Wsg 0oh6CyadPmYpYqy0NUkTPx9qnzKAj75GV2FZ+X7ZyQ== X-Google-Smtp-Source: AAOMgpcEIA8DtbOboswufmBpXEBYRVc3tKHQbOia1dkYbXI7dhb8WAqRvWAH1aapbUb/pkI7BNBC6oaxwf0PNqfMWps= X-Received: by 2002:adf:e34d:: with SMTP id n13-v6mr8635297wrj.158.1532765325444; Sat, 28 Jul 2018 01:08:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 01:08:44 -0700 (PDT) In-Reply-To: References: From: Tim Wicinski Date: Sat, 28 Jul 2018 04:08:44 -0400 Message-ID: To: Victor Vasiliev Cc: Joseph Salowey , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bf4a2005720abc94" Archived-At: Subject: Re: [TLS] WG adoption call: draft-rescorla-tls-esni X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2018 08:08:50 -0000 --000000000000bf4a2005720abc94 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I support adoption of this draft, but as a consumer of SSL certificates which have *17* wildcards on one certificate, I feel that the handling of wildcard DNS records in this draft needs some more thought. Tim On Fri, Jul 27, 2018 at 11:22 PM, Victor Vasiliev < vasilvv=3D40google.com@dmarc.ietf.org> wrote: > I support adoption of this draft and would be happy to review it. > > On Tue, Jul 24, 2018, 22:18 Joseph Salowey wrote: > >> >> The sense of the TLS@IETF102 room was the the WG should adopt >> https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/ as a WG item. >> But, we need to confirm this on list. If you would like for this draft = to >> become a WG document and you are willing to review it as it moves throug= h >> the process, then please let the list know by 2359UTC 20180807. If you = are >> opposed to this being a WG document, please say so (and say why). >> >> Note that the draft has been marked as a "Candidate for WG Adoption=E2= =80=9D in >> the datatracker. >> >> >> _______________________________________________ >> 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 > > --000000000000bf4a2005720abc94 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    I support adoption of this draft, but as a consumer of SSL= certificates which have *17* wildcards on one certificate, I feel that the= handling of wildcard DNS records in this draft needs some more thought.
    Tim

    <= br>
    On Fri, Jul 27, 2018 at 11:22 PM, Victor Vasi= liev <vasilvv=3D40google.com@dmarc.ietf.org> wrote:
    I support a= doption of this draft and would be happy to review it.

    On= Tue, Jul 24, 2018, 22:18 Joseph Salowey <joe@salowey.net> wrote:

    The sense of the TLS@IETF102 room w= as the the WG should adopt=C2=A0https://datatracker.ietf.org/doc/draft-rescorla-tls-esni/= =C2=A0as a WG item= .=C2=A0 But, we need to confirm this on list.=C2=A0 If you would like for t= his draft to become a WG document and you are willing to review it as it mo= ves through the process, then please let the list know by 2359UTC 20180807.= =C2=A0 If you are opposed to this being a WG document, please say so (and s= ay why).

    Note that the draft has been marked as a "Candidate fo= r WG Adoption=E2=80=9D in the datatracker.


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

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


    --000000000000bf4a2005720abc94-- From nobody Sat Jul 28 06:41:58 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D377130F4D for ; Sat, 28 Jul 2018 06:41:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lBohSPmYiTMJ for ; Sat, 28 Jul 2018 06:41:52 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::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 96576130ECF for ; Sat, 28 Jul 2018 06:41:51 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id j19-v6so6751696ljc.7 for ; Sat, 28 Jul 2018 06:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cCCnC1Uim7zPIfBoojsPoKgydHec3G0MEZPVKgAvstA=; b=nFxg0tjLs7RkUe4CQg95bxXCUciMsdQnuIrlSmTPRldsHWxdNQnmr7TYtdxnV3TyRL HK4zUf4fjUc7pX1dZRKXxlVWBTEQH7i8sKnjjcrwXN64zw9+Kl0QAiLieeNoi2+PVjNQ RYxuj9y6jFM0svYRAu83zn868/rNQjriw79wYZwuPJJTGyexOvgBZMqaOFSstg/sDNz0 IGIOqCIa2QWRUohAqqeONBqGld1aeTbGa11zezgCpZ2lE80uoVRml160mxYBb/5TUgXU Kl3dRN1742GK4whMFUQytrBFEZA8k+9rxXLrGJMsbkpETDprYjrvr7rkvvByXDieaUXa FY8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cCCnC1Uim7zPIfBoojsPoKgydHec3G0MEZPVKgAvstA=; b=oxZcoRe4fJgtVBTbJ3Zjw0BJzKotoWOVvP4x7+O+XWjklOi8vneoLOhzcOp6uOHX1R C/8vBvKJwmP4r9thXGbwbVREMmvx5Aia0KXTHveRSa3sCuH5333KJDMhSH8TCXLu5OsV criEu7sO9oW8Xaey+h6csjU/SxujYK9ffCxVZFNA+nD4ozQxiH9z8v/1cHneSFvACpUj yqf9fJEZIyqBFqzD99g/Zj1W2g8SCe9Nti4uuu6hLG7RTT4JkPIapEjm9jvCkHZkcTro KlpPdIkcX21p+HB7IJ6V95tQoWex2WP2yF9koVxKpDMLbf2/zexXugYaq3lJGzawMZPT Lftg== X-Gm-Message-State: AOUpUlG16BxQyNP1JmrYmNNQv4mF0meLPATwCbehxM5upIlLaeB7MZEH TN2WGAnvAF/e0Pa3E7BrQ4E1fT1PrmoELAFrdSVSOrnP X-Google-Smtp-Source: AAOMgpf+mZGJLSo4bOGTuLbSKbitXNoIyvRNkI6vYVTqHTaDO82Kx3evUNSlBCt8/kCv6QXwX8KKssXYbVMfb9/z26Y= X-Received: by 2002:a2e:2096:: with SMTP id g22-v6mr7707193lji.37.1532785309787; Sat, 28 Jul 2018 06:41:49 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 06:41:09 -0700 (PDT) In-Reply-To: <20180728074851.GA14017@LK-Perkele-VII> References: <20180728074851.GA14017@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 28 Jul 2018 06:41:09 -0700 Message-ID: To: Ilari Liusvaara Cc: "" Content-Type: multipart/alternative; boundary="000000000000e83e8605720f6335" Archived-At: Subject: Re: [TLS] Double-Checking after TLS 1.3 pre-RFC copy edits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2018 13:41:57 -0000 --000000000000e83e8605720f6335 Content-Type: text/plain; charset="UTF-8" On Sat, Jul 28, 2018 at 12:48 AM, Ilari Liusvaara wrote: > On Fri, Jul 27, 2018 at 04:20:43PM -0700, Eric Rescorla wrote: > > Dear TLS WG members. > > > > I am doing my final copy-edits for the TLS 1.3 RFC and I noted one > > technical point and two points I would like to edit for clarity but I > > wanted more eyes on. > > > > 2. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-7.4.2 > > > > The following block comes *after* the description of how to compute > > ECDH for the NIST curves but before stuff about the CFRG curves. > > > > ECDH functions are used as follows: > > > > - The public key to put into the KeyShareEntry.key_exchange > > structure is the result of applying the ECDH scalar multiplication > > function to the secret key of appropriate length (into scalar > > input) and the standard public basepoint (into u-coordinate point > > input). > > > > - The ECDH shared secret is the result of applying the ECDH scalar > > multiplication function to the secret key (into scalar input) and > > the peer's public key (into u-coordinate point input). The output > > is used raw, with no processing. > > > > So it's not clear from the text which it applies to. I'm not the expert > > here, but it seems like this is at least confusing in the context > > of NIST curves, so perhaps we need to rescope it in to the CFRG > > curves. This seems to be Ilari's text. Ilari? > > There are basically three types of asymmetric key exchange TLS 1.3 can > currently use: > > - Multiplicative Diffie-Hellman. > - Elliptic-Curve Diffie-Hellman with (x,y) point coordinates. > - "ECDH functions". > > And then the term "ECDH function" is seemingly not defined anywhere. > But that definition is certainly intended to encompass X25519 and > X448, being any function f from pair of octet strings to a > octet string plus octet string G, such that: > > - f is easy to compute. > - f(a,f(b,G)) = f(b,f(a,G)) > - It is hard to compute any f(a,f(b_i,G)) from f(a,G) and all f(b_i,G), > for some index i, except with very small probability. > > These condtions imply that one can construct Diffie-Hellman type key > exchange safe for multiple uses. For both X25519 and X448, one can find > such f and G. There are also other such function + base pairs (not > necressarily derived from elliptic curves). > > And then there are key exchanges that are thought to be secure, but can > not be expressed in such framework, even with extra transforms. E.g. key > exchanges based on Key Encapsulation Mechanisms (which are important for > post-quantum, thus PQ would need a fourth type). > > > Looks like the text after it was considerably expanded from when that > text was originally introduced. It initially said "For X25519 and X448, > see [RFC7748]." (and in -11, it was a reference to the draft that > became RFC7748). Now it has considerably expanded text: > > For X25519 and X448, implementations SHOULD use the approach > specified in [RFC7748] to calculate the Diffie-Hellman shared secret. > Implementations MUST check whether the computed Diffie-Hellman shared > secret is the all-zero value and abort if so, as described in > Section 6 of [RFC7748]. If implementors use an alternative > implementation of these elliptic curves, they SHOULD perform the > additional checks specified in Section 7 of [RFC7748]. > > > Might make sense to split the section and define the dangling term > somewhere? > Thanks. This helps. The text here isn't totally generic, as it refers to scalar multiplication and u-coordinate point input. So, if we had some other ECDH-type thing that didn't have these concepts, then we would have yet new text. In the interest of the minimal change, I suggest: "For X25519 and X448, the calculations are as follows" ... "For these curves, implementations SHOULD use..." How does that sound? -Ekr > > -Ilari > --000000000000e83e8605720f6335 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


    On Sat, Jul 28, 2018 at 12:48 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
    On Fri, Jul 27, 2018 at 04:20:43PM -0700, Eric Rescorla wrote: > Dear TLS WG members.
    >
    > I am doing my final copy-edits for the TLS 1.3 RFC and I noted one
    > technical point and two points I would like to edit for clarity but I<= br> > wanted more eyes on.
    >
    > 2. htt= ps://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-7.4.2
    >
    > The following block comes *after* the description of how to compute > ECDH for the NIST curves but before stuff about the CFRG curves.
    >
    >=C2=A0 =C2=A0 ECDH functions are used as follows:
    >
    >=C2=A0 =C2=A0 -=C2=A0 The public key to put into the KeyShareEntry.key_= exchange
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0structure is the result of applying the ECDH= scalar multiplication
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0function to the secret key of appropriate le= ngth (into scalar
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0input) and the standard public basepoint (in= to u-coordinate point
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0input).
    >
    >=C2=A0 =C2=A0 -=C2=A0 The ECDH shared secret is the result of applying = the ECDH scalar
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0multiplication function to the secret key (i= nto scalar input) and
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0the peer's public key (into u-coordinate= point input).=C2=A0 The output
    >=C2=A0 =C2=A0 =C2=A0 =C2=A0is used raw, with no processing.
    >
    > So it's not clear from the text which it applies to. I'm not t= he expert
    > here, but it seems like this is at least confusing in the context
    > of NIST curves, so perhaps we need to rescope it in to the CFRG
    > curves. This seems to be Ilari's text. Ilari?

    There are basically three types of asymmetric key exchange TLS 1.3 c= an
    currently use:

    - Multiplicative Diffie-Hellman.
    - Elliptic-Curve Diffie-Hellman with (x,y) point coordinates.
    - "ECDH functions".

    And then the term "ECDH function" is seemingly not defined anywhe= re.
    But that definition is certainly intended to encompass X25519 and
    X448, being any function f from pair of octet strings to a
    octet string plus octet string G, such that:

    - f is easy to compute.
    - f(a,f(b,G)) =3D f(b,f(a,G))
    - It is hard to compute any f(a,f(b_i,G)) from f(a,G) and all f(b_i,G),
    =C2=A0 for some index i, except with very small probability.

    These condtions imply that one can construct Diffie-Hellman type key
    exchange safe for multiple uses. For both X25519 and X448, one can find
    such f and G. There are also other such function + base pairs (not
    necressarily derived from elliptic curves).

    And then there are key exchanges that are thought to be secure, but can
    not be expressed in such framework, even with extra transforms. E.g. key exchanges based on Key Encapsulation Mechanisms (which are important for post-quantum, thus PQ would need a fourth type).


    Looks like the text after it was considerably expanded from when that
    text was originally introduced. It initially said "For X25519 and X448= ,
    see [RFC7748]." (and in -11, it was a reference to the draft that
    became RFC7748). Now it has considerably expanded text:

    =C2=A0 For X25519 and X448, implementations SHOULD use the approach
    =C2=A0 specified in [RFC7748] to calculate the Diffie-Hellman shared secret= .
    =C2=A0 Implementations MUST check whether the computed Diffie-Hellman share= d
    =C2=A0 secret is the all-zero value and abort if so, as described in
    =C2=A0 Section 6 of [RFC7748].=C2=A0 If implementors use an alternative
    =C2=A0 implementation of these elliptic curves, they SHOULD perform the
    =C2=A0 additional checks specified in Section 7 of [RFC7748].


    Might make sense to split the section and define the dangling term
    somewhere?




    --000000000000e83e8605720f6335-- From nobody Sat Jul 28 08:32:44 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A146130F26 for ; Sat, 28 Jul 2018 08:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhAniU06qSAy for ; Sat, 28 Jul 2018 08:32:41 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 1549F130F25 for ; Sat, 28 Jul 2018 08:32:41 -0700 (PDT) Received: from [10.32.60.55] (50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141]) (authenticated bits=0) by mail.proper.com (8.15.2/8.15.2) with ESMTPSA id w6SFWL6B062289 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Sat, 28 Jul 2018 08:32:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 50-1-51-141.dsl.dynamic.fusionbroadband.com [50.1.51.141] claimed to be [10.32.60.55] From: "Paul Hoffman" To: "TLS WG" Date: Sat, 28 Jul 2018 08:32:36 -0700 X-Mailer: MailMate (1.11.3r5509) Message-ID: <9413A59D-CAE5-473B-AA3D-427BFFCE3FC4@vpnc.org> In-Reply-To: References: <20180718023039.GV33554@straasha.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Archived-At: Subject: Re: [TLS] TLS DANE chain, detailed response to concerns raised in the room on Monday X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2018 15:32:43 -0000 (Reviving this thread to help the WG move forward on getting this document published) On 18 Jul 2018, at 5:41, Shumon Huque wrote: > On Wed, Jul 18, 2018 at 4:55 AM Eric Rescorla wrote: > >> >> To the extent to which this is true, it's an argument that one should >> be >> pinning at a different layer. >> >> > (I've mentioned this in private email to some of you, but for broader > input, I'm throwing it out on the list too.) > > On the topic of other layers .. > > At yesterday's WG meeting, Sam Weiler suggested that the pinning > information could be conveyed via the DNS. That way you would not need > new > holes/fields in the TLS extension. Paul said it doesn't work. But > Willem > Toorop and I discussed it after the meeting, and think that it does. In reading this thread, I agree with Shumon and others that the new RR proposal works, and it adds pinning in the DNS layer. However, I agree with Viktor and Niko that it is more complicated than an indicator in the chain extension about the pinning desired by the TLS server. As was discussed by many people at the mic line at the meeting, pinning is both important and difficult to get correct. Picking the "right" layer at which to pin is probably one of those architectural guesses that we might just have to make. Given that, my preference is for the simplest solution that actually and fully gives pinning for the TLSA record, and at this point that would be in the extension itself. --Paul Hoffman From nobody Sat Jul 28 10:32:59 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEE63131017 for ; Sat, 28 Jul 2018 10:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCGxMiD7fWJu for ; Sat, 28 Jul 2018 10:32:56 -0700 (PDT) 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 A99B0130FDF for ; Sat, 28 Jul 2018 10:32:56 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id l7-v6so6701958ioj.1 for ; Sat, 28 Jul 2018 10:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=L/Y/nwDIF8DGNpYk74DlVgqFdQncgfpdyhgZM51JkVc=; b=KZ7roxwn/iUMj+Ttj63CNArU+jyDPa0AQBnY5CadZwMGZud+uj7lPQ0L4G2pIuH3PU VCvzrp0ie+T0Dy4HvzROpbZUP0hHVoAwbKVwnEIotYvC8VEcipSm0Enp8vHa8HXkb1IU KH6O3jEpS5uvhKLY8O20gag+ybz+Ny4EK0fvV3vhQrIB/ItNUCV2z37Gwa3gdEIlBPJT rhgWOXPtExXX3gXpZI6ayl4jFU16p03W5B3KS5rKhdSVlpgJqhPIuXvf+PDfzFj1PF2U XkT+/KbyQwzyZtZbn9o9knf4RK0CsdfPGEvzhP1g95rZpCvUJSBp7IH26vz52paJe7xO XGMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=L/Y/nwDIF8DGNpYk74DlVgqFdQncgfpdyhgZM51JkVc=; b=YaMKjcI/nGEfXmsZp0OibSokl8VrEQ54Nb6BeH0EmLgX+VWYf5+7SByN+b6qpusxcL jbDpGfdrEM7V8OVvrGWccTX4T7msG233KaPpeFtJaRSZzpVaqgAEIHBTDExf1aS76RYs hxfda+/LiC1p56I5DV4QAoZ3tcNUH7UzYD8TLUZonYntldeSiMDA4+oNFSg/c14H9xSE CWpKiEz5076aht3wrOJV7vF/A3vv/8CyYmv/1L1BmQcZKyIAr6Pcp87Ot2pW21S5n9jh Ecuzz9mpEk+xHrgbgIQ56AMjvhJPSYOQBfV4S4izsAZFNtJdP/OP+ItwRFckAOWNN9wv /Ezw== X-Gm-Message-State: AOUpUlE1RT/tcDbEMPbrbykISeJAqp8wcgrqwD4CY0P/mWIQ25D+NswP oSEqdZrA5ooDWuaYPlI4k5ysVSbwljeqOe0+eBYZg94J X-Google-Smtp-Source: AAOMgpcsS7derfvRCRNUFheBMDqx9hg50z7MecALgLkFJk3F/Rprhxlvy2XDFC/7o6H8Xq07OMGz8bYQPxzhujgQ8Zs= X-Received: by 2002:a6b:8828:: with SMTP id k40-v6mr9261206iod.68.1532799175718; Sat, 28 Jul 2018 10:32:55 -0700 (PDT) MIME-Version: 1.0 From: Christopher Wood Date: Sat, 28 Jul 2018 10:32:44 -0700 Message-ID: To: "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Minutes for TLS IETF 102 uploaded X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 28 Jul 2018 17:32:58 -0000 Minutes for both TLS sessions at IETF 102 have been uploaded: https://datatracker.ietf.org/doc/minutes-102-tls/ Many thanks to Joe Hall and Gurshabad Grover for taking detailed notes. Please review the minutes and check for inaccuracies. If anything is incorrect, please let the chairs know ASAP. Thanks, Chris, Joe, and Sean From nobody Sun Jul 29 08:10:26 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A183B130DE8 for ; Sun, 29 Jul 2018 08:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.59 X-Spam-Level: X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_RP_RNBL=1.31] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGsSJWc1OALg for ; Sun, 29 Jul 2018 08:10:23 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FEDE1277D2 for ; Sun, 29 Jul 2018 08:10:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 7AC855142F; Sun, 29 Jul 2018 18:10:20 +0300 (EEST) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 7R22kzmPKJpp; Sun, 29 Jul 2018 18:10:20 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id F38D52323; Sun, 29 Jul 2018 18:10:17 +0300 (EEST) Date: Sun, 29 Jul 2018 18:10:17 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "" Message-ID: <20180729151017.GA8266@LK-Perkele-VII> References: <20180728074851.GA14017@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Double-Checking after TLS 1.3 pre-RFC copy edits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 29 Jul 2018 15:10:26 -0000 On Sat, Jul 28, 2018 at 06:41:09AM -0700, Eric Rescorla wrote: > > The text here isn't totally generic, as it refers to scalar multiplication > and u-coordinate > point input. So, if we had some other ECDH-type thing that didn't have these > concepts, then we would have yet new text. > > In the interest of the minimal change, I suggest: > > "For X25519 and X448, the calculations are as follows" > ... > > "For these curves, implementations SHOULD use..." > > How does that sound? Yeah, passable. I do not think it is likely we need to add another DH function (due to threat of QC making ((H)EC)DH go away), and even if we do, it is just some extra text. The PQC asymmetric key exchanges will be KEMs, which have pretty different behavior from existing things. -Ilari From nobody Sun Jul 29 15:29:33 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6126C130EBC for ; Sun, 29 Jul 2018 15:29:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrU_Sn1BMCx6 for ; Sun, 29 Jul 2018 15:29:30 -0700 (PDT) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DCA9130E66 for ; Sun, 29 Jul 2018 15:29:30 -0700 (PDT) Received: by mail-lf1-x12f.google.com with SMTP id a134-v6so6819232lfe.6 for ; Sun, 29 Jul 2018 15:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AFcTn04WFXRsou+axKe9grVunNs3w/iAJ/4x7FqPnAk=; b=eRWhfm8m2rLaOhKjtCUcen33gucv607HHtHJZ/BBZcC+A/d1X1iA/DX36lmb3zTgL+ M8FmqnPWBFdYLSwaFAGfQo6J2DYmWmOU798tnK9tmcyLSVjvID0scSI5+hVrGT8z4rwR PX0+Vd4QeurUmDmgnP/V53YT7j5Wx82Osf/QzmrdPYPs5LOAtsv6c86N/1id27CAAGUM 5L2yaGDLDwJIIZggdlDXsa/h4ZzjE2JRu7fg6h8ULbSxXb6yZKcgNyCNggYbBoqY9OZV 9oNtvVsydSjuONH/jBG9kstLtucH3QiArom6GTJ8BcwYbJ69Oe86BNCcNJ53faskPVUA ITsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AFcTn04WFXRsou+axKe9grVunNs3w/iAJ/4x7FqPnAk=; b=MZTb5rYGp3lz7vwB9W5GQJXDqo+6mVDKAr8s4VAiUXLFea5iXs/T4rlQKwv2NIMyJG YtSQS4fg0OpApz1tswYiNNd68mkzd3Af13Nn8J6BvckTi2a8LA+o3Qc5M8loLqxhe6Q7 A3MIIg9EROwMSl9O3cPjDNQNiE0Gf6WMP3zI8tLhegyCyAT7p8rmengInTTi6Bps1OZH P3XDq0SqXPEMCV2xVnE0amgU/oGd4o3tDUITmPmXqa208tEiQf/vdp6/5VvL+VEQgKhY nzufmQgpYspiV4IX5+1G8ZMXgKRRKP2597Od3L6FC3ulOyzm82ZAnVeythPWJFYJLjD5 rLwA== X-Gm-Message-State: AOUpUlHPhQF7xEFJaR3IzUEN34oVYQKL5sqih54zPppU/zZCGgQmEvX3 HWgmi2dknCTjzYkrCVPsdq+A5+rQWWxU/RzhoAs1xA== X-Google-Smtp-Source: AAOMgpcd63PQMSTG8KeCZITUxJwCAzb8eg40qdt9URXUkCGasv+lB5QWnvHIXdzKqTvYFSylSnc7zqNyKmAXZWtDgJ4= X-Received: by 2002:a19:1ad1:: with SMTP id a200-v6mr8612910lfa.49.1532903368784; Sun, 29 Jul 2018 15:29:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Sun, 29 Jul 2018 15:28:48 -0700 (PDT) In-Reply-To: <20180729151017.GA8266@LK-Perkele-VII> References: <20180728074851.GA14017@LK-Perkele-VII> <20180729151017.GA8266@LK-Perkele-VII> From: Eric Rescorla Date: Sun, 29 Jul 2018 15:28:48 -0700 Message-ID: To: Ilari Liusvaara Cc: "" Content-Type: multipart/alternative; boundary="000000000000c591d705722ae0fe" Archived-At: Subject: Re: [TLS] Double-Checking after TLS 1.3 pre-RFC copy edits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 29 Jul 2018 22:29:32 -0000 --000000000000c591d705722ae0fe Content-Type: text/plain; charset="UTF-8" Thanks! On Sun, Jul 29, 2018 at 8:10 AM, Ilari Liusvaara wrote: > On Sat, Jul 28, 2018 at 06:41:09AM -0700, Eric Rescorla wrote: > > > > The text here isn't totally generic, as it refers to scalar > multiplication > > and u-coordinate > > point input. So, if we had some other ECDH-type thing that didn't have > these > > concepts, then we would have yet new text. > > > > In the interest of the minimal change, I suggest: > > > > "For X25519 and X448, the calculations are as follows" > > ... > > > > "For these curves, implementations SHOULD use..." > > > > How does that sound? > > Yeah, passable. > > I do not think it is likely we need to add another DH function (due > to threat of QC making ((H)EC)DH go away), and even if we do, it is > just some extra text. The PQC asymmetric key exchanges will be KEMs, > which have pretty different behavior from existing things. > > > > -Ilari > --000000000000c591d705722ae0fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Thanks!

    On Sun, Jul 29, 2018 at 8:10 AM, Ilari Liusvaara <= ilariliusvaara@welho.com> wrote:
    On Sat, Jul 28, 2018 at 06:41:09AM -0700, Eric Resco= rla wrote:
    >
    > The text here isn't totally generic, as it refers to scalar multip= lication
    > and u-coordinate
    > point input. So, if we had some other ECDH-type thing that didn't = have these
    > concepts, then we would have yet new text.
    >
    > In the interest of the minimal change, I suggest:
    >
    > "For X25519 and X448, the calculations are as follows"
    > ...
    >
    > "For these curves, implementations SHOULD use..."
    >
    > How does that sound?

    Yeah, passable.

    I do not think it is likely we need to add another DH function (due
    to threat of QC making ((H)EC)DH go away), and even if we do, it is
    just some extra text. The PQC asymmetric key exchanges will be KEMs,
    which have pretty different behavior from existing things.



    -Ilari

    --000000000000c591d705722ae0fe-- From nobody Sun Jul 29 18:02:23 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 262CA130EE1 for ; Sun, 29 Jul 2018 18:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSEv4qXNQpek for ; Sun, 29 Jul 2018 18:02:18 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8822F130DEA for ; Sun, 29 Jul 2018 18:02:18 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id s198-v6so18282218oih.11 for ; Sun, 29 Jul 2018 18:02:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SV3KwA77ED7+ttQKcJE33JbitDJyv81BGS2o2+QnMyc=; b=H6vBdq7++rHmMb785CHSRBTfla/asCXS/8jy7i0wvTm5Ye1kDdLxt4ljVuo9A6QWlU ejsOhdcXrm2hN+vTMG9H1kpLGRxafEIFQ7QW3busdekTaZdXvcUHv3Pkh19pS+nOktpJ g/uC1FMgJxt9Lig5ZgMmweYY16Rj5ebMHOgTUGXSiAieIXBxPfcSZNdK2h0v6DYF+UsD aDRcGOpYVqsn9DMzEnUjqQLYTuCLSZDFFZ8y9HDCnih5sP0jfl5HpoYqy7Pc1TKEmCnl oX0REePJ2NYR7VSTvUr2uq0suBqpfPurXyj1nWFWtdrKkST7mT4mIzDj7O/51viKRSuI eAbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SV3KwA77ED7+ttQKcJE33JbitDJyv81BGS2o2+QnMyc=; b=FlZvmSh2nbuJ6YiCHjhok6h9HwsQqz4U05UatdTw6ow/c3NieVePEGPLrMgspM8SGh 29UBLTETJO/XJd6Gf6v3lz4MqEc0y7Bc5bfCYwSvZr2SRGNCB86roq+q765wthu46gn6 VxqMHbSj3xiA4CUgNxnNUKMMpOYhijdpwyreqj15+d8FZStFeprp4DiwqEMY6eTkfI3X jxF1RzIaQCqWgC8dJDiAWGNdkWSxADkpyD3O3klYco/RgnoxEE4sEnxpUumfafm16gtH cuQkMf20epTFk3y6nUokGb2a2t/gFKfpFvpJ13J2QfY5PVCi+SnQ/e6xgWc3rX01Z7vJ fInw== X-Gm-Message-State: AOUpUlGGo1c9FNczelO/P89sIBoYbfZ0RfyIWNuMHqYqsryM8aqbYAMG IMsxP0iujpisFbCpeP6JKmRRoPg30F2seHebx6il5UYK X-Google-Smtp-Source: AAOMgpfJqaRllMctHiqddqNTHhDHeZqHjSiNIE85gipkrdjG6zkF65xeRwAacMpdZUMmfqw13HE/ibjYVVqRYqxtPpA= X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr14588812oib.254.1532912537672; Sun, 29 Jul 2018 18:02:17 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Mon, 30 Jul 2018 11:02:05 +1000 Message-ID: To: Mark.O=40ncsc.gov.uk@dmarc.ietf.org Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Last Call: (Example Handshake Traces for TLS 1.3) to Informational RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2018 01:02:21 -0000 Thanks Mark, I hadn't recorded the messages individually because it was a little tricky, but by doing so both of your concerns should be addressed (at a modest cost of 7 extra pages of hex). For example, this now shows: {server} send a ServerHello handshake message ServerHello (90 octets): 02 00 00 56 03 03 77 bd a6 37 17 c6 c7 06 9e ae bc df d0 49 d9 c9 07 ca 6c d4 7e 87 8f 4e 0c 26 86 07 37 1d 71 4f 00 13 01 00 00 2e 00 33 00 24 00 1d 00 20 37 b6 e5 9f 38 84 d0 51 93 52 d9 48 cb 26 20 d3 c9 2f 61 5e 8e e4 17 eb d0 f1 69 e4 6e fe 0b 72 00 2b 00 02 03 04 {server} derive secret for handshake "tls13 derived": I haven't pushed a new revision because it is currently under review by the IESG, but will do so at the next opportunity. You can see a preview here (noting that this uses the draft version identifier of 0x7f1c rather than the final 0x0304): https://tlswg.github.io/draft-ietf-tls-tls13-vectors/draft-ietf-tls-tls13-v= ectors.html On Sat, Jul 28, 2018 at 2:58 AM Mark O wrote: > > > > A couple of comments on draft-ietf-tls-tls13-vectors-06: > > Ordering of messages: > > Whenever the steps =E2=80=98{server} derive secret "tls13 c hs traffic":= =E2=80=99 and =E2=80=98{server} derive secret "tls13 s hs traffic":=E2=80= =99 appear, this is corresponding to the steps in the second phase of the k= ey schedule (section 7.1 of tls13-28) > To complete these you need to have the encoded ServerHello message (as se= en in =E2=80=98Derive-Secret(., "c hs traffic", ClientHello...ServerHello)= =E2=80=99). > The description of the ServerHello message doesn=E2=80=99t come until sev= eral steps later. Someone using the test vectors to create unit tests would= need to look ahead to the ServerHello payload (after =E2=80=98{server} se= nd handshake record:=E2=80=99, starting with =E2=80=98payload (90 octets): = 02 00 00=E2=80=99) before they can recreate the steps above. > > Coalescence of records: > There are several examples where multiple messages are shown concatenated= , both in their payload and ciphertext forms, which makes it much harder to= test them. Concatenating them (or not) has no effect on the protocol, so i= t=E2=80=99s not a requirement. It would be helpful to split out the message= s so that it=E2=80=99s clearer which bytes belong to which message. The fir= st example of this is after "{server} send a EncryptedExtensions handshake= message", "{server} send a Certificate handshake message", "{server} sen= d a CertificateVerify handshake message", and "{server} send a Finished ha= ndshake message"; starting with "payload (657 octets): 08 00 00". > > Mark > > > > This information is exempt under the Freedom of Information Act 2000 (FOI= A) and may be exempt under other UK information legislation. Refer any FOIA= queries to ncscinfoleg@ncsc.gov.uk > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Jul 30 07:36:19 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B82131141 for ; Mon, 30 Jul 2018 07:36:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEpcAouJ1XMy for ; Mon, 30 Jul 2018 07:36:07 -0700 (PDT) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (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 E64AB131114 for ; Mon, 30 Jul 2018 07:36:06 -0700 (PDT) X-Spoof: Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs210cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jul 2018 10:36:05 -0400 Received: from XCT114CNC.rim.net (10.65.161.214) by XCT105CNC.rim.net (10.65.161.205) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 30 Jul 2018 10:36:05 -0400 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT114CNC.rim.net ([::1]) with mapi id 14.03.0319.002; Mon, 30 Jul 2018 10:36:04 -0400 From: Dan Brown To: Eric Rescorla CC: =?utf-8?B?SGFubm8gQsO2Y2s=?= , "tls@ietf.org" Thread-Topic: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Thread-Index: AdQdyutxd5brAeCrTvCBnUE+fi65pAALHowA///OLCuAAEQ9AP/wPvXg Date: Mon, 30 Jul 2018 14:36:03 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501CA9EDD@XMB116CNC.rim.net> References: <20180717155550.1a18202e@computer> <20180717145727.8642646.41749.26614@blackberry.com> In-Reply-To: Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.252] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_004B_01D427F1.1C4320F0" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2018 14:36:15 -0000 ------=_NextPart_000_004B_01D427F1.1C4320F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_004C_01D427F1.1C4320F0" ------=_NextPart_001_004C_01D427F1.1C4320F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable The TLS 1.3 draft sentence =E2=80=9CThey are no longer considered = appropriate for general use and should be assumed to be potentially = unsafe=E2=80=9D seems a bit excessive. I suggest deleting it, and think = that its encompassing paragraph flows fine without it, and is = sufficiently logical. I see its removal as an editorial change (though = I am not sure it is too late or not to make such a change). =20 More rationale below =E2=80=A6 =20 For example, consider secp256k1 (used in bitcoin), one of the curves = obsoleted/deprecated in TLS 1.3 and 4492bis. I certainly agree with the = prevailing wisdom (first suggested by Miller) that, because secp256k1 is = a special CM curve, it is a greater security risk than non-CM curves = (including secp251r1 (aka NIST P256), Curve25519, and the Brainpool = curves). It is fine for TLS to heed this advice. =20 But there is still no proof that the risk is greater, and various = reputable authors have pointed out situations that special algorithms = may sometimes better survive disasters than their less special = counterparts, I can dig up references if needed. (My view is that this = risk of disaster is to apply both types of algorithms, i.e. defense in = depth, (hence I proposed a new CM curve to CFRG) but I would perfectly = understand if doubling the cost of key agreement is too expensive for = TLS. =20 I also don=E2=80=99t dispute that supporting (a choice of) many curves = might induce security risks (e.g. spreading security analysis too thin, = etc., weakest option attacks, etc.), and that there may be greater = implementation risks (of some curves vs others), and so on, but I view = most of these risk as pragmatic risks, which are mitigatable with = sufficient effort. =20 The quoted sentence =E2=80=9CThey are no longer considered appropriate = for general use and should be assumed to be potentially unsafe=E2=80=9D = loses most of these nuances.=20 =20 From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: Tuesday, July 17, 2018 11:02 AM To: Dan Brown Cc: Hanno B=C3=B6ck ; tls@ietf.org Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? =20 Well, I note that the text also says "or have had very little usage," =20 -Ekr =20 =20 On Tue, Jul 17, 2018 at 7:57 AM, Dan Brown > wrote: It's mainly due to CFRG's advice, isn't it? Calling other curves potentially unsafe or inappropriate for general use = is a bit harsh and outside the scope of TLS, isn't it? As to using a narrow or wide set of curves, there are reputable = proposals for the latter: ia.cr/2015/647 and ia.cr/2015/366 = =20 which may be too slow for TLS, or lacking in some other practicalities, = but it is hard to conclude it is riskier or less secure. If it's not too late then an editorial softening for the reason for the = set of allowed TLS curves makes sense. Best regards, Dan Original Message From: Hanno B=C3=B6ck Sent: Tuesday, July 17, 2018 9:56 AM To: tls@ietf.org =20 Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? Hi, I think there's been a mentality change in the TLS community that explains this. Back when Brainpool curves were standardized there was a "more is better" mentality when it came to algorithms. I.e. if an algorithm is not broken it's good to have it in TLS. Particularly all kinds of nationalized algs made it into TLS. There's a very strong reason against this: It creates complexity. More opportunities for attacks, more fragmentation of the ecosystem. I believe I speak for a lot of people here when I say that fewer algorithms is better and having more algs "just because" is not a good reason. With that in mind an algorithm doesn't have to be weak to be removed from TLS. It's reason enough if it's rarely used and doesn't have a significant advantage over alternatives. Brainpool curves were never widely used in mainstream deployments of TLS (aka browsers). They have no significant advantage over the other choices. They pretty much exist because Germany wanted to have their homegrown crypto algorithm, too, meaning they exist for nationalistic reasons, not technical ones. So deprecating them has the same reason we don't have SEED or Camellia in TLS any more. -- Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de =20 GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org =20 https://www.ietf.org/mailman/listinfo/tls =20 ------=_NextPart_001_004C_01D427F1.1C4320F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

    The TLS = 1.3 draft sentence =E2=80=9CThey are no longer considered appropriate = for general use and should be assumed to be potentially unsafe=E2=80=9D = seems a bit excessive.=C2=A0 I suggest deleting it, and think that its = encompassing paragraph flows fine without it, and is sufficiently = logical.=C2=A0 I see its removal as an editorial change (though I am not = sure it is too late or not to make such a change).

     

    More = rationale below =E2=80=A6

     

    For example, = consider secp256k1 (used in bitcoin), one of the curves = obsoleted/deprecated in TLS 1.3 and 4492bis. =C2=A0I certainly agree = with the prevailing wisdom (first suggested by Miller) that, because = secp256k1 is a special CM curve, it is a greater security risk than = non-CM curves (including secp251r1 (aka NIST P256), Curve25519, and the = Brainpool curves).=C2=A0 It is fine for TLS to heed this = advice.

     

    But there is still no proof that the risk is greater, = and various reputable authors have pointed out situations that special = algorithms may sometimes better survive disasters than their less = special counterparts, I can dig up references if needed.=C2=A0 (My view = is that this risk of disaster is to apply both types of algorithms, i.e. = defense in depth, (hence I proposed a new CM curve to CFRG) but I would = perfectly understand if doubling the cost of key agreement is too = expensive for TLS.

     

    I also = don=E2=80=99t dispute that supporting (a choice of) many curves might = induce security risks (e.g. spreading security analysis too thin, etc., = weakest option attacks, etc.), and that there may be greater = implementation risks (of some curves vs others), and so on, but I view = most of these risk as pragmatic risks, which are mitigatable with = sufficient effort.

     

    The quoted = sentence =E2=80=9CThey are no longer considered appropriate for general = use and should be assumed to be potentially unsafe=E2=80=9D loses most = of these nuances.

     

    From: = Eric Rescorla [mailto:ekr@rtfm.com]
    Sent: Tuesday, July 17, = 2018 11:02 AM
    To: Dan Brown = <danibrown@blackberry.com>
    Cc: Hanno B=C3=B6ck = <hanno@hboeck.de>; tls@ietf.org
    Subject: Re: [TLS] Why = are the brainpool curves not allowed in TLS 1.3?

     

    Well, I note that the text also says "or have had = very little usage,"

     

    -Ekr

     

     

    On Tue, = Jul 17, 2018 at 7:57 AM, Dan Brown <danibrown@blackberry.com> = wrote:

    It's = mainly due to CFRG's advice, isn't it?
    Calling other curves = potentially unsafe or inappropriate for general use is a bit harsh and = outside the scope of TLS, isn't it?
    As to using a narrow or wide set = of curves, there are reputable proposals for the latter:

    ia.cr/2015/647 and = ia.cr/2015/366

    which may be too slow for = TLS, or lacking in some other practicalities, but it is hard to conclude = it is riskier or less secure.

    If it's not too late then an = editorial softening for the reason for the set of allowed TLS curves = makes sense.

    Best regards,

    Dan


      Original = Message
    From: Hanno B=C3=B6ck
    Sent: Tuesday, July 17, 2018 9:56 = AM
    To: tls@ietf.org
    Subject: = Re: [TLS] Why are the brainpool curves not allowed in TLS = 1.3?



    Hi,

    I = think there's been a mentality change in the TLS community = that
    explains this.
    Back when Brainpool curves were standardized = there was a "more is
    better" mentality when it came to = algorithms. I.e. if an algorithm is
    not broken it's good to have it = in TLS. Particularly all kinds of
    nationalized algs made it into = TLS.

    There's a very strong reason against this: It creates = complexity. More
    opportunities for attacks, more fragmentation of the = ecosystem. I
    believe I speak for a lot of people here when I say that = fewer
    algorithms is better and having more algs "just = because" is not a good
    reason. With that in mind an algorithm = doesn't have to be weak to be
    removed from TLS. It's reason enough if = it's rarely used and doesn't
    have a significant advantage over = alternatives.

    Brainpool curves were never widely used in = mainstream deployments of TLS
    (aka browsers). They have no = significant advantage over the other
    choices. They pretty much exist = because Germany wanted to have their
    homegrown crypto algorithm, too, = meaning they exist for nationalistic
    reasons, not technical ones. So = deprecating them has the same reason we
    don't have SEED or Camellia = in TLS any more.

    --
    Hanno B=C3=B6ck
    https://hboeck.de/

    mail/jabber: hanno@hboeck.de
    GPG: = FE73757FA60E4E21B937579FA5880072BBB51E42

    _________________________= ______________________
    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

     

    ------=_NextPart_001_004C_01D427F1.1C4320F0-- ------=_NextPart_000_004B_01D427F1.1C4320F0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIh1TCCBckw ggOxoAMCAQICBQD2V+DAMA0GCSqGSIb3DQEBDQUAMHwxCzAJBgNVBAYTAkNBMRswGQYDVQQKDBJC bGFja0JlcnJ5IExpbWl0ZWQxIjAgBgNVBAsMGUJsYWNrQmVycnkgRW50ZXJwcmlzZSBQS0kxLDAq BgNVBAMMI0JsYWNrQmVycnkgRW50ZXJwcmlzZSBSU0EgUm9vdCBDQSAxMB4XDTEzMTIxMzE3NDU0 N1oXDTM4MTIxMzE3NDU0N1owfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkgTGlt aXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxhY2tC ZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwggIgMA0GCSqGSIb3DQEBAQUAA4ICDQAwggII AoICAQDGRcB/8QfFrWiS6iI+cqEd5oN9JFerfmDskffgyqIzZzEywv5Yx7/zv3YMsQB7kuYUtRGa uQGKrCDOSul6MXVYFRqqszScZKTFN873LBcUcpmcrbDLET6410g3krO7OKMQUmmcfFql0mCTxWay BKef7BPJEXwn/YOxopXtQ9g2SgYZm0KCAjoOH3Yb0BQrNkFKN9plF/BK0S/brBWAzwKKpJo7YW7B iuK75OjTfIM2ILRc5oZs8vI8B3IltjvUG53dFATXByJBXScvBefIIGYMrXbs2SN17BjicAVNW4pp NUKoB0YpGjmJ3LClIeSdnLTUC84k268v8GQ302/2d+V6VKaXlMk2F9JraENGYe+vT4mez4Co5ELZ aW8LJtEYeSZOOlgssychWms0FY8IIToH9Fqgu9xO8N5TAFWipjMtJ8tPqMChdVwkz5dP3jxPMCAI pwmDii6mCIy1jIv+iS1qMluemIu1FneNFfaESBFby0llyS+XG2sEbFAthY1V7jw50GFs2c5sHIY3 ajT8YC21+Qzxat2OcI2/lhnV3V5k+oImJxDswvjFHNQ/APW7ti+B1VEWJ0HcKzEz2eeWdqYxhZAh XmdS7Ir/U1ROIASEYFg6wt56aC8/PjVOyMRG6NvMdyPwwzfMx3CFavzoOnXb3YL9vDI2AyY59WCw edlGcQIBA6NUMFIwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFPhp ifhjnu9oXoEwYnBSow7dspYIMBAGCSsGAQQBgjcVAQQDAgEAMA0GCSqGSIb3DQEBDQUAA4ICAQCs FUaj+ZL3/7JbMYjTdp7mixMW3e/ZpxBWPU6upIAFlBdN05eMkvfVDhAkAFmXCWXMp4iUWd7dz3Kf f2LdAyGhKOqSfg2Ns+MqKLLM4ugjQ8arlRNC2kabtf8RpeRxgMWGsgecZ8L12YHlZ67AzBd+YrBS 2Is+GC2CMYGqTFI6IUVsFQGIsaz+a4TghhsokY8qqKU4Eul4rUrKnzNciskstDTPOQrpORDHpFQt D6nHeB5LlRaSuwVcIcr/H28HEffXc7tFXu+/C3Y6lzQcXD0vMXnSOJ7/CrH0cPe2bQaC+oMBpu2V qjVXWZ8umTyT6etZ3nz1llIeZAxUW/MROetLQFLjBmywiY5EBu/q1UIdlJ/qC7VcCmfExowfLyqY v2V+ShNrEXtzHPPCuPk/j1eP6fg1lP3kbJg0ChTcCEAWtBX4foFcVM4c1f8Au5thaDnH7G4kWL7s dNxoKNnONIYtYbeSKWqfomRPbb2OBgKXM3wTKV6Ze/fLPW9WNdtNFk0Mr0b+nUmPZLGUEL+ZMG95 0BNuQgxWblbOXxwTesin4D2Vn5tL0J9XHk62EdDFefR+5UJqRanhr4pOxO0WWpu1Ux6x1xRDW4yT xNqnXVfjduQDJfbmXvp6PG5UJlhlo7FkW3rz1tWpEWHgOPJ9qAJG7rl5CA67TXdpmIBzbyJYITCC B0kwggYxoAMCAQICClZxDY0AAAACH3EwDQYJKoZIhvcNAQELBQAwVjETMBEGCgmSJomT8ixkARkW A25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEqMCgGA1UEAxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUg SXNzdWluZyBDQSAxMB4XDTE4MDIwODE5MjQwMVoXDTE5MDIwODE5MjQwMVowgakxEzARBgoJkiaJ k/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xDTALBgNVBAsTBEFNRVIxCzAJBgNVBAsT AkNBMRQwEgYDVQQLEwtNaXNzaXNzYXVnYTEOMAwGA1UECxMFVXNlcnMxEjAQBgNVBAMTCURhbiBC cm93bjEnMCUGCSqGSIb3DQEJARYYZGFuaWJyb3duQGJsYWNrYmVycnkuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAohJqrR7zCc/JYInUzai/eVD0K2w8BxWQp42YEU4kNA1sCBCJ BI4/7pNSTAnJTG0yMSoyuBbP8mky6PDlo5PYnCCtXmWha8lJBUuAJ9OHzJwDP9ScBCeCam2MQ2Yu rxW52026C/V93IWR8hEY5YEN0ikdCQU+aYMsLXGnt50z4+Kxq0xcPN54N8IsdY7Fa17x/GzV/Dlv vAMlQDPkAAEwNI96az0Wr0YEvZLgAnuwZH9tnWzsO28M4W0r9x+wPRYkSlsavJF2t5UNCA8ZD5Yy b7+NwLKlmfWEQ2fjwT7yl0RsfkF1sOHNdd51ymmO7GSh4X4L7QHOenRA+hYF4LT6GwIDAQABo4ID wzCCA78wPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIh7+XS4a5gSSGwYEyg9vyJYLc2AGBALHD Koef9EACAWQCAQcwHQYDVR0lBBYwFAYIKwYBBQUHAwQGCCsGAQUFBwMCMAwGA1UdEwEB/wQCMAAw TwYDVR0gAQH/BEUwQzBBBgorBgEEAZtKEwECMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wJwYJKwYBBAGCNxUKBBowGDAKBggrBgEFBQcDBDAKBggr BgEFBQcDAjALBgNVHQ8EBAMCBsAwHQYDVR0OBBYEFL/Dm4ZZ67qzpYa3/pf8WhtppWOtMB8GA1Ud IwQYMBaAFBovS0vbB8lJO4nWMggnop4L8w9rMIIBMgYDVR0fBIIBKTCCASUwggEhoIIBHaCCARmG QGh0dHA6Ly9jcmwucmltLm5ldC9CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUyMENB JTIwMS5jcmyGgdRsZGFwOi8vL0NOPUJsYWNrQmVycnklMjBDb3Jwb3JhdGUlMjBJc3N1aW5nJTIw Q0ElMjAxLENOPU1DQTAxMENOQyxDTj1DRFAsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049 U2VydmljZXMsQ049Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NlcnRpZmljYXRl UmV2b2NhdGlvbkxpc3Q/YmFzZT9vYmplY3RDbGFzcz1jUkxEaXN0cmlidXRpb25Qb2ludDCCAQMG CCsGAQUFBwEBBIH2MIHzMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwgcoG CCsGAQUFBzAChoG9bGRhcDovLy9DTj1CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwSXNzdWluZyUy MENBJTIwMSxDTj1BSUEsQ049UHVibGljJTIwS2V5JTIwU2VydmljZXMsQ049U2VydmljZXMsQ049 Q29uZmlndXJhdGlvbixEQz13aW5kb3dzLERDPWxvY2FsP2NBQ2VydGlmaWNhdGU/YmFzZT9vYmpl Y3RDbGFzcz1jZXJ0aWZpY2F0aW9uQXV0aG9yaXR5ME0GA1UdEQRGMESgKAYKKwYBBAGCNxQCA6Aa DBhkYW5pYnJvd25AYmxhY2tiZXJyeS5jb22BGGRhbmlicm93bkBibGFja2JlcnJ5LmNvbTANBgkq hkiG9w0BAQsFAAOCAQEAyAMjuNH2sn+U8uhj30d48XfUYSaIR1Z/nGgiJcMbREyoP1H9lIM9jYrL GjzUQ7IIT7xRfRfV8aEKec3gL9xPqyhMaAXv1TiQnG8Xo7d1pHyh9gZRXdv/khGyTNd2Y/4Pf100 cg+INLDZfFnuQ/r/x9yBZqrM9d612GLtrBC/MEnJmxwL+SrcdLO7GT4w4uzeyzTUe32+WM6dlu9O h+8c4c+wTlBU5D6HDN8L5mDgYkBSv5ok8FjsK0hp9ggb2skeXZrdTeiOnHJDvmfYp5BXHBFPyivz hcfYja7P8wUTSKivxVVNTGBLXBhGvj2xTiEblt5lzmCq0aVecHUnP9/cvzCCCAUwggXtoAMCAQIC BEMVWF8wDQYJKoZIhvcNAQENBQAwfDELMAkGA1UEBhMCQ0ExGzAZBgNVBAoMEkJsYWNrQmVycnkg TGltaXRlZDEiMCAGA1UECwwZQmxhY2tCZXJyeSBFbnRlcnByaXNlIFBLSTEsMCoGA1UEAwwjQmxh Y2tCZXJyeSBFbnRlcnByaXNlIFJTQSBSb290IENBIDEwHhcNMTQwMjI2MTYyMzU2WhcNMjQwMjI2 MTYyMzU2WjB5MQswCQYDVQQGEwJDQTEbMBkGA1UECgwSQmxhY2tCZXJyeSBMaW1pdGVkMSIwIAYD VQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJMSkwJwYDVQQDDCBCbGFja0JlcnJ5IENvcnBv cmF0ZSBQb2xpY3kgQ0EgMTCCAiAwDQYJKoZIhvcNAQEBBQADggINADCCAggCggIBALom9kCQ+lPa 4g4nzDj+EFbwiF3CYO2/MwRWadgSaavVydBoPc1VIjEN80UbZ1VV5kkHiqYvAuSMx/R2AOgu1o9F qpnaRb59a4R5aobixHEIhYyCt2mmRCgJ6dYYiJbtDn1t00uT0yyI/YU+AUxWFK9c3fy+X20ASyxA ObA9Wev2cFsGFbg6dozYkPDQHlgSczJcEnCyUD6fhgM5N/NsgHmvN3OQb8LL5Kzs204QgbUd966v lHOu6ppVEg2xuTzzhPVONHirYEyFMTa5KNoA1eSX4gzVix+YiAKP8AqvgqEQB4zi2jXSYDzd9RUt nOflg+jz+OKTNDSpOB7/tiPa959++RiRYbWlkYm+Wh+X9uL/ra+uatOTH2UMosyXnO4ryoXOe9JZ WGe0awdY7Rkj65LPmHsCWvR05N1M6vX5JHZLOov65F7J/ZWLLCIAR/sm1mPhBTauU3uvE6JK5/ub PQPxF6UDpNdoaUB7+rfmSoBxyIlmMy6A7v5cbZyHONyLlz+r4sklPDPcz5CBIjbUyFNzK0KK0GXR YVKD++YTbqdCe6vKFZSg2+vIYQ/bFqtp7+gKIpmjjWdzotxVcKgl+r+kTk4pSECLU39Efbo50Nve Q6N0N0sgpj/JVOF53XMRKy4JQ2SDL0A+PkuBL3mdIb+hD0uUsvmDhhB3xavB0UhlAgEDo4ICkjCC Ao4wEgYDVR0TAQH/BAgwBgEB/wIBATAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFDu4wXcNnq1D WPwlrhXQt/KRMoWbMB8GA1UdIwQYMBaAFPhpifhjnu9oXoEwYnBSow7dspYIMIGGBggrBgEFBQcB AQR6MHgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnJpbS5uZXQvb2NzcDBQBggrBgEFBQcwAoZE aHR0cDovL2NydC5yaW0ubmV0L0JsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUy MENBJTIwMS5jcnQwggE3BgNVHR8EggEuMIIBKjCCASagggEioIIBHoZEaHR0cDovL2NybC5yaW0u bmV0L0JsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUyMENBJTIwMS5jcmyGgdVs ZGFwOi8vL0NOPUJsYWNrQmVycnklMjBFbnRlcnByaXNlJTIwUlNBJTIwUm9vdCUyMENBJTIwMSxD Tj1Sb290Q0EsQ049Q0RQLENOPVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENO PUNvbmZpZ3VyYXRpb24sREM9d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25M aXN0P2Jhc2U/b2JqZWN0Q2xhc3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwNwYDVR0gBDAwLjAsBgRV HSAAMCQwIgYIKwYBBQUHAgEWFmh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy8wEAYJKwYBBAGCNxUBBAMC AQAwGQYJKwYBBAGCNxQCBAweCgBTAHUAYgBDAEEwDQYJKoZIhvcNAQENBQADggIBALfxM34RYrFM 8E5/7K7T54kPvkcjQrX9Vtf7+CTHHG2EH7SuFoFWsnNTeP+J8TxJP0hxz4mA5FnMKNlhTPsuP0Nu /Fu1R1okaLsIeOPGAWbtpCQ9fYG+lgeONh5DTfj1uhrLDDUAbqJfjYX8ab4/j9RPgm/mWjlR6nMz PyaCc6cASqnOjs0VSLFdmctNMwvqDwKj4qnCX+AM61Nxd2K3ZITiq6BQIj37hQh07lwgVQra+S56 /cmyO5QKXSnyD/n3U/IPEhShFa30j7yeR4OZ2Gv8vK6HY5jzY5eoJztN089F0l2jSdYIlm47E+sr Vwk88z8UwzsTBKu5LWYVsywfJdyZQF1+bwu52Q8c+mzMaVDZwBwQ3ODIYJ3Y5aWCCmn7Lfkkij14 qcsLkEaKjp6ejoy980wzkPMivmGhV8uxslS+UgjA5qqFZY8iOJAmBLy8ABkE42HoBdezxMCya7TK 3ZxKnTQe9RYDImLx45VQ6K75/uJddTD7GERw7KCCjgmYniD6ozzDPHylziygpUzHhItdeVH+47dE 1nlk1pVzf6oiqDgRuEY1DHIIYKEVh6Zi9F0uaOo7SwZ+h9hqpF2EgGkpliTu8M7CPRlK3OBNPnk4 BgXSNj4D1FdKK7rGbTgXcL/YbtLX2weWErbw+uN/UCG7k3BOelop0zlSJfj9KsotMIIMrjCCCpag AwIBAgIECxEcnDANBgkqhkiG9w0BAQsFADB5MQswCQYDVQQGEwJDQTEbMBkGA1UECgwSQmxhY2tC ZXJyeSBMaW1pdGVkMSIwIAYDVQQLDBlCbGFja0JlcnJ5IEVudGVycHJpc2UgUEtJMSkwJwYDVQQD DCBCbGFja0JlcnJ5IENvcnBvcmF0ZSBQb2xpY3kgQ0EgMTAeFw0xNDA0MTcxODA4MjVaFw0xOTA0 MTcxODA4MjVaMFYxEzARBgoJkiaJk/IsZAEZFgNuZXQxEzARBgoJkiaJk/IsZAEZFgNyaW0xKjAo BgNVBAMTIUJsYWNrQmVycnkgQ29ycG9yYXRlIElzc3VpbmcgQ0EgMTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBANUcv8oSAXw3NNOhPMafhnN2N+8xE31gbXNo+R6TBeuSdZEo5PDfR+PD ps/sIXrSecnAZJWGhDUOQ2pXPRk8jfl0lbcQERTI1UC04Zv5+I2YOw4qTaBt77PAtvW22s3sE6Ag O6okqW6NQFjEGToKXjgo6grBLO6/G4Uc/tPqh6/bcmH4NmaSbszrSJUsPMeNyEWu7r3orxu9KJzM nDQBWpbKZq6l4W96mut0lTPXL8bRDQah5nc0UfRrMzwlLowHtLPXM7/1J2XG+tG7SYIQ3wQ6BRN8 bWXWwMguzsiEz2BQEX60cml4Vz7G5IenHuymRHOERKa4UPiH7oggn8HtKh8CAwEAAaOCCF8wgghb MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBQaL0tL2wfJSTuJ 1jIIJ6KeC/MPazAfBgNVHSMEGDAWgBQ7uMF3DZ6tQ1j8Ja4V0LfykTKFmzCBgQYIKwYBBQUHAQEE dTBzMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5yaW0ubmV0L29jc3AwSwYIKwYBBQUHMAKGP2h0 dHA6Ly9jcnQucmltLm5ldC9CbGFja0JlcnJ5JTIwQ29ycG9yYXRlJTIwUG9saWN5JTIwQ0ElMjAx LmNydDCCASwGA1UdHwSCASMwggEfMIIBG6CCARegggEThj9odHRwOi8vY3JsLnJpbS5uZXQvQmxh Y2tCZXJyeSUyMENvcnBvcmF0ZSUyMFBvbGljeSUyMENBJTIwMS5jcmyGgc9sZGFwOi8vL0NOPUJs YWNrQmVycnklMjBDb3Jwb3JhdGUlMjBQb2xpY3klMjBDQSUyMDEsQ049U3ViQ0EsQ049Q0RQLENO PVB1YmxpYyUyMEtleSUyMFNlcnZpY2VzLENOPVNlcnZpY2VzLENOPUNvbmZpZ3VyYXRpb24sREM9 d2luZG93cyxEQz1sb2NhbD9jZXJ0aWZpY2F0ZVJldm9jYXRpb25MaXN0P2Jhc2U/b2JqZWN0Q2xh c3M9Y1JMRGlzdHJpYnV0aW9uUG9pbnQwggYSBgNVHSAEggYJMIIGBTBBBgorBgEEAZtKFAIBMDMw MQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYB BAGbShMBAzAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQu aHRtMEEGCisGAQQBm0oTAQIwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQ U3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwEBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0u bmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMCAzAzMDEGCCsGAQUFBwIBFiVodHRw Oi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTAgIwMzAxBggrBgEF BQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwIB MDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYK KwYBBAGbShMDAzAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1l bnQuaHRtMEEGCisGAQQBm0oTAwIwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3Bz L0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwMBMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5y aW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMEADAzMDEGCCsGAQUFBwIBFiVo dHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBQMwMzAxBggr BgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtK EwUCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0w QQYKKwYBBAGbShMFATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0 ZW1lbnQuaHRtMEEGCisGAQQBm0oTBgMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQv Y3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwYCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9j cC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMGATAzMDEGCCsGAQUFBwIB FiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTBwMwMzAx BggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5uZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEE AZtKEwcCMDMwMQYIKwYBBQUHAgEWJWh0dHA6Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5o dG0wQQYKKwYBBAGbShMHATAzMDEGCCsGAQUFBwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BT dGF0ZW1lbnQuaHRtMEEGCisGAQQBm0oTCAMwMzAxBggrBgEFBQcCARYlaHR0cDovL2NwLnJpbS5u ZXQvY3BzL0NQU3RhdGVtZW50Lmh0bTBBBgorBgEEAZtKEwgCMDMwMQYIKwYBBQUHAgEWJWh0dHA6 Ly9jcC5yaW0ubmV0L2Nwcy9DUFN0YXRlbWVudC5odG0wQQYKKwYBBAGbShMIATAzMDEGCCsGAQUF BwIBFiVodHRwOi8vY3AucmltLm5ldC9jcHMvQ1BTdGF0ZW1lbnQuaHRtMBAGCSsGAQQBgjcVAQQD AgEAMBkGCSsGAQQBgjcUAgQMHgoAUwB1AGIAQwBBMA0GCSqGSIb3DQEBCwUAA4ICAQAeVuw/L3Zy FbBCOhKq5sL9OrBp4G1j4r6C2WJN2BuAoN4fOdzw7H27Y60d8otCRquP8G/AvQ43dJCsE7kld10v tOs2L4T17T3OHxVoMEU39zoIjgu3x7pVUWNf6HCd3QDwWbQZrLIpPWh4ipvIRipQlizCBfDxmbsJ H/BBiiWl5RC7fnWHbEfdbbHPDWyZ/9CsM2XpGdMgYg82LXWBUzGbKSwtoya0wHEEMlhM9D5MaQkm DmYwJOI9m+ryyZMnYYo28ZvW6khFl/Frd/Y77aSOIgtNTXQ+S86xW4PBJJ1jqoal1xt4jYrWWRBE 0wvpZygMoRFCRMsBGvr/r5rqZ9QcN+OX3tmUOC2rtqH9qQKzABJCDetqB16Oyynx1cvUN/x3p1LM Cd3YcqE4ppRxwvX+377msqZamYjHRMuwM1I2RpuVbMdbEwTIHeb17WgRmHkRWF1yKf1XRxN9ywp0 BzkK0tBvN+yMjJSXiZITYAb0U6WxrtEHWdr1CyJPuSrUzwkx0NdCrImlvwo6froM5h3crRXhUgkm +eNPZhiZ2cBG2OaOX8XKUtounkbqVEbblUy1tLIaxUwYw2j+BcKWrbQsoW798S37b7hJWVVE048I gOfRemUiP7yZ5nh0+SQ6+jTVRaWAba8nawivkrv0ja/k1QwzZD9p7nUSvmizKhbCYzGCAiwwggIo AgEBMGQwVjETMBEGCgmSJomT8ixkARkWA25ldDETMBEGCgmSJomT8ixkARkWA3JpbTEqMCgGA1UE AxMhQmxhY2tCZXJyeSBDb3Jwb3JhdGUgSXNzdWluZyBDQSAxAgpWcQ2NAAAAAh9xMAkGBSsOAwIa BQCggZ4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNzMwMTQz NjAxWjAjBgkqhkiG9w0BCQQxFgQUe2msNuXDClGNKLv3ti+RLO/bsF8wPwYJKoZIhvcNAQkPMTIw MDAHBgUrDgMCGjALBglghkgBZQMEAgMwCwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATANBgkqhkiG 9w0BAQEFAASCAQA+ZRksG/0WFSW6oa80h3jajEsoOwM2eEDEGcUKt1sxiglZOHFcVHjj0KmIu5Gu dGaPoje8IGndW938ZvRiliWbYrdLUXtDfcfXHYTHYG1lfjvlV8MNMGOU0uj2H6CU2nT1o1a8e+a8 ym9xhc6o3RgSu4Te+6swC+WJHGdqUlfJQodMgP9HnLjT5+j1wKr6fN5zGB5qP+7iOMX1pEEkkpjY NW1DtHN60s2WFNidgfxZD01ZubYtNaD6gh057lM7M3p7/SQ8RwPvvdipi7BSjpjKEZUdmlPV+N3Z KD3nSG+NcwVF7eaQIj59B3Zb7CkoNtHvpOvsS7JeJ7B+dHVHBaCrAAAAAAAA ------=_NextPart_000_004B_01D427F1.1C4320F0-- From nobody Mon Jul 30 07:55:46 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34ECC1310E4 for ; Mon, 30 Jul 2018 07:55:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SYHd-p0KIgsE for ; Mon, 30 Jul 2018 07:55:42 -0700 (PDT) Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28E8D130DDF for ; Mon, 30 Jul 2018 07:55:42 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 632AF40241C4; Mon, 30 Jul 2018 14:55:41 +0000 (UTC) Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id E288D76C3; Mon, 30 Jul 2018 14:55:40 +0000 (UTC) From: Hubert Kario To: tls@ietf.org Date: Mon, 30 Jul 2018 16:55:39 +0200 Message-ID: <3272838.bFeZ0KHCYb@pintsize.usersys.redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart47909341.Qt2gZc6Kir"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 30 Jul 2018 14:55:41 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]); Mon, 30 Jul 2018 14:55:41 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:'' Archived-At: Subject: Re: [TLS] Double-Checking after TLS 1.3 pre-RFC copy edits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2018 14:55:44 -0000 --nextPart47909341.Qt2gZc6Kir Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Saturday, 28 July 2018 01:20:43 CEST Eric Rescorla wrote: > Dear TLS WG members. >=20 > I am doing my final copy-edits for the TLS 1.3 RFC and I noted one > technical point and two points I would like to edit for clarity but I > wanted more eyes on. >=20 >=20 > 1. https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.1.2 >=20 > If the client is attempting a PSK key > establishment, it SHOULD advertise at least one cipher suite > indicating a Hash associated with the PSK. >=20 > This seems like it would be better as a MUST. It's not a disaster > if we don't change it, but can anyone think of a reason it should > be a SHOULD? It can be a MUST, but then we need to add a MUST for a server not to=20 overinterpret lack of them (as in MUST NOT abort) - client may send a PSK=20 associated with a hash in a ciphersuite that the server does not know =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 115, 612 00 Brno, Czech Republic --nextPart47909341.Qt2gZc6Kir Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEYeeuxEU+3unL/K+dkqjRuAHS9fUFAltfJusACgkQkqjRuAHS 9fWEZhAAoXbijTt2PD1RXQ2xXgmkUyZ9TeIAa/vXsOAG6rC5AZDDlneZ3xRDFS8e +VFZ0gtKlADEoN71k/l0lZUzUa6FIg41/awH2RfLpDfTQpOFSUFvNl1N0FWc3fIk GUkP2ceb/51khzhbMfWE9SPRsOp6HcD6LcQhSsiqR7h1DHHia9dc/hdLUtk3N4WB uwPKcfMWr6Hu2UDAyC1HHukGqKCOy4RnDvr+7+bG9Rzah6I8SDBiv9EXKAineHtK HRxnkDfKYkr3BeoiTT8CHIlEoCJgp1RY7wte1Y4dWffZS78FI3SRSzxIKiTZzFju yDDu8VfOLnKMAOKLklHoe2pXGQVPoTRcR3ZK/mdIdxKc2UpingSHGNZYY7wact2r +NnuT/3EWz7WMNJAYMJxsAITgdiMTFwMrkk5C/wS76Q4lfUsl8IsyXPTTCzr7MM6 DSdlbDWtNA78QfwO+c13UrzTk/VUr1x7O62cLx5xpFm0hxZ1a6lTIzLSJeUChttG wRxG2cnpgfWMKGB1VUDlS0pmUvWVDQCDX9em/fEgOpNVwkJRY3u0UKnCmTGnW1bx yTULxpUbCZgz/dFzrY6xsYMrnQoIMKlvJ0lgo1m3TDL+Wt/LkulGAuciRGV+zkcR S8M7SE7ysiNVQWzYAr0+M3Ux4MulUS76NlqyDkWaHrvEyBQ76jU= =yeTK -----END PGP SIGNATURE----- --nextPart47909341.Qt2gZc6Kir-- From nobody Mon Jul 30 08:54:54 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBE76130DD7 for ; Mon, 30 Jul 2018 08:54:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woyuSoFBcDBb for ; Mon, 30 Jul 2018 08:54:51 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4A4C8130DD4 for ; Mon, 30 Jul 2018 08:54:50 -0700 (PDT) Received: from LLE2K16-MBX01.mitll.ad.local (LLE2K16-MBX01.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id w6UFsm3T018487; Mon, 30 Jul 2018 11:54:49 -0400 From: "Blumenthal, Uri - 0553 - MITLL" Message-ID: <65F6D687-763D-4778-852D-3CEAF2F84FC9@ll.mit.edu> Content-Type: multipart/alternative; boundary="Apple-Mail=_92ACED27-2267-4703-BA19-3BDEF7626E74" MIME-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Mon, 30 Jul 2018 11:54:46 -0400 In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501CA9EDD@XMB116CNC.rim.net> CC: Eric Rescorla , "tls@ietf.org" To: Dan Brown References: <20180717155550.1a18202e@computer> <20180717145727.8642646.41749.26614@blackberry.com> <810C31990B57ED40B2062BA10D43FBF501CA9EDD@XMB116CNC.rim.net> X-Mailer: Apple Mail (2.3445.9.1) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-30_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=703 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807300173 Archived-At: Subject: Re: [TLS] Why are the brainpool curves not allowed in TLS 1.3? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2018 15:54:54 -0000 --Apple-Mail=_92ACED27-2267-4703-BA19-3BDEF7626E74 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" > On Jul 30, 2018, at 10:36, Dan Brown wrote: >=20 > The TLS 1.3 draft sentence =E2=80=9CThey are no longer considered = appropriate for general use and should be assumed to be potentially = unsafe=E2=80=9D seems a bit excessive. I suggest deleting it, and think = that its encompassing paragraph flows fine without it, and is = sufficiently logical. I see its removal as an editorial change (though = I am not sure it is too late or not to make such a change). I concur with your reasoning, and think that at the very least the words = =E2=80=9Cshould be assumed to be potentially unsafe=E2=80=9D be removed = from the document.=20 --Apple-Mail=_92ACED27-2267-4703-BA19-3BDEF7626E74 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"
    On = Jul 30, 2018, at 10:36, Dan Brown <danibrown@blackberry.com> wrote:

    The TLS = 1.3 draft sentence =E2=80=9CThey are no longer considered appropriate = for general use and should be assumed to be potentially unsafe=E2=80=9D = seems a bit excessive.  I suggest deleting it, and think that its = encompassing paragraph flows fine without it, and is sufficiently = logical.  I see its removal as an editorial change (though I am not = sure it is too late or not to make such a = change).

    I = concur with your reasoning, and think that at the very least the words = =E2=80=9Cshould be assumed to be potentially unsafe=E2=80=9D be removed = from the document. 

    = --Apple-Mail=_92ACED27-2267-4703-BA19-3BDEF7626E74-- From nobody Mon Jul 30 15:33:42 2018 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 A6453128CF3; Mon, 30 Jul 2018 15:33:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Adam Roach To: "The IESG" Cc: draft-ietf-tls-tls13-vectors@ietf.org, Sean Turner , tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153299001967.7842.14757350576096250364.idtracker@ietfa.amsl.com> Date: Mon, 30 Jul 2018 15:33:39 -0700 Archived-At: Subject: [TLS] Adam Roach's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 List-Id: "This is the mailing list 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, 30 Jul 2018 22:33:40 -0000 Adam Roach has entered the following ballot position for draft-ietf-tls-tls13-vectors-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for all the work that went into this document. I think it's very useful to have a set of test vectors for future implementations to develop against. I have a couple of minor comments. --------------------------------------------------------------------------- §1: > Note: Invocations of HMAC-based Extract-and-Expand Key Derivation > Function (HKDF) [RFC5869] are not labelled, but can be identified > through the use the labels used by HKDF. This doesn't parse. Probably should say "...through the use of labels..." or something similar. --------------------------------------------------------------------------- §6: > Note that private keys for this > example are not included in the draft. > > {client} create an ephemeral x25519 key pair: > > private key (32 octets):... I'm not sure what to make of this. Should it say "...private RSA keys for this example..." or something like that? It may also be useful to include a sentence or clause explaining why the omitted private key is not useful for users of this document. From nobody Mon Jul 30 16:13:45 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAFAD130F25; Mon, 30 Jul 2018 16:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zONMwSAlksm4; Mon, 30 Jul 2018 16:13:32 -0700 (PDT) Received: from mail-oi0-x242.google.com (mail-oi0-x242.google.com [IPv6:2607:f8b0:4003:c06::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA94130E9F; Mon, 30 Jul 2018 16:13:32 -0700 (PDT) Received: by mail-oi0-x242.google.com with SMTP id k81-v6so24456265oib.4; Mon, 30 Jul 2018 16:13:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AppOsoNLF524MlyK2tWIkFq9unJelBvpwVujtsVi0zo=; b=Z5K2U5ERz3SVc2ISDAisG2eNNnKRj3GJwt+tvClEaqzCz8b6tsdcZA2BaJLqY1zy3q dCDC+1tS/t5n3AkI2v2GzlkWyklsZ6HGnzZC4rJsMzkdS6iIVNn7vabWCXRv/+GZsl2B +BxCMIwnCgLmbDHYXM9ETcJk0loi1Ltc4taMLfODickrXwDqdPN7IDLQm/6WGdYDhgOx oHc/nUFZvoMPheCbd/waElTWd738Bh4on/DyrY0RE0Kzcv4R9uzcxIM7rtvpK+Fi+yHZ DZT4UgPNZrrjMu+ElfNaHIZ296hw5lLa5/vE+Hxuw33TGs9AWEuys4JsRfwtrNnzJbEV Sn4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AppOsoNLF524MlyK2tWIkFq9unJelBvpwVujtsVi0zo=; b=TS6LBl+2mBLRBu4D6NJpD9WZVTVPDEHNBCS8OHV0sEasLn5TWpRqmFiuLPSyL3sNKd 5M9OI/0sJQvtl8stZ9S8A8gds1ifudocUYHuAFTlmC8nM4O3WlY79waFiaxmfuHLwl3M KF6AcEm5Jd3ONgSMBTMCAwRybWcRyhz8RxcqryREG9qHjPkMEXCc/ghCCHIxihkDaGA9 Tl3sCOTKmC5z5y9WHWb8NJAjjxpyCuGUgoa0fdtM7Wu8Y2Izea32ttQ+UqGcCE9allnA g62xlO3RNreMUwNYrbnI1V/iOJGHiIqT8A9BgM8VfaEJKQgUyHKQENNEnkg1uT8f9JLu qTtA== X-Gm-Message-State: AOUpUlGaph4QO9/Qm3RhSOzxzN2FR9A2tMdTMoVbTXLpG67gBHn+v65D plAjsAYwQt5eAM9wwBsmT1HyxJn6LXPT9xnaWR9roCX+ X-Google-Smtp-Source: AAOMgpcl7ArM5Y4pq0Y2WYtQ+wX+hulML51FV8QBktbuy/0WWjchwiprTHSqlngTK/6PxuoJQt84ybgp2CMW7vLKiOw= X-Received: by 2002:aca:5841:: with SMTP id m62-v6mr21368326oib.346.1532992411387; Mon, 30 Jul 2018 16:13:31 -0700 (PDT) MIME-Version: 1.0 References: <153299001967.7842.14757350576096250364.idtracker@ietfa.amsl.com> In-Reply-To: <153299001967.7842.14757350576096250364.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Tue, 31 Jul 2018 09:13:20 +1000 Message-ID: To: Adam Roach Cc: The IESG , draft-ietf-tls-tls13-vectors@ietf.org, Sean Turner , tls-chairs , "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2018 23:13:34 -0000 On Tue, Jul 31, 2018 at 8:33 AM Adam Roach wrote: > This doesn't parse. Probably should say "...through the use of labels..." or > something similar. > [...] > I'm not sure what to make of this. Should it say "...private RSA keys for this > example..." or something like that? It may also be useful to include a sentence > or clause explaining why the omitted private key is not useful for users of this > document. The private keys for certificates weren't included (as you noticed, the key exchange keys are). Both fixed in https://github.com/tlswg/draft-ietf-tls-tls13-vectors/commit/ca4896c7a3b3cc6d214a1e6fe94b64ba1b1230e8 From nobody Mon Jul 30 16:22:05 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B721130F14; Mon, 30 Jul 2018 16:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h01BiREgqohf; Mon, 30 Jul 2018 16:22:01 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84E32130DD5; Mon, 30 Jul 2018 16:22:01 -0700 (PDT) Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6UNLu5h069388 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 30 Jul 2018 18:21:57 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local To: Martin Thomson Cc: The IESG , draft-ietf-tls-tls13-vectors@ietf.org, Sean Turner , tls-chairs , "" References: <153299001967.7842.14757350576096250364.idtracker@ietfa.amsl.com> From: Adam Roach Message-ID: <07cac7dd-d518-87d9-a94a-7bd1ec2b0ef3@nostrum.com> Date: Mon, 30 Jul 2018 18:21:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [TLS] Adam Roach's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 30 Jul 2018 23:22:03 -0000 On 7/30/18 6:13 PM, Martin Thomson wrote: > On Tue, Jul 31, 2018 at 8:33 AM Adam Roach wrote: >> This doesn't parse. Probably should say "...through the use of labels..." or >> something similar. >> [...] >> I'm not sure what to make of this. Should it say "...private RSA keys for this >> example..." or something like that? It may also be useful to include a sentence >> or clause explaining why the omitted private key is not useful for users of this >> document. > The private keys for certificates weren't included (as you noticed, > the key exchange keys are). > > Both fixed in https://github.com/tlswg/draft-ietf-tls-tls13-vectors/commit/ca4896c7a3b3cc6d214a1e6fe94b64ba1b1230e8 Thanks! /a From nobody Tue Jul 31 10:10:04 2018 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 54AB6130F17; Tue, 31 Jul 2018 10:09:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: Cc: tls@ietf.org, ietf@ietf.org, draft-ietf-tls-tls13-vectors.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153305699627.3135.8054434413462324752@ietfa.amsl.com> Date: Tue, 31 Jul 2018 10:09:56 -0700 Archived-At: Subject: [TLS] Secdir last call review of draft-ietf-tls-tls13-vectors-06 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 List-Id: "This is the mailing list 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, 31 Jul 2018 17:09:57 -0000 Reviewer: Matthew Miller Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Document: Reviewer: Matthew A. Miller Review Date: 2018-07-31 IETF LC End Date: 2018-07-24 IESG Telechat date: 2018-08-02 Summary: This document provides example handshakes for TLS 1.3, including private keys where necessary, making it suitable for testing. This document is ready to be published as an Informational draft. Major Issues: N/A Minor Issues: N/A Nits: N/A From nobody Tue Jul 31 16:14:36 2018 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 7A34F130ECA; Tue, 31 Jul 2018 16:14:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: sean@sn3rd.com, Sean Turner , tls-chairs@ietf.org, draft-ietf-tls-tls13-vectors@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.83.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153307887249.3105.12827768403582747815.idtracker@ietfa.amsl.com> Date: Tue, 31 Jul 2018 16:14:32 -0700 Archived-At: Subject: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 List-Id: "This is the mailing list 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, 31 Jul 2018 23:14:33 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-tls-tls13-vectors-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Rich version of this review at: https://mozphab-ietf.devsvcdev.mozaws.net/D3562 Has anyone checked these besides MT? COMMENTS S 3. > 03 05 03 06 03 02 03 08 04 08 05 08 06 04 01 05 01 06 01 02 01 > 04 02 05 02 06 02 02 02 00 2d 00 02 01 01 00 1c 00 02 40 01 > > {server} extract secret "early": > > salt: (absent) ARen't we using the convention 0? S 3. > {server} extract secret "handshake": > > salt (32 octets): 6f 26 15 a1 08 c7 02 c5 67 8f 54 fc 9d ba b6 97 > 16 c0 76 18 9c 48 25 0c eb ea c3 57 6c 36 11 ba > > IKM (32 octets): 81 51 d1 46 4c 1b 55 53 36 23 b9 c2 24 6a 6a 0e You should specify Z above with the DH. S 3. > 64 00 > > output (32 octets): a8 0c b7 d1 5d b3 4a 17 ab b0 c2 37 65 be 68 > c2 6d 3f 10 da 34 90 5b 09 99 47 e5 5e 37 db 17 b3 > > {server} send a Finished handshake message Maybe include more of the finished computaitons. S 3. > key output (16 octets): 26 79 a4 3e 1d 76 78 40 34 ea 17 97 d5 ad > 26 49 > > iv info (12 octets): 00 0c 08 74 6c 73 31 33 20 69 76 00 > > iv output (12 octets): 54 82 40 52 90 dd 0d 2f 81 c0 d9 42 This is kind of an odd order. S 3. > > IKM (32 octets): 81 51 d1 46 4c 1b 55 53 36 23 b9 c2 24 6a 6a 0e > 6e 7e 18 50 63 e1 4a fd af f0 b6 e1 c6 1a 86 42 > > secret (32 octets): 5b 4f 96 5d f0 3c 68 2c 46 e6 ee 86 c3 11 63 > 66 15 a1 d2 bb b2 43 45 c2 52 05 95 3c 87 9e 8d 06 Aren't these the same as the server too? S 3. > key output (16 octets): c6 6c b1 ae c5 19 df 44 c9 1e 10 99 55 11 > ac 8b > > iv info (12 octets): 00 0c 08 74 6c 73 31 33 20 69 76 00 > > iv output (12 octets): f7 f6 88 4c 49 81 71 6c 2d 0d 29 a4 This is the same as the server write side, right? S 3. > server read traffic keys) > > {client} derive read traffic keys for application data (same as > server write traffic keys) > > {client} calculate finished "tls13 finished": This isn't calculating the finished but rather the finished keys. S 4. > secret (32 octets): 04 8b 40 aa 09 ff d4 c6 76 9c 54 1a 2f 46 e2 > 84 66 06 f7 0d 62 a6 15 97 77 29 c5 b2 81 c7 e7 15 > > {client} send a ClientHello handshake message > > {client} calculate finished "tls13 finished": You should label this as the binder. S 4. > output (32 octets): a8 19 28 e3 08 5c 3a 85 63 ed 82 2d a9 af 7a > b7 1a c5 43 2a 5f 9d 1e 6f 71 32 f1 8b 36 e2 c7 05 > > {client} send handshake record: > > payload (512 octets): 01 00 01 fc 03 03 88 09 d2 a3 9b f9 ae b3 You should explain why this is 512 S 4. > 36 db da 6a 62 6f 02 70 e2 0e eb c7 3d 6f ca e2 b1 a0 da 12 2e > e9 04 2f 76 be 56 eb f4 1a a4 69 c3 d2 c9 da 91 97 d8 2f d3 99 > 32 00 21 20 3c e6 69 de de c4 4e 5e 75 53 8f cc ab 3d b0 45 fb > 5d 21 01 19 99 e1 45 12 ee 3a b3 5f 2a f4 e9 > > ciphertext (517 octets): 16 03 01 02 00 01 00 01 fc 03 03 88 09 I should have noted this earlier, but it's not really ciphertext. S 5. > f5 71 06 36 c0 5b 88 ab a0 35 38 0c 00 2b 00 03 02 03 04 00 0d > 00 20 00 1e 04 03 05 03 06 03 02 03 08 04 08 05 08 06 04 01 05 > 01 06 01 02 01 04 02 05 02 06 02 02 02 00 2d 00 02 01 01 00 1c > 00 02 40 01 > > {server} send a ServerHello handshake message Maybe note that this is a HRR From nobody Tue Jul 31 16:30:21 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC2DC130E96; Tue, 31 Jul 2018 16:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2mUHGv3MCYIv; Tue, 31 Jul 2018 16:30:17 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A981130DF5; Tue, 31 Jul 2018 16:30:17 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w6VNRMNR030872; Wed, 1 Aug 2018 00:30:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3+5l7SIlOoY1nKt3Ov7boHG6xmQvPk9kXUy/Gc2MybU=; b=md7OCQD0teUHLYyqA+vF/K4akQsW5Q7nAfNxVWlo73kOxy4TbQP8MHqKUQXYWcFRxfs7 Rn96VKbLMI1aS8mcaFVv89cPIT6rHq6DtwVhyb3qPDaEoRjCSaLjsLCkpq820YF6Iyiy z0bT0GFKXQowVL9xJuc56pXXW70QOlPvkVSnFxk2j0v9GpRlTk/KdYn6peCbCjr0/Zg2 /jXygYmrcTxz0ikLeivo9rhDqGU1ZCAIOB+sWVZ9yRSayE70NeSEAVc+UZLbawGU56iZ puOib/i105L2XZnXMnS0FLsIXPqCd0gmH3x3RMEbKyo/TfNEeAf9Gj5fMzZhXOqx6nm1 Pw== Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2kgfr59jg8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Aug 2018 00:30:17 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6VNKB7i029315; Tue, 31 Jul 2018 19:30:15 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.53]) by prod-mail-ppoint4.akamai.com with ESMTP id 2kgktwbfue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 31 Jul 2018 19:30:15 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 31 Jul 2018 19:30:08 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Tue, 31 Jul 2018 19:30:08 -0400 From: "Salz, Rich" To: Eric Rescorla , The IESG CC: "draft-ietf-tls-tls13-vectors@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Thread-Topic: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) Thread-Index: AQHUKSRHGmDliLAsokCCbtbF0wZZtqSp+oyA Date: Tue, 31 Jul 2018 23:30:08 +0000 Message-ID: <89A1792A-1F47-4874-9E24-402886F8D423@akamai.com> References: <153307887249.3105.12827768403582747815.idtracker@ietfa.amsl.com> In-Reply-To: <153307887249.3105.12827768403582747815.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.102] Content-Type: text/plain; charset="utf-8" Content-ID: <7F0659F58DF32F479D85F4C91F7F4AF4@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-31_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807310216 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-31_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807310217 Archived-At: Subject: Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2018 23:30:20 -0000 ICAgIA0KICAgIEhhcyBhbnlvbmUgY2hlY2tlZCB0aGVzZSBiZXNpZGVzIE1UPw0KDQpZZXMsIG9w ZW5zc2w6DQoNCmNvbW1pdCBkNmNlOWRhNDliMTMxY2FkODVkYThjOTRjNjE3ZmViZjZjOGQ5MDcz DQpBdXRob3I6IE1hdHQgQ2Fzd2VsbCA8bWF0dEBvcGVuc3NsLm9yZz4NCkRhdGU6ICAgVGh1IEp1 bCAxOSAxMjo0NjowMiAyMDE4ICswMTAwDQoNCiAgICBVcGRhdGUgdGhlIFRMU3YxLjMgdGVzdCB2 ZWN0b3JzDQogICAgDQogICAgVXNlIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgdGVzdCB2ZWN0 b3JzIGF2YWlsYWJsZSBpbjoNCiAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10bHMtdGxzMTMtdmVjdG9ycy0wNg0KICAgIA0KICAgIFJldmlld2VkLWJ5OiBSaWNoIFNh bHogPHJzYWx6QG9wZW5zc2wub3JnPg0KICAgIChNZXJnZWQgZnJvbSBodHRwczovL2dpdGh1Yi5j b20vb3BlbnNzbC9vcGVuc3NsL3B1bGwvNjc0NikNCiANCg0K From nobody Tue Jul 31 16:32:14 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15BE130DD1 for ; Tue, 31 Jul 2018 16:32:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.009 X-Spam-Level: X-Spam-Status: No, score=-0.009 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQVgWs5MyR99 for ; Tue, 31 Jul 2018 16:32:02 -0700 (PDT) Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44B49130EA3 for ; Tue, 31 Jul 2018 16:31:59 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id u202-v6so11968209lff.9 for ; Tue, 31 Jul 2018 16:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7uKHB6Ge7cpzIjpQ0S+2pa5vbU8HIXs0+6hzJWv7M9I=; b=grDADUIxjL0dxC+mJsPokTtbac9yFI1N4hUPJ8hmcxdbprnHMKQH3zFEubZqMQBfU1 QOXRkAbzQEoxAMwV+uI2t6HpGBOwHbnLz6SteNY+rpjkIlsprvOgqTe2ZoWXWfH90zG8 AyCqvmVSiMDxixztMOUbyEcvmt/Aa0LN+7A7c9x5MjP+9IUyXXRGNBN0J9nxcBEG0BAN 7rEKFpPGITE2rxB83AskxMwGuml3m3l6S7dDdIFsFkdu/paOyKg+ftK6MQJukPwZE19j jOOmZofXfNhyt1DAGKGnY6HlH2rOlvxLy7X5dvdQojA2B7auPgyz2iPXWAXlVzqHF06l /Rsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7uKHB6Ge7cpzIjpQ0S+2pa5vbU8HIXs0+6hzJWv7M9I=; b=Mx2ppuZmybsJ1cGs2p2nTqMSDnp3WlcpWXuDNHJnWLkLx4lZbJ5SJGR6Jpv/REyxJ/ /HRuUynLLD2byGEPbzFutKbTg6APnUu9DHxgkSAal37XW+653vqJY4sWoMvOME6VrBlN na/rJllGKj6uRtGKKtd25xlfrpTBb0qpvWy9GYZU5kQRDJYIeJKyHR1xrO3wiXjaUO+3 WDkYOa3x87pfDasj4amFyGVdPLsF6VyuY0IgAHsvJgqF9Zs0tHn9qYPBDFxWbCxB38VU SrBrEKWzx+f5uBr+tp72/K1nOz4LAsMJN0IS493DJrb9lp16t5yq59OOkFDBckyvX2Cv FDMQ== X-Gm-Message-State: AOUpUlFSCRqifEBL3lSLoDmpsWVZJR+GME10pAogFezvtloXFga4rSus Pc6FIGl0n07rCVCyhp9ANvbI27wZ4kgzVkKUOCdZ4A== X-Google-Smtp-Source: AAOMgpcEZzkmbL8pFXE58e8AqZpf2eCLLRcmWuuPw2qevIv4yZOZbA35pgjIotjHWpjNK2TvSI5KthWVXrvvEoMrQV4= X-Received: by 2002:a19:6308:: with SMTP id x8-v6mr15021365lfb.104.1533079917399; Tue, 31 Jul 2018 16:31:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ab3:4091:0:0:0:0:0 with HTTP; Tue, 31 Jul 2018 16:31:16 -0700 (PDT) In-Reply-To: <89A1792A-1F47-4874-9E24-402886F8D423@akamai.com> References: <153307887249.3105.12827768403582747815.idtracker@ietfa.amsl.com> <89A1792A-1F47-4874-9E24-402886F8D423@akamai.com> From: Eric Rescorla Date: Tue, 31 Jul 2018 16:31:16 -0700 Message-ID: To: "Salz, Rich" Cc: The IESG , "draft-ietf-tls-tls13-vectors@ietf.org" , "tls-chairs@ietf.org" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="000000000000e3a58a057253fbcd" Archived-At: Subject: Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2018 23:32:04 -0000 --000000000000e3a58a057253fbcd Content-Type: text/plain; charset="UTF-8" Awesome. Thanks! -Ekr On Tue, Jul 31, 2018 at 4:30 PM, Salz, Rich wrote: > > Has anyone checked these besides MT? > > Yes, openssl: > > commit d6ce9da49b131cad85da8c94c617febf6c8d9073 > Author: Matt Caswell > Date: Thu Jul 19 12:46:02 2018 +0100 > > Update the TLSv1.3 test vectors > > Use the latest version of the test vectors available in: > https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-06 > > Reviewed-by: Rich Salz > (Merged from https://github.com/openssl/openssl/pull/6746) > > > --000000000000e3a58a057253fbcd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    Awesome. Thanks!

    -Ekr
    <= div>

    On Tue, Jul 31, 2018 at 4:30 PM, Salz, Rich <rsalz@akamai.com> wrote:
    =C2=A0 =C2= =A0
    =C2=A0 =C2=A0 Has anyone checked these besides MT?

    Yes, openssl:

    commit d6ce9da49b131cad85da8c94c617febf6c8d9073
    Author: Matt Caswell <matt@openssl.o= rg>
    Date:=C2=A0 =C2=A0Thu Jul 19 12:46:02 2018 +0100

    =C2=A0 =C2=A0 Update the TLSv1.3 test vectors

    =C2=A0 =C2=A0 Use the latest version of the test vectors available in:
    =C2=A0 =C2=A0 https://tools.ietf.org/html= /draft-ietf-tls-tls13-vectors-06

    =C2=A0 =C2=A0 Reviewed-by: Rich Salz <rsalz@openssl.org>
    =C2=A0 =C2=A0 (Merged from https://github.com/openssl/openssl/pull/6746)



    --000000000000e3a58a057253fbcd-- From nobody Tue Jul 31 16:32:38 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8416F130EFA; Tue, 31 Jul 2018 16:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V0zkT1go-Gim; Tue, 31 Jul 2018 16:32:10 -0700 (PDT) Received: from dmz-mailsec-scanner-4.mit.edu (dmz-mailsec-scanner-4.mit.edu [18.9.25.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117A4130ED6; Tue, 31 Jul 2018 16:32:09 -0700 (PDT) X-AuditID: 1209190f-cc9ff70000004cdc-ad-5b60f1780651 Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP id 9D.2E.19676.871F06B5; Tue, 31 Jul 2018 19:32:08 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id w6VNW6Dx027451; Tue, 31 Jul 2018 19:32:07 -0400 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id w6VNW2dZ032002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 31 Jul 2018 19:32:04 -0400 Date: Tue, 31 Jul 2018 18:32:02 -0500 From: Benjamin Kaduk To: "Salz, Rich" Cc: Eric Rescorla , The IESG , "tls-chairs@ietf.org" , "draft-ietf-tls-tls13-vectors@ietf.org" , "tls@ietf.org" Message-ID: <20180731233202.GR96369@kduck.kaduk.org> References: <153307887249.3105.12827768403582747815.idtracker@ietfa.amsl.com> <89A1792A-1F47-4874-9E24-402886F8D423@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <89A1792A-1F47-4874-9E24-402886F8D423@akamai.com> User-Agent: Mutt/1.9.1 (2017-09-22) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hTV1q34mBBt0HDWymLejvnsFiten2O3 mPFnIrPFvXVn2SzmnLjBYvHpfBejA5vHiWVXWD2WLPnJ5DH5cRtzAHMUl01Kak5mWWqRvl0C V8brE7EFC1krHu1pYGpgbGLpYuTkkBAwkfjafIapi5GLQ0hgMZPEmcdnGCGcjYwSHasmQWWu Mkns3vyeFaSFRUBV4trnA2wgNpuAikRD92VmEFsEaFTL2SMsIA3MAp8YJfac6QPbISyQIjF5 xSSgBg4OXqCip++kIYY2Mkpc6rnKCFLDKyAocXLmE7B6ZgEtiRv/XjKB1DMLSEss/8cBYnIK 2ElsancFqRAVUJbY23eIfQKjwCwkzbOQNM9CaF7AyLyKUTYlt0o3NzEzpzg1Wbc4OTEvL7VI 10QvN7NELzWldBMjOKwl+XcwzmnwPsQowMGoxMN7ojohWog1say4MvcQoyQHk5Ior/VhoBBf Un5KZUZicUZ8UWlOavEhRgkOZiURXhuZ+Ggh3pTEyqrUonyYlDQHi5I4772a8GghgfTEktTs 1NSC1CKYrAwHh5IEr+EHoKGCRanpqRVpmTklCGkmDk6Q4TxAw2eD1PAWFyTmFmemQ+RPMepy /Hk/dRKzEEtefl6qlDjvofdARQIgRRmleXBzQOlIInt/zStGcaC3hHk1QEbxAFMZ3KRXQEuY gJZoh8SCLClJREhJNTAqNzDY+b8P3sZxZIptl8JXV8tbj70F3hfMuXCL4cDruh17JSwEPIQk zaoPx0XVCVxJmnLGbu6B5c3WzJvvHDP0/26lkLcsd8OGmyeEJi+tnf/r3r+USXKZJsmBQsab zs4Jcjgn9ITt/+2QxoWmbCLX3gZ9WRrdlGB0+W6S734RzzcfThWsqbNSYinOSDTUYi4qTgQA DErzWyIDAAA= Archived-At: Subject: Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 31 Jul 2018 23:32:17 -0000 IIUC openssl only tests a subset of the vectors in the document, though. -Ben On Tue, Jul 31, 2018 at 11:30:08PM +0000, Salz, Rich wrote: > > Has anyone checked these besides MT? > > Yes, openssl: > > commit d6ce9da49b131cad85da8c94c617febf6c8d9073 > Author: Matt Caswell > Date: Thu Jul 19 12:46:02 2018 +0100 > > Update the TLSv1.3 test vectors > > Use the latest version of the test vectors available in: > https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-06 > > Reviewed-by: Rich Salz > (Merged from https://github.com/openssl/openssl/pull/6746) > > From nobody Tue Jul 31 17:02:07 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BD3130EE3; Tue, 31 Jul 2018 17:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.811 X-Spam-Level: X-Spam-Status: No, score=-0.811 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djCgyfEmFm1N; Tue, 31 Jul 2018 17:01:41 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F42130EC9; Tue, 31 Jul 2018 17:01:41 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w6VNv91D029839; Wed, 1 Aug 2018 01:01:39 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=vSTEv/q6C9r44NYRMblecd0iJeXOpXSVEGngt9Lf31E=; b=B+XfyWrEbQ0vjNRZYpwAcMuBoxhpLL2TaTJPlB6xF8cBofGolwESfP3iytnsOx661GWD +RYkWZuRQPHh8KiTHRP3Qv7jasgXwfoMRJsR+8A96yqHAzfkPRWFOWPqWrQzH+6sJSRV TACeiGa82d5lOD3ih9/RClsmQF61a6K1EoWLmeE17Y6OsvEx2VROMS/Ex6xjiz5Tr9W1 l05cv3ebIwoVgCGSiZnfbZ7+Qtzmx3ql2SRxpJ7OTQ/OD2M9YZY/5M6UMB4A7Alm00F4 BWdZ4xPdNLCPM9NLYI7UrnTH9zPdceDRgexFDzwFn9juptJajyyJ/cMfxgLWLiK2wz40 sg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2kjywcrapg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Aug 2018 01:01:38 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w6VNoWjN007549; Tue, 31 Jul 2018 20:01:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2kgktv2htt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 31 Jul 2018 20:01:38 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb2.msg.corp.akamai.com (172.27.123.59) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 31 Jul 2018 20:01:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Tue, 31 Jul 2018 20:01:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1365.000; Tue, 31 Jul 2018 20:01:37 -0400 From: "Salz, Rich" To: Benjamin Kaduk , "Salz, Rich" CC: "tls@ietf.org" , The IESG , "draft-ietf-tls-tls13-vectors@ietf.org" , "tls-chairs@ietf.org" Thread-Topic: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) Thread-Index: AQHUKSRHGmDliLAsokCCbtbF0wZZtqSp+oyAgABDlwD//8U0AA== Date: Wed, 1 Aug 2018 00:01:36 +0000 Message-ID: <9C27D587-755F-4924-B1D3-397472CC0DB0@akamai.com> References: <153307887249.3105.12827768403582747815.idtracker@ietfa.amsl.com> <89A1792A-1F47-4874-9E24-402886F8D423@akamai.com> <20180731233202.GR96369@kduck.kaduk.org> In-Reply-To: <20180731233202.GR96369@kduck.kaduk.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.f.0.180709 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.102] Content-Type: text/plain; charset="utf-8" Content-ID: <3121436B47CA064CB0ADFCE1529674D0@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-31_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807310221 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-07-31_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807310222 Archived-At: Subject: Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 01 Aug 2018 00:01:45 -0000 R29vZCBwb2ludC4gIFRoZSBzaW1wbGUgMVJUVCBoYW5kc2hha2UgSSB0aGluay4NCg0K77u/T24g Ny8zMS8xOCwgNzozMiBQTSwgIkJlbmphbWluIEthZHVrIiA8a2FkdWtAbWl0LmVkdT4gd3JvdGU6 DQoNCiAgICBJSVVDIG9wZW5zc2wgb25seSB0ZXN0cyBhIHN1YnNldCBvZiB0aGUgdmVjdG9ycyBp biB0aGUgZG9jdW1lbnQsIHRob3VnaC4NCiAgICANCiAgICAtQmVuDQogICAgDQogICAgT24gVHVl LCBKdWwgMzEsIDIwMTggYXQgMTE6MzA6MDhQTSArMDAwMCwgU2FseiwgUmljaCB3cm90ZToNCiAg ICA+ICAgICANCiAgICA+ICAgICBIYXMgYW55b25lIGNoZWNrZWQgdGhlc2UgYmVzaWRlcyBNVD8N CiAgICA+IA0KICAgID4gWWVzLCBvcGVuc3NsOg0KICAgID4gDQogICAgPiBjb21taXQgZDZjZTlk YTQ5YjEzMWNhZDg1ZGE4Yzk0YzYxN2ZlYmY2YzhkOTA3Mw0KICAgID4gQXV0aG9yOiBNYXR0IENh c3dlbGwgPG1hdHRAb3BlbnNzbC5vcmc+DQogICAgPiBEYXRlOiAgIFRodSBKdWwgMTkgMTI6NDY6 MDIgMjAxOCArMDEwMA0KICAgID4gDQogICAgPiAgICAgVXBkYXRlIHRoZSBUTFN2MS4zIHRlc3Qg dmVjdG9ycw0KICAgID4gICAgIA0KICAgID4gICAgIFVzZSB0aGUgbGF0ZXN0IHZlcnNpb24gb2Yg dGhlIHRlc3QgdmVjdG9ycyBhdmFpbGFibGUgaW46DQogICAgPiAgICAgaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdGxzLXRsczEzLXZlY3RvcnMtMDYNCiAgICA+ICAgICAN CiAgICA+ICAgICBSZXZpZXdlZC1ieTogUmljaCBTYWx6IDxyc2FsekBvcGVuc3NsLm9yZz4NCiAg ICA+ICAgICAoTWVyZ2VkIGZyb20gaHR0cHM6Ly9naXRodWIuY29tL29wZW5zc2wvb3BlbnNzbC9w dWxsLzY3NDYpDQogICAgPiAgDQogICAgPiANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgICBU TFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rs cw0KICAgIA0KDQo= From nobody Tue Jul 31 22:03:30 2018 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCA31130DEA; Tue, 31 Jul 2018 22:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQrvB1xDH2Zk; Tue, 31 Jul 2018 22:03:26 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8524B130E66; Tue, 31 Jul 2018 22:03:26 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id 13-v6so32289160ois.1; Tue, 31 Jul 2018 22:03:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Trm/pNoPVw2kroIuhp8oi7LUHdgIP5gtn4Ku4vkfoXU=; b=l60f9eCHNV0M3AxKOsebRMRuX/+jlGNTSdHw8CrIxqxEioAKo3oNFoWatECoMxpOuW pg/XakHKZ9cKCfrW7h2dYvOhMHVAIDj5Gfzz0LZ7QO2EqCoqnOzbT4ooOGHnvHecF4kn FoureldfLbz38j0BDbl+OY0Y+mj/nOGqquwYXVF3rKKCAS3U0JhrHKjF9xUjgfcivNz5 h5Z6gs1KiWqoeF9Wj6B2HBzEMGxitpqCsDvfwrkfEuWKKXpzrNaIso+S3jAxujY+j+0R tLCvGSqqNITnwU0oGlTGdS4bBfT8AMRbILfJceQfxyYWNkbyc4wRXEVDUEMgJXScvRId iYmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Trm/pNoPVw2kroIuhp8oi7LUHdgIP5gtn4Ku4vkfoXU=; b=i0d2aWc4XJ87IF31vUUmOjm/HGGtM5b5cu0B0hQCyh+f8avjB6RcJFHiXyH2ksBTn6 d3UR92A4cDzzFCbfZJa1Dq+JUAAL20WS1j2tODUt9m2EU4QpnGpFOC0qsnMzMDRqhVYT qtfOt/1jzNrMFQayuRIcJzF92AUutNwOpUuyLfJQ72/ORKE7Wo+YEdZc+WKUYcaFANJK 7Rj4nEc86+LCOCyj7pT2lXOs4CAvoQvHN2Mr8Wy4Iq7nzMmk+47GAT+Xmk9Jt4HdqqXg TP/XU8qlo1rwNnjRbzWcwIB/LwAc4JCuTyAY0GDz8Mngbx3qP9bmz675knBvxvJtJNrc /l+g== X-Gm-Message-State: AOUpUlH4BPaaqEWDqIFhHw+Xa5OABvfGnkrvFDEzfVT4d0fWxHbkR3XY lRcUiFYMCK1yqRRpquBavgSqJixU9Y7FnW0UgY0= X-Google-Smtp-Source: AAOMgpe5JMgYunGy1b5i3aDKtgMxVbYeeLjAvqVxCuG35KyChNvrX8Ol4Ab5bt0jLRyaA0I1E4n4Fw8e3I/YKQ+VP1Y= X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr1837712oib.254.1533099805710; Tue, 31 Jul 2018 22:03:25 -0700 (PDT) MIME-Version: 1.0 References: <153307887249.3105.12827768403582747815.idtracker@ietfa.amsl.com> In-Reply-To: <153307887249.3105.12827768403582747815.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Wed, 1 Aug 2018 15:03:13 +1000 Message-ID: To: Eric Rescorla Cc: The IESG , Sean Turner , tls-chairs , draft-ietf-tls-tls13-vectors@ietf.org, "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Eric Rescorla's No Objection on draft-ietf-tls-tls13-vectors-06: (with COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "This is the mailing list 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, 01 Aug 2018 05:03:29 -0000 Thanks for checking on this. I had a couple of bugs with deduplication that made some of the values unnecessarily repetitious. There are a few values around Finished calculation that I added (the values were there already, but you had to extract them from other values). A preview is available (though that uses the draft version numbers and it doesn't have the Finished values because those changes haven't made it into NSS yet): https://tlswg.github.io/draft-ietf-tls-tls13-vectors/draft-ietf-tls-tls13-vectors.html The diff isn't particularly enlightening because the handshakes are completely different each time, but you should be able to find the specific changes if you look for them. On Wed, Aug 1, 2018 at 9:14 AM Eric Rescorla wrote: > Has anyone checked these besides MT? I wasn't aware that openssl was using them, but Kazu provided a ton of feedback when building this. > COMMENTS > > salt: (absent) > > ARen't we using the convention 0? Yes, but "salt: 0" is hard to distinguish from "salt (1 octet): 00", so I decided to be more explicit. I built special code for this, so it could say anything; what would you prefer it to say? "(zero)"? I tend to think that this is OK, but I don't care what it says. > S 3. > > {server} extract secret "handshake": > > > > salt (32 octets): 6f 26 15 a1 08 c7 02 c5 67 8f 54 fc 9d ba b6 97 > > 16 c0 76 18 9c 48 25 0c eb ea c3 57 6c 36 11 ba > > > > IKM (32 octets): 81 51 d1 46 4c 1b 55 53 36 23 b9 c2 24 6a 6a 0e > > You should specify Z above with the DH. The IKM is Z. I didn't see much point in repeating it. Besides, because this is driven from logging, it would require a whole bunch of new logging to support recording of the key exchange. > S 3. > > {server} send a Finished handshake message > > Maybe include more of the finished computaitons. Yeah, the computed HMAC wasn't logged, so I missed it. If you are willing to review the change to NSS to log the result (https://phabricator.services.mozilla.com/D2589), I can include that in the block explicitly, which is better. > S 3. > > key output (16 octets): 26 79 a4 3e 1d 76 78 40 34 ea 17 97 d5 ad > > 26 49 > > > > iv info (12 octets): 00 0c 08 74 6c 73 31 33 20 69 76 00 > > > > iv output (12 octets): 54 82 40 52 90 dd 0d 2f 81 c0 d9 42 > > This is kind of an odd order. I don't know how else to order this. > S 3. > > > > IKM (32 octets): 81 51 d1 46 4c 1b 55 53 36 23 b9 c2 24 6a 6a 0e > > 6e 7e 18 50 63 e1 4a fd af f0 b6 e1 c6 1a 86 42 > > > > secret (32 octets): 5b 4f 96 5d f0 3c 68 2c 46 e6 ee 86 c3 11 63 > > 66 15 a1 d2 bb b2 43 45 c2 52 05 95 3c 87 9e 8d 06 > > Aren't these the same as the server too? Yeah, I had some bugs in the deduplication code that prevented some of these duplicates from being picked up properly. > S 3. > > key output (16 octets): c6 6c b1 ae c5 19 df 44 c9 1e 10 99 55 11 > > ac 8b > > > > iv info (12 octets): 00 0c 08 74 6c 73 31 33 20 69 76 00 > > > > iv output (12 octets): f7 f6 88 4c 49 81 71 6c 2d 0d 29 a4 > > This is the same as the server write side, right? Same here. > S 3. > > server read traffic keys) > > > > {client} derive read traffic keys for application data (same as > > server write traffic keys) > > > > {client} calculate finished "tls13 finished": > > This isn't calculating the finished but rather the finished keys. The fix mentioned above should address that. > S 4. > > secret (32 octets): 04 8b 40 aa 09 ff d4 c6 76 9c 54 1a 2f 46 e2 > > 84 66 06 f7 0d 62 a6 15 97 77 29 c5 b2 81 c7 e7 15 > > > > {client} send a ClientHello handshake message > > > > {client} calculate finished "tls13 finished": > > You should label this as the binder. Done. I've added the other inputs to this as well. > S 4. > > output (32 octets): a8 19 28 e3 08 5c 3a 85 63 ed 82 2d a9 af 7a > > b7 1a c5 43 2a 5f 9d 1e 6f 71 32 f1 8b 36 e2 c7 05 > > > > {client} send handshake record: > > > > payload (512 octets): 01 00 01 fc 03 03 88 09 d2 a3 9b f9 ae b3 > > You should explain why this is 512 I don't think that it's appropriate to document all the design choices here; that this is padded is one from many. (It's also very hard to pick this sort of exceptional condition out for special treatment.) > S 4. > > 36 db da 6a 62 6f 02 70 e2 0e eb c7 3d 6f ca e2 b1 a0 da 12 2e > > e9 04 2f 76 be 56 eb f4 1a a4 69 c3 d2 c9 da 91 97 d8 2f d3 99 > > 32 00 21 20 3c e6 69 de de c4 4e 5e 75 53 8f cc ab 3d b0 45 fb > > 5d 21 01 19 99 e1 45 12 ee 3a b3 5f 2a f4 e9 > > > > ciphertext (517 octets): 16 03 01 02 00 01 00 01 fc 03 03 88 09 > > I should have noted this earlier, but it's not really ciphertext. Fixed. -> "complete record" > S 5. > > f5 71 06 36 c0 5b 88 ab a0 35 38 0c 00 2b 00 03 02 03 04 00 0d > > 00 20 00 1e 04 03 05 03 06 03 02 03 08 04 08 05 08 06 04 01 05 > > 01 06 01 02 01 04 02 05 02 06 02 02 02 00 2d 00 02 01 01 00 1c > > 00 02 40 01 > > > > {server} send a ServerHello handshake message > > Maybe note that this is a HRR The tool that produces this doesn't know this, but I will add a note above the example.